From nobody Mon Jul 1 00:44:28 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF3912002E; Mon, 1 Jul 2019 00:44:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoshifumi Nishida via Datatracker To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-nat64-deployment.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoshifumi Nishida Message-ID: <156196706639.5822.4976381308809192758@ietfa.amsl.com> Date: Mon, 01 Jul 2019 00:44:26 -0700 Archived-At: Subject: [v6ops] Tsvart last call review of draft-ietf-v6ops-nat64-deployment-06 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 07:44:27 -0000 Reviewer: Yoshifumi Nishida Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Summary: Ready This document is a complementary doc for RFC7269 and transport related issues are already addressed in RFC7269. I don't see new issues will be introduced in the scenarios described in this doc. Thanks, -- Yoshi From nobody Mon Jul 1 01:01:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2BE120024; Mon, 1 Jul 2019 01:01:34 -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, FROM_EXCESS_BASE64=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.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 K3Ep811uky_C; Mon, 1 Jul 2019 01:01:32 -0700 (PDT) Received: from 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 AFB3D120046; Mon, 1 Jul 2019 01:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1561968088; x=1562572888; i=jordi.palet@theipv6company.com; 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=O31sWfS4yaDoz/+Cg0R6e/FbIu8815weQc44qvmRD/s=; b=YXxPVfk57jJMb hNoo5eRhqjtAI3fZ5qsc6kfHYrUUKJ0rvltsnO8nksDf2HbY/GCZ1M4eDI2aASQH w4nW+ZLFviHVSkCv3GoDwFD8jhCQ9pfp1VgmLIzLzuKNd8Ugq1yp5fg057oq5eXd pm22yZdbtgYSNXaa4AqBuJq7q8sBXI= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Mon, 01 Jul 2019 10:01:28 +0200 X-Spam-Processed: consulintel.es, Mon, 01 Jul 2019 10:01:28 +0200 Received: from [10.10.10.139] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006312051.msg; Mon, 01 Jul 2019 10:01:28 +0200 X-MDRemoteIP: 2001:470:1f09:495:996:cda7:772b:dc49 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Mon, 01 Jul 2019 10:01:28 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=10854b7c97=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Mon, 01 Jul 2019 10:01:25 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: Yoshifumi Nishida , CC: , , Message-ID: <488C7588-BB11-41F9-9629-8CEAC7888DC0@theipv6company.com> Thread-Topic: Tsvart last call review of draft-ietf-v6ops-nat64-deployment-06 References: <156196706639.5822.4976381308809192758@ietfa.amsl.com> In-Reply-To: <156196706639.5822.4976381308809192758@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Tsvart last call review of draft-ietf-v6ops-nat64-deployment-06 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 08:01:35 -0000 Thanks a lot Yoshi! =20 Regards, Jordi @jordipalet =20 =EF=BB=BFEl 1/7/19 9:44, "Yoshifumi Nishida via Datatracker" escribi=C3=B3: Reviewer: Yoshifumi Nishida Review result: Ready =20 This document has been reviewed as part of the transport area review te= am's ongoing effort to review key IETF documents. These comments were writte= n primarily for the transport area directors, but are copied to the docum= ent's authors and WG to allow them to address any issues raised and also to t= he IETF discussion list for information. =20 When done at the time of IETF Last Call, the authors should consider th= is review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. =20 Summary: Ready =20 This document is a complementary doc for RFC7269 and transport related = issues are already addressed in RFC7269. I don't see new issues will be introd= uced in the scenarios described in this doc. =20 Thanks, -- Yoshi =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 Mon Jul 1 01:05:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D66712004C for ; Mon, 1 Jul 2019 01:05:10 -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, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 6SG8w2D24mhs for ; Mon, 1 Jul 2019 01:05:08 -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 DD2EF12004A for ; Mon, 1 Jul 2019 01:05:07 -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 x61853rX000509; Mon, 1 Jul 2019 10:05:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 37CE42047C3; Mon, 1 Jul 2019 10:05:03 +0200 (CEST) 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 2A0082046F2; Mon, 1 Jul 2019 10:05:03 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x61853Xe025165; Mon, 1 Jul 2019 10:05:03 +0200 To: "Eric Vyncke (evyncke)" , "v6ops@ietf.org" References: <63917e52-db92-a9d6-d7c7-0fa3d73dde27@gmail.com> From: Alexandre Petrescu Message-ID: <9b6886ae-e58f-2193-2e4c-dcc47f6e106f@gmail.com> Date: Mon, 1 Jul 2019 10:05:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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: Subject: Re: [v6ops] RFC that explains that interco links with LL only, are possible X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 08:05:10 -0000 thank you that is it: RFC 7404. It explains the advantages and caveats of using LL only in the infrastructure (interco) links. In my context I use it between cars without infrastructure. It works fine and has same advantages and caveats. I will mention this RFC to my surprised interlocutor. Alex Le 28/06/2019 à 17:23, Eric Vyncke (evyncke) a écrit : > RFC 7404 ;-) > > *From: *v6ops on behalf of Alexandre Petrescu > > *Date: *Friday, 28 June 2019 at 14:13 > *To: *"v6ops@ietf.org" > *Subject: *[v6ops] RFC that explains that interco links with LL only, > are possible > > What is the RFC of v6ops WG that explains that it is possible to use > link-local addresses (only LL, no GUA, no ULA) on a interco between > routers, yet all other subnets use GUAs, and they do see each other? > > This is a fundamental concept used for car-to-car communicaitons (the > link outside is LL-only, and all PCs in the cars use ULAs and can see > each other). > > In a private converrsation I am asked how can this possible, and I want > to redirect to that RFC. > > Alex > From nobody Tue Jul 2 08:03:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB11120181; Tue, 2 Jul 2019 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 nVUuhlvgD7Jk; Tue, 2 Jul 2019 08:03:32 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 9C17A12022E; Tue, 2 Jul 2019 08:03:24 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id y57so18791134qtk.4; Tue, 02 Jul 2019 08:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=My6XXy/h6PAc3H0V5dvDymEFRl/Dr9un8qGpZkZXeQM=; b=Ktu1Q0YdULI+oB9y7b3NsxyuEVb2eQ7pvriN9Fn3x88JuzNXFCew1AmDCm0XpNp73l QnKo87kynWdAOWhbhTpM+kNxgmsriR9d31/wcamuavjdWLDpTEdtOMB3S3bPNcGJNTPc KOwkqhmH1aN7cYqAKNkGZz+0wJmtAr9gNX7+Y12t0E8gr2ciX8Xi16J0EtsP+2Lt9B8E ZNesmb+XlJbJ2+5emv38DJZoh4dpZ62RtXGz/xPQxjzwXqCLgRdBtRIlMZw5H5k9IvAn u70Xy7b4KK5BMybg5lg1j2oo861Yk5uhwfZejiC2OmrgfeMA+GwlyKDBSe4nap/qxoOs yCBw== 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:cc; bh=My6XXy/h6PAc3H0V5dvDymEFRl/Dr9un8qGpZkZXeQM=; b=hXmbLk2nVK1/1FgJp/UxPAwHOyrwEXK5QO5jzgjixKw9HyWHJXanxBOCYuLT5CQY9Q DD6E4VlJeB8yz3Be+QKaSmcO1aVskqpMWhWHMX8NDUMgPg6s0l4I7Wb9cIQMSaZpIwnd fqk64XtfEyPIgDF2IiT9lrraJ2LYxYnoMVt+fK0RindyVc4s2gu919sntJqh+IQN0PzT QpuOqTgmu237Y/HlhlsSc9S7Zjp+EW0CGatdP2b7Xy0wOzSUfuN5063m6kPWLTXARs9V uJIxL4WwgY1HhHaeX6SXZOXDVGuRPLRw+qq0/O9aErECC5HXJxAZWW5iJfiUFxeidiiq 16yQ== X-Gm-Message-State: APjAAAVFIJPJyxlf2IgNddezNj+NHRxvVmLylh2b9z/NGJNAO6k+E3au baHdw7dWotXqjjswFYtyIYbl8QFU3iK73Dqrl1qiUy66n5Y= X-Google-Smtp-Source: APXvYqzk2v+S11lm3NBQwIVZaFCX/RBZGOYlz0xODwp99qiI5brzrgVvaU5EfIC8TIa4GafW6x4twCa2jf4grKCoh8I= X-Received: by 2002:a0c:91bc:: with SMTP id n57mr27089432qvn.141.1562079803305; Tue, 02 Jul 2019 08:03:23 -0700 (PDT) MIME-Version: 1.0 From: Jen Linkova Date: Wed, 3 Jul 2019 01:03:11 +1000 Message-ID: To: V6 Ops List Cc: 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 15:03:34 -0000 Hello, I wrote a short draft to discuss and document an operational issue related to the ND state machine and packet loss caused by how routers create ND cache entries for new host addressed: https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ (taking into account some vendors have implemented one of the proposed solution already, I guess it's a well-known problem but it might still worth documenting) Comments are appreciated! -- SY, Jen Linkova aka Furry From nobody Tue Jul 2 08:38:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07F512030F; Tue, 2 Jul 2019 08:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 pOnKICI-HHU3; Tue, 2 Jul 2019 08:37:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8318A1202CF; Tue, 2 Jul 2019 08:37:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 44BF4380BE; Tue, 2 Jul 2019 11:35:44 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 46D4DBE6; Tue, 2 Jul 2019 11:37:36 -0400 (EDT) From: Michael Richardson To: 6lo@ietf.org, Jen Linkova , 6tisch@ietf.org CC: V6 Ops List , 6man <6man@ietf.org> In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 15:38:02 -0000 --=-=-= Content-Type: text/plain I think that the discussion here is particularly relevant to constrained devices/routers on route-over MESH(RPL,etc.) networks. I also think that for L=0 networks, which RPL creates with RPL DIO messages rather than (just) RAs, and 6LRs that need to support join operations (like draft-ietf-6tisch-minimal-security) this may matter. In particular, in the minimal-security case, we need to partition the ND cache such that untrusted (unverified) malicious pledge nodes can not attack the ND cache. The behaviour 2.2.1. Host Sending Unsolicited NA, should probably never flush an old entry out of the ND. I think that under attack (whether from untrusted pledges, or from p0woned devices already on the network), it is better to prefer communication from existing nodes rather than new ones. 2.2.1.2 mentions this. {typo: -It's recommended that thsi functionality is configurable and +It's recommended that this functionality is configurable and } I didn't really understand 2.2.2: is it exploiting some corner case in the spec, or maybe just some part I am not well clued in about. So maybe an extra paragraph to explain things. I kinda like the ping all routers trick. Jen Linkova wrote: > I wrote a short draft to discuss and document an operational issue > related to the ND state machine and packet loss caused by how routers > create ND cache entries for new host addressed: > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > (taking into account some vendors have implemented one of the proposed > solution already, I guess it's a well-known problem but it might still > worth documenting) > Comments are appreciated! > -- > SY, Jen Linkova aka Furry > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0bej8ACgkQgItw+93Q 3WWRWQf+KrGpxzGcMbUnLLcYSG0w8d12bfMAeoDFhTzBLgN7ABvk2ahSPve9n/q6 RpQAXkAl2uO7CGxvVTLN3cVd6f5+J73/PoJwF6gQQQuzQ31n19EN1wssXwTmWWsK K5FQSvJKuOemPVXor5PH4B2VWhfYJ2jastDO4b2IdTYgeRquwpbW9xpuZbaBIIxV Axv7Mh7G1nQXpJOmGYhhVC3BMa6YuoDIMMO7Q37d+UgkL8dLX9tygPuHq0aq41z3 wkXpMI7kcHNa5idunraD0jBmDMxvOsM6keH4Qgw4DSiORTbJfilJbrbSzFCGDsiB bmqtlFeZ0eC38RtYV2ANY5M5lihalA== =OS23 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 2 10:54:28 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E751206CA; Tue, 2 Jul 2019 10:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 4Jobn6_q2T3W; Tue, 2 Jul 2019 10:54:19 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5545F1206BC; Tue, 2 Jul 2019 10:54:19 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id w79so13821719oif.10; Tue, 02 Jul 2019 10:54:19 -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=RTnTVP37YZG5NN9wgMIHC+ZHgt8WgOFzTeNK/Xz89Cw=; b=WHHt5I8iYBruBxgBvkgrfe3PIWYy/tClkYE3pJeLdvGnua7wevwOF31gTI8JHoKBh7 ZsgVty6QG/9k3RAcGadx0u3IuXGsG2rtxq+kb6MWTaYxpAz3CW05IHmel6tAsIKhPWxb hfiphklzQ6dFWmwNBBV44FTu8st4tU5H+McuH3pjxptaipUVeATMpCHdU4iwHHRZP4lA Eyz3FEvk6zD8MBLhnkkmr4uSGtB3ZlE6K6Dnm81bkz6DfxD4tE/4aytOAjSeuax1NUN0 JrFar/sPdLv+mHJ1e4AST/xZx4OI8Ztr1HTmhShgD986/yrOrkxDfAyZyTN0r7IyeYLm hy3Q== 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=RTnTVP37YZG5NN9wgMIHC+ZHgt8WgOFzTeNK/Xz89Cw=; b=g2OW68hMQxhHuAlAMmwgt6wHFmfavMiXHB7H/aP/++ig33VC4iqjSPhQOOOQ0ie+Vi LtXhDiR2wGk5RMhGuYq9idsHooKbKAuDhENjPHOXprvaSkzykwQ1ahH1L0ZWq7KweFmA w2LBa52ZYyHzyviujALJzZQLwSX2pXyuT4yQ7MOLjdTWrbst2Sn5xXevIc2k1SIBgBT7 A3YLnnOuFMmvSv6gCO2GryIoBZB6ZgRQLuE/Jkj62pr+2E3xnLf7UlOBu8ZV3M9AncjL NqfkQ2VH8ja+JhCkpuEaSPOAp/jeSPREndf8QxLq8QXHhs2VJQaWBD+2ILp08Y3KXGe/ F+mg== X-Gm-Message-State: APjAAAVulM6SzleBSTXNyV7ZF7mp0JQjs09nuTCw69m3QduMKsCb2sBs 94EFdyguFMdidYA2W9qrLCE= X-Google-Smtp-Source: APXvYqwY6p+/BkHPOz9X+LeHw0vD5b8BW9wmSlQp7WmDndJpsUfyXfbbEjQLhG+qEAt4nMlFyAZUAQ== X-Received: by 2002:aca:4787:: with SMTP id u129mr3504802oia.139.1562090058683; Tue, 02 Jul 2019 10:54:18 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::101e? ([2600:8802:5903:df16::101e]) by smtp.gmail.com with ESMTPSA id t9sm5457554otm.35.2019.07.02.10.54.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jul 2019 10:54:17 -0700 (PDT) From: Fred Baker Message-Id: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7688EA57-AB51-4D22-BFF6-3A47FA7F1CAD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 2 Jul 2019 10:54:15 -0700 In-Reply-To: Cc: V6 Ops List , 6man <6man@ietf.org> To: Jen Linkova References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 17:54:21 -0000 --Apple-Mail=_7688EA57-AB51-4D22-BFF6-3A47FA7F1CAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for this. As usual, Ron and I are looking for supportive = commentary on the list in vetting agenda items. My big question at this = point is whether (following Michael's lead) it belongs in v6ops, 6man, = or 6lo. Operationally, do you see it in non-IOT-attacks? > On Jul 2, 2019, at 8:03 AM, Jen Linkova wrote: >=20 > Hello, >=20 > I wrote a short draft to discuss and document an operational issue > related to the ND state machine and packet loss caused by how routers > create ND cache entries for new host addressed: >=20 > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ >=20 > (taking into account some vendors have implemented one of the proposed > solution already, I guess it's a well-known problem but it might still > worth documenting) >=20 > Comments are appreciated! >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_7688EA57-AB51-4D22-BFF6-3A47FA7F1CAD 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+AFAl0bmkgACgkQEhdRnd2G P+CfOg//cUohdr+Z51PeQK3b3ZSSHIYlfncVJDwuTtQanZ8cw/wukKW9s8n4tK/8 mdURcLv+OCNe3wz16bw/D+Hpru7zOFNtsRoY12MgdpWDqhDUaCAuo38zsnIY5kaJ msAmPqB+mAV+MKfe/Hjk3b27Vf9b9N6ISl/+4aN6NsWUGhHwZzAwXRBnlAxvOKKJ IbAwmrytLtdW3b1Ht9tVWDGML35NkfR/KEXGoXgMSWjztYGtbqtrWYYPFgfZXsqu Ll+DGdAkBALmzRIB8cnI8ARc9hWLkVpwFF/j13LdcmTjahJwahg8YpMHQ048uDCo i1sroeFLE3NDm5xATyU+NJWfw6r25FqvbcLh6BQ0VGwCAspVjcFo2FfQoTz/xlRm 9MSdvtn0wDWKAqa6waCZ8s7+OckhynkqNLAylYyJRl1gUa7oagxYv3RAiOeQJWiT gvjaTHgTJHIcW/edSBJAe4redg6gqWziC3EpqzFO9xSucA9hMqmB62ISFQ4vkHyg pRvKV1sO7BIN3ZSdjSVFegdPjdIHFwkTAjYR5xg9KH1vctDdROB4uA6LUeGiqMIc eJa3v9gg06gLudyPdYsHaXHag66Cjp+Rgl6XTF6tEPqZsf2ncpuo+dS0M+jOMV0y ++8llbfKEqZ1RxzwRl1tRhzpodGqJjg2dcY9AdCc6TLOal7oAU8= =Fg23 -----END PGP SIGNATURE----- --Apple-Mail=_7688EA57-AB51-4D22-BFF6-3A47FA7F1CAD-- From nobody Tue Jul 2 13:50:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5829A12011D; Tue, 2 Jul 2019 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 t2QY-9KH2GZz; Tue, 2 Jul 2019 13:50:17 -0700 (PDT) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 6CAEA1200E9; Tue, 2 Jul 2019 13:50:17 -0700 (PDT) Received: by mail-wm1-f50.google.com with SMTP id u8so2476606wmm.1; Tue, 02 Jul 2019 13:50:17 -0700 (PDT) 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=CERycPsBef0P8DUhE8haT8zA11qPAo6jI8gZ4rsXqjM=; b=EpwSHYenVbHi+91C/t+xieB4RWOh5Gooqer0Ft0o0f6stf4bj+BJNFKcC1f0V0Z0hV FQ4F2E5l9PxeIRsMzAhM17sgAd8JshzSpDSB9i6kYo8Kv6s4g2v06aluwDG6iM4xK2iB xCDloQUU9r4AFP0nOC5DhMa/j/EjFMUdZ8gHaObfGpE8PohI8rOerjmn94goJeL624Gx OA7ROCTHVEekJ9ha1iigS+iK5HY+G5R6zWF9006fWZfkmU4S2n3GRLJilgdPyCfttyE+ eAlvo8PBUEvDonxcqaaTllfW0QxuMBEirDWdkT/fRByywMWXRgKL3QpwWFwlBO0vjwzW 0cKQ== X-Gm-Message-State: APjAAAVWzs59p1Y1gpn2wvP12QI6uqJMs6EWqK3IgAOc0PFwc4BOdgz8 pHYNY5JbiJvw5ln+gf1jsChDVNnJd+7OnosucBkjjU55 X-Google-Smtp-Source: APXvYqwIqEE8IDgWO0WgmDr9ls076w3OBGQyLHcZ17rHAfqIjCvuXvJsxv0QPBk+t7YACH15bxchenpaTwjoWLXKuLA= X-Received: by 2002:a05:600c:224d:: with SMTP id a13mr4473369wmm.62.1562100615472; Tue, 02 Jul 2019 13:50:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 2 Jul 2019 13:50:04 -0700 Message-ID: To: Jen Linkova Cc: V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000049eae3058cb8e44f" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 20:50:19 -0000 --00000000000049eae3058cb8e44f Content-Type: text/plain; charset="UTF-8" At Wed, 3 Jul 2019 01:03:11 +1000, Jen Linkova wrote: > I wrote a short draft to discuss and document an operational issue > related to the ND state machine and packet loss caused by how routers > create ND cache entries for new host addressed: > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ I've read ver 00 of the draft. I see the problem it discusses is worth considering. Some specific comments on the draft follow. - Section 2.2.1: I'm not sure if sending an unsolicited NA for an optimistic address really respects the sense of RFC4429 Section 2.2. The high level rationale of the restrictions is to avoid "disrupting disrupt the rightful owner of the address in the case of a collision." Even if the RFC text does not explicitly prohibit that (as long as the override flag is cleared), if we allow to send such an unsolicited NA, it can result in the creation of a new neighbor cache entry for that address (actually, that's the purpose of it in the sense of this draft). But what if there's actually a collision with another "rightful owner" of it? Isn't it considered a kind of interference that Section 2.2 of RFC4429 tries to prevent? It may still be justifiable after some more detailed analysis, but I think we need more explicit discussion in this sense. - Section 2.2.3.2 o Responding to RS with RA is not instant but delayed by a random interval. Additional delay would compromise the idea of populating the routers ND cache before the return traffic to the host GUA arrives. I don't understand what's the problem here. Does it assume the delay of sending RA in response to the RS means delaying the creation of the neighbor cache entry? My interpretation of RFC4861 is that the delay only applies to sending the RA. When to create the neighbor cache entry is up to the router implementation but I'd expect it's normally upon receiving the RS. At least one implementation that I know of behaves that way. Or, if this means something totally different than that, I have no idea about what's the problem, so more clarification would help anyway. - Section 2.2.3.2 o Some wireless devices are known to fiddle with ND packets and perform various non-obvious forms of ND proxy actions. In some cases unsoliciated NAs might not even reach the routers. I suspect you meant RS, not NA here. -- JINMEI, Tatuya --00000000000049eae3058cb8e44f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Wed, 3 Jul 2019 01:03:11 +1000,
Jen Linkova <furry13@gmail.com> wrote:

&g= t; I wrote a short draft to discuss and document an operational issue
&g= t; related to the ND state machine and packet loss caused by how routers> create ND cache entries for new host addressed:
>
> https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/
I've read ver 00 of the draft.=C2=A0 I see the problem it discusse= s is
worth considering.

Some specific comments on the draft follo= w.

- Section 2.2.1: I'm not sure if sending an unsolicited NA fo= r an
=C2=A0 optimistic address really respects the sense of RFC4429 Sect= ion 2.2.
=C2=A0 The high level rationale of the restrictions is to avoid= "disrupting
=C2=A0 disrupt the rightful owner of the address in th= e case of a
=C2=A0 collision." =C2=A0Even if the RFC text does not = explicitly prohibit that
=C2=A0 (as long as the override flag is cleared= ), if we allow to send such
=C2=A0 an unsolicited NA, it can result in t= he creation of a new neighbor
=C2=A0 cache entry for that address (actua= lly, that's the purpose of it in
=C2=A0 the sense of this draft).=C2= =A0 But what if there's actually a collision
=C2=A0 with another &qu= ot;rightful owner" of it?=C2=A0 Isn't it considered a kind of
= =C2=A0 interference that Section 2.2 of RFC4429 tries to prevent?

= =C2=A0 It may still be justifiable after some more detailed analysis, but I=
=C2=A0 think we need more explicit discussion in this sense.

- S= ection 2.2.3.2

=C2=A0 =C2=A0o =C2=A0Responding to RS with RA is not = instant but delayed by a random
=C2=A0 =C2=A0 =C2=A0 interval.=C2=A0 Add= itional delay would compromise the idea of
=C2=A0 =C2=A0 =C2=A0 populati= ng the routers ND cache before the return traffic to the
=C2=A0 =C2=A0 = =C2=A0 host GUA arrives.

=C2=A0 I don't understand what's th= e problem here.=C2=A0 Does it assume the
=C2=A0 delay of sending RA in r= esponse to the RS means delaying the
=C2=A0 creation of the neighbor cac= he entry?=C2=A0 My interpretation of RFC4861
=C2=A0 is that the delay on= ly applies to sending the RA.=C2=A0 When to create
=C2=A0 the neighbor c= ache entry is up to the router implementation but I'd
=C2=A0 expect = it's normally upon receiving the RS.=C2=A0 At least one
=C2=A0 imple= mentation that I know of behaves that way.

=C2=A0 Or, if this means = something totally different than that, I have no
=C2=A0 idea about what&= #39;s the problem, so more clarification would help
=C2=A0 anyway.
- Section 2.2.3.2

=C2=A0 =C2=A0o =C2=A0Some wireless devices are k= nown to fiddle with ND packets and
=C2=A0 =C2=A0 =C2=A0 perform various = non-obvious forms of ND proxy actions.=C2=A0 In some
=C2=A0 =C2=A0 =C2= =A0 cases unsoliciated NAs might not even reach the routers.

=C2=A0 = I suspect you meant RS, not NA here.

--
JINMEI, Tatuya
--00000000000049eae3058cb8e44f-- From nobody Tue Jul 2 22:09:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9D612018A; Tue, 2 Jul 2019 22:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 jsU6hjeiOYWd; Tue, 2 Jul 2019 22:09:13 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 BA566120111; Tue, 2 Jul 2019 22:09:13 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id y57so1191690qtk.4; Tue, 02 Jul 2019 22:09:13 -0700 (PDT) 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=ppYUcI4v5ppyGc6e1PH5pB9OVyjOoYHgVBQ4i8i9fMA=; b=JUJ2rQTOQlkTb/N0ys0gy9W/7OtcHTmQuq/zn8hltAq7w4KDFyjw8T3HoyEhYbrtC+ PBNlTo0T85O95LOsXcQjoZCL/bPR/KzRPzyP5qsi28I+p1B+0wSGQLHvE1m6l0RLNII+ 5o/wEf8tO2rzmRV9vv8+XTZy0YU7GY0AARGdOnZSBp2YbKxNvF/nJD08haXYwq1zlNh6 cDjd4Nig08s7ShrAurKe/9hsD5+sXkfEok6c6kP+Sc+3nppHoKsR2BfSpXWSLsWuSkkL h7gVou6FnAWSzuuVc7FULVd2NfvNo0gk0nKDRle5RBPxhFvEpOK+2hS7LKi+zgNUrzxt 3H5w== 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=ppYUcI4v5ppyGc6e1PH5pB9OVyjOoYHgVBQ4i8i9fMA=; b=CGl4lPGJ8PUexfV0vWrC1a91n+T101wXSC5Sx9fNfo45WDcPzSXm2cDr7jSRES48AP BJSsjwTgHK0I9iWwF1pJw0uKG4yeqDISyyRW+DUNpQhwOIfRifEkSQt1mhxU7oYSPPv7 w9JdpnBgRew3C2XyKCNp4IlLV445RoMehOx70Ol4dA1862TJy32UPsxUxGo97j7WolPW hq+oT4xVj+ukTSRN4AljusocNn/Ls6XtmwF1s7UBVKfHDkmrXBiGSMif9SdOjoEZj/R3 PDx2ySK+W9BWW680uuV1DfjrPuNuimYfwUDNCEn0WRHLMsRrCeYo1GbF1J1N35rXe1JC 2Yfg== X-Gm-Message-State: APjAAAVMmYXtNVNbMxKrTzBanE2aSHhhhqHHO5O6i1RHx09wIiTA1Z/s iEgUvBAd+7C9mqphu53ylcTwwl68/sIgrY8rcEQ= X-Google-Smtp-Source: APXvYqw2kmZDniCT8bEqJw4Pfz6IwSo6kcWGgxJFxQYYuEp80jaQiYzZefRyuZUuJVL/1CyB0ZxXYiuBZFoVDjFhIoA= X-Received: by 2002:a0c:81f0:: with SMTP id 45mr30745555qve.13.1562130552616; Tue, 02 Jul 2019 22:09:12 -0700 (PDT) MIME-Version: 1.0 References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> In-Reply-To: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> From: Jen Linkova Date: Wed, 3 Jul 2019 15:09:01 +1000 Message-ID: To: Fred Baker Cc: V6 Ops List , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 05:09:16 -0000 On Wed, Jul 3, 2019 at 3:54 AM Fred Baker wrote: > > Thanks for this. As usual, Ron and I are looking for supportive commentary on the list in vetting agenda items. If you see enough comments, I'd like to present this. I guess I'd need 5 mins for explaining the problem and options for solutions and maybe 10 mins for discussion? >My big question at this point is whether (following Michael's lead) it belongs in v6ops, 6man, or 6lo. Well...IMHO it's in the grey area between v6ops and 6man. It's an operational issue. Caused by ND state machine design (I'm really not a fun of a situation when legitimate packets are dropped by design). The solution might be in v6ops or in 6man - we can either say 'oh, just let hosts ping the routers or tweak their probing logic' or we might look at ND state machine to see if anything could be done there. > Operationally, do you see it in non-IOT-attacks? I have no experience and very, very limited knowledge of IOT area. I do see it as an operational issue on IPv6-only WiFi. I'd have never expected it but users do notice when it takes 5-10 seconds for their phones to start using WiFi. I'd be happy to consider it a cosmetic issue ("everything will start working, just be patient" but by number of complains it competes with 'Spotify client is broken' one... So I believe we shall at least try. > > On Jul 2, 2019, at 8:03 AM, Jen Linkova wrote: > > > > Hello, > > > > I wrote a short draft to discuss and document an operational issue > > related to the ND state machine and packet loss caused by how routers > > create ND cache entries for new host addressed: > > > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > > > (taking into account some vendors have implemented one of the proposed > > solution already, I guess it's a well-known problem but it might still > > worth documenting) > > > > Comments are appreciated! > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > -------------------------------------------------------------------------------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > -- SY, Jen Linkova aka Furry From nobody Tue Jul 2 23:52:36 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C311201E0; Tue, 2 Jul 2019 23:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 igrQJ-hym1bW; Tue, 2 Jul 2019 23:52:10 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 DA9921201E5; Tue, 2 Jul 2019 23:52:09 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id a15so1358395qtn.7; Tue, 02 Jul 2019 23:52:09 -0700 (PDT) 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=im/t12M9nQtGO7XKwA/ufAEUDRiVtugobyy8j63/5j4=; b=PY+MDe+ADVLyoZ/xCCCbvmPc9GuuIG+tq/l6SpIvwl7EYEUqTnRKTarABbeVf7VzWL xQ76vmLk4IlmsaGO7/xLQTrrrIX46vefvOnPpzPPGlfy9DvsB2E1d9gWZmJ+nt9+T4vH H73f+ckxPE1yi+wyYIhXssYFU1xl3oBB8bf/Rf0Owtfl0MSyc70R6mNZ2b3UnGAC6xlt PGhphkwmIZkCbTPPiy2lsm0px2ca5qmZws9CT1jFNIhjeYDq9PSS29wyXMwH/dgI66hu En1jX7OU12byBnFUxM1s4+erN7Cn6InpJIlKD7QVZhRXmTYZXgSY56fjmQ+Sij/WaT+F Rbvg== 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=im/t12M9nQtGO7XKwA/ufAEUDRiVtugobyy8j63/5j4=; b=qvP/2cVDDJPYPOJjfDUaLqZhoqds1iIvYZAvtjHG+i2F/OxcQ7JHNs8KKdSYbM5Sia sWJ2iEdpJ0nV/cg5l5mf7Ys+UsUeBLDjF0mWYxQUq17HeMjAP5er5PgqIEVr0JDBnG29 VvosxptIKJsOzj7gxFw4s9bTW96h8oxLazOOXUNP2Jcn5jlp7pU/no40wlVRBqtt+2MP bP5j3uXtEGVDbr2T5ki64yHgIBSrh0vhm8+RqqnlYBldaYjOhbeMpx5NuYRv/ZpzsU7y rMIRII7ZSH5a2ObfnuvoFo3QpWoFXl8Ijc792kOMlNXU73AMxVz2cJiwzZZud4EBJG+B Tggg== X-Gm-Message-State: APjAAAXcFoXyeITrGvNWZom9FMfImh/7MsjU7aWGT3MD556mz9dI5PAT gZetkjw6k0ev/18iaP8Q9JWrLnAwQDrdTvDyc+M= X-Google-Smtp-Source: APXvYqylCn8yOtubAKuTfkEbbbc257hGmn0bDdGVYhDhhSXuxp4pwkDNq+U0QR7tDDQSolM4Zf5HjuWvjG9MqUFkRpI= X-Received: by 2002:a0c:81f0:: with SMTP id 45mr31134286qve.13.1562136728799; Tue, 02 Jul 2019 23:52:08 -0700 (PDT) MIME-Version: 1.0 References: <5377.1562081856@localhost> In-Reply-To: <5377.1562081856@localhost> From: Jen Linkova Date: Wed, 3 Jul 2019 16:51:57 +1000 Message-ID: To: Michael Richardson Cc: 6lo@ietf.org, 6tisch@ietf.org, V6 Ops List , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 06:52:13 -0000 On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson wrote: > I think that the discussion here is particularly relevant to constrained > devices/routers on route-over MESH(RPL,etc.) networks. > > I also think that for L=0 networks, which RPL creates with RPL DIO messages > rather than (just) RAs, and 6LRs that need to support join operations > (like draft-ietf-6tisch-minimal-security) this may matter. Disclaimer: I have very limited knowledge in that area. > In particular, in the minimal-security case, we need to partition the ND > cache such that untrusted (unverified) malicious pledge nodes can not > attack the ND cache. The next version of the draft will have much more details on discussing the security considerations indeed. > The behaviour 2.2.1. Host Sending Unsolicited NA, should probably > never flush an old entry out of the ND. I'd say that the router behaviour for creating a STALE entry upon receiving an unsolicited NA should be the same as for creating an entry for any other reason (e.g. for receiving an RS with SLLAO). The same safety rules shall apply. > I think that under attack > (whether from untrusted pledges, or from p0woned devices already on the > network), it is better to prefer communication from existing nodes rather > than new ones. 2.2.1.2 mentions this. I guess your routers do purge old stale entries? > {typo: > -It's recommended that thsi functionality is configurable and > +It's recommended that this functionality is configurable and > } Thanks, will fix in -01. > I didn't really understand 2.2.2: is it exploiting some corner case in the > spec, or maybe just some part I am not well clued in about. So maybe an > extra paragraph to explain things. It's just using the standard ND process: when the node B receives an NS from node A and that NS contains the node B address as a target address and SLLAO contains node A LLA, the node B would respond with NA and would create a STALE entry for the node A - https://tools.ietf.org/html/rfc4861#section-7.2.3 > I kinda like the ping all routers trick. I think it's a hack ;( we do have a mechanism for communicating neighbours addresses/reachability called ND. It would be nice to utilise its machinery. Pinging creates additional overhead on routers and could get filtered. But I'd not be surprised if it's the only way we have realistically to mitigate the issue.. > > Jen Linkova wrote: > > I wrote a short draft to discuss and document an operational issue > > related to the ND state machine and packet loss caused by how routers > > create ND cache entries for new host addressed: > > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > > (taking into account some vendors have implemented one of the proposed > > solution already, I guess it's a well-known problem but it might still > > worth documenting) > > > Comments are appreciated! > > > -- > > SY, Jen Linkova aka Furry > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- SY, Jen Linkova aka Furry From nobody Tue Jul 2 23:59:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F83120279; Tue, 2 Jul 2019 23:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 TVG-87xjcvqK; Tue, 2 Jul 2019 23:58:49 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 935701200B5; Tue, 2 Jul 2019 23:58:49 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u13so2343861iop.0; Tue, 02 Jul 2019 23:58:49 -0700 (PDT) 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=qFCGHBT1SIh4FL4n/elQ+WU9vBWZUrMBrnzLeNASQmY=; b=SEdUoO0+rZMsOyCF6MJdNfWNFe3OuKanNCWbp5bC2zI8eO19pt8hsV6iWHjXkv2b2K kB66wWqXXE+IKNUcBJUTVmSpN6QRveypHK6EyLYQAd2EAmtT9QjdpuD6z5AKhEF1WEYA JO7aRvtVDB9cxJgU/Zj6Q6q95R+0gOowMwXCXJ6A5MDT3rM3wnbdDTG2rkz2KqHEFIgM ytvPzOKLlIwPp/lw4OSPzZDy73AuAZh4NY5XzgNaffbbujYADPC+cZSdxDvFrdpiZnJg nYnOk7iaZBd0qiwksu+clZ6vLj1J3RSLFxrGtqgnAV+spt6Mmaz6NUZBlC0XxRJL46NN suYw== 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=qFCGHBT1SIh4FL4n/elQ+WU9vBWZUrMBrnzLeNASQmY=; b=ZVZL7yRUmiIKNDsVj8MQJnmC36DogPduhoOJAXAwIrcxhtU6IYaMjUzQFZfYZfwKQI SZtgnpTjqMbWCJ1Us72Ng+lSBs2qEQnrFzM677DSC67AIjQ1fkAmbT85PDfHoN6iLtPI cvxbBdI8MnmdHWdN3VgR+sZkil3rAZd4XeMPkIHL0BZ1uDUuATgPzWwXbyJO3tDh2f6x Q+Ha99U7DjJGmRWQpVprKOH++z8dFIPElC+3QurzsCmzCMTgiWW945YtQ8Kl61785Suz /ZOjdfTrZY2kGYdz0wEkoLQ4OKdDveQr5VuZ/JDxJtVtRg3bC/qemiq3lDVqljnSiUSM dNMQ== X-Gm-Message-State: APjAAAXHKNr2ISdRrZnOgNIi7QEi7kMOLb2ZmiBswD46pCSJQOlbwbmR OUjPC+y5eo/5BcrkNJGBqvmJI5NK8S16fg6fqGw= X-Google-Smtp-Source: APXvYqyxZxKuuvgUunv3RbnIQ1dNcVUvfWp24LQbIh2H73NQ+pcOWv4JHC/FMlHa0fHXfaNXlL711bbHgKbc7vEZAHY= X-Received: by 2002:a5d:87da:: with SMTP id q26mr37691012ios.193.1562137128988; Tue, 02 Jul 2019 23:58:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Loganaden Velvindron Date: Wed, 3 Jul 2019 10:58:37 +0400 Message-ID: To: Jen Linkova Cc: V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000a9f4c2058cc164e2" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 06:58:53 -0000 --000000000000a9f4c2058cc164e2 Content-Type: text/plain; charset="UTF-8" Comments inline On Tue, Jul 2, 2019 at 7:04 PM Jen Linkova wrote: > Hello, > > I wrote a short draft to discuss and document an operational issue > related to the ND state machine and packet loss caused by how routers > create ND cache entries for new host addressed: > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > (taking into account some vendors have implemented one of the proposed > solution already, I guess it's a well-known problem but it might still > worth documenting) > > Comments are appreciated! > > >From abstract: user-visible connectivity issues when a new (not beeing seen on the beeing->being. -- > SY, Jen Linkova aka Furry > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000a9f4c2058cc164e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments inline

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 2, 2019 at 7:04 PM Jen Lin= kova <furry13@gmail.com> wro= te:
Hello,

I wrote a short draft to discuss and document an operational issue
related to the ND state machine and packet loss caused by how routers
create ND cache entries for new host addressed:

https://datatracker.ietf.org/doc/= draft-linkova-v6ops-nd-cache-init/

(taking into account some vendors have implemented one of the proposed
solution already, I guess it's a well-known problem but it might still<= br> worth documenting)

Comments are appreciated!


From abstract:
user-visible connectivity issu= es when a new (not beeing seen on the=C2=A0
beeing->bei= ng.

--
SY, Jen Linkova aka Furry

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000a9f4c2058cc164e2-- From nobody Wed Jul 3 00:10:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3481203E0; Wed, 3 Jul 2019 00:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 Va2QrHviiwUZ; Wed, 3 Jul 2019 00:10:10 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 A52381201E2; Wed, 3 Jul 2019 00:10:10 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id w17so1373362qto.10; Wed, 03 Jul 2019 00:10:10 -0700 (PDT) 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:content-transfer-encoding; bh=46hMSdp8z6SCAsokKFjuCmUGhJT97/5DY1BNaV107/w=; b=dMsMXmFtqyTB5X/7nc8Fk4teuvKaJJ/iTItVp9RX+yZ5vbx+i2N7IL/VKLgbOVnRgj DKOknEohy4Jp6Vc9tI6heWbIgSKzHOsujp4r/Yaorhp124QDMh1G++mnwqcSNMACfRgL uuvaFdU65/0wedO5hGxSHQtb9oN2I0CaBVsKsphQhVgSbcvVv+LvlxqUpyHP/UNRJFNP hZVHwFCgiW5M+HSlLme0Gh83ppdcjAXJBavbwvQGLq/i0G1YyZvZSRdJojj8qvrw+u9g swzURpMgviuhF8qLKlIf1PFrfO9N3lph7jmTVYp4e3wyvwB83B2WQpzec/N6DPXDHGCx zRQw== 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=46hMSdp8z6SCAsokKFjuCmUGhJT97/5DY1BNaV107/w=; b=dXqh49SEoyeG+9yKcBDG+7z51jqus1Y54tfQwKTt6MWKqXX7WLiR+j1SvY7b2W0BT3 RCMVcKv2m7YY5v9ZCMzWXpTDqOTh5DajqelzdkPpiRlVG5aeOpayjaGNwrEafZlipmeY sXl3fASVF0RuU2Fr9hLx+JsbJHdfwDGXONo/AwOBc5Kt9IZCod0TFrUw5SyViJXAdLNq IcuOPeGbsIs1rTpBUbmHaVq2yqYYKgMFGU3TA+AtjhnZGCGEaNiiJzZHk0B9O89SjwoP t7gyFPAVnYGj3d0pyOoEe6aGLHffSTUNcRQhAmWzn/NNiSmBUEdnwxJJYQ4uGyGwwAEu vNOA== X-Gm-Message-State: APjAAAUPjlERwCbZ0Zd9dgCayOi/0LLsrpnT+wMLEHb+gr4G+0SfgTQ5 wx49TL3jnD7arxusX19DPlDjrijpDLn9pSL8GaQ= X-Google-Smtp-Source: APXvYqwfbSG6QsQsjahYJIanv+QuMW1eGp9b2/rDIb8yLzCnh/K0Fzq2peW9jievzkwDmbEJg53zNYsSdgYiBBV3D80= X-Received: by 2002:a0c:bc07:: with SMTP id j7mr30929759qvg.76.1562137809576; Wed, 03 Jul 2019 00:10:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Wed, 3 Jul 2019 17:09:58 +1000 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: V6 Ops List , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 07:10:13 -0000 Jinmei-san, Thanks a lot for your feedback. On Wed, Jul 3, 2019 at 6:50 AM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > Some specific comments on the draft follow. > > - Section 2.2.1: I'm not sure if sending an unsolicited NA for an > optimistic address really respects the sense of RFC4429 Section 2.2. > The high level rationale of the restrictions is to avoid "disrupting > disrupt the rightful owner of the address in the case of a > collision." Even if the RFC text does not explicitly prohibit that > (as long as the override flag is cleared), if we allow to send such > an unsolicited NA, it can result in the creation of a new neighbor > cache entry for that address (actually, that's the purpose of it in > the sense of this draft). But what if there's actually a collision > with another "rightful owner" of it? Isn't it considered a kind of > interference that Section 2.2 of RFC4429 tries to prevent? Very good point. Two things are probably worth considering here: 1) Actions prohibited in the Section 2.2 of RFC4429 (sending NS from the optimistic address and sending RS with SLLAO) would both *update* the ND cache entry if such entry exists. So I guess the risk of potential disruption is higher. What the draft suggests is only creating an entry if one does not exist already (it would also update INCOMPLETE entry). If the entry exists (for the "rightful owner" ) the only thing which might happen is REACHABLE -> STALE change which should not disrupt the traffic flow. 2) the case when a rightful owner of the address exist but there is no ND cache entry would probably mean there is no (or minimal) disruption anyway - as there is no traffic to that address. The only corner case seems to me 'there is an incomplete entry so the router has started ND process and now the new owner came". > It may still be justifiable after some more detailed analysis, but I > think we need more explicit discussion in this sense. Sure, I'll add more details in -01. > - Section 2.2.3.2 > > o Responding to RS with RA is not instant but delayed by a random > interval. Additional delay would compromise the idea of > populating the routers ND cache before the return traffic to the > host GUA arrives. > > I don't understand what's the problem here. Does it assume the > delay of sending RA in response to the RS means delaying the > creation of the neighbor cache entry? My interpretation of RFC4861 > is that the delay only applies to sending the RA. When to create > the neighbor cache entry is up to the router implementation but I'd > expect it's normally upon receiving the RS. At least one > implementation that I know of behaves that way. Ah, thanks for pointing that out. I somehow assumed that the delay might affect the entry creation as well. I'll fix the text in -01. > - Section 2.2.3.2 > > o Some wireless devices are known to fiddle with ND packets and > perform various non-obvious forms of ND proxy actions. In some > cases unsoliciated NAs might not even reach the routers. > > I suspect you meant RS, not NA here. Yep, copy-n-paste is to blame.. --=20 SY, Jen Linkova aka Furry From nobody Wed Jul 3 01:14:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E4812069D; Wed, 3 Jul 2019 01:13:56 -0700 (PDT) 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, 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 header.b=dL7mHtBW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=r2e4/bxx 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 dI68wlfcPjOr; Wed, 3 Jul 2019 01:13:54 -0700 (PDT) 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 EDD0F1204E0; Wed, 3 Jul 2019 01:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3969; q=dns/txt; s=iport; t=1562141633; x=1563351233; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bI2Pj3V1pAP9pU6pvLZCaBKrMR6Xp8ayxbug/02yrhA=; b=dL7mHtBWOZa4sQscy1IacyIyYlrtt2KczeXmzuEpa5rww3CunD/7UIHj r/D7SElx4SgPBGSzdf/o4KI4w++wrCrQgTsIddzQs/f+2t9ZIeanxIwLz e9ULOxLMsQXPhLPPxQ7/nXcOup/wwx/PJwJGnIbu0zChC76wXqhcF4wjn Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AiXB7sh1hEIaQOkCcsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAAC9Yhxd/5JdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBQ1ADalUgBAsoCodZA4RSigyCW4lNjXmBLhS?= =?us-ascii?q?BEANUCQEBAQwBARgLCgIBAYFLgnUCgh8jNAkOAQMBAQQBAQIBBW2KNwyFSgE?= =?us-ascii?q?BAQQBARAoBgEBLAsBCwQCAQgRBAEBARUJECEGCx0IAgQBDQUIEweDAYFqAx0?= =?us-ascii?q?BAgyZPAKBOIhggiOCeQEBBYFGQYMNDQuCEgMGgTQBhHGEJIJJF4FAP4ERRoF?= =?us-ascii?q?Ofj6CGkcBAQMBgRgJPj2CfYImjBWdZ0AJAoIWhlaJNoQOl22NMIc8gXKOAAI?= =?us-ascii?q?EAgQFAg4BAQWBUDiBWHAVO4JsgkGDcYUUhT9ygSmLeAGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,446,1557187200"; d="scan'208";a="590799039" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 08:13:52 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x638DqvX027033 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 08:13:52 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 03:13:52 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 03:13:51 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 03:13:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tUYVw6w/Q+VCqMUMDBBlTGPQM2Hc40W5RbgkDQQ0l0Y=; b=r2e4/bxxZKj9pT6H9+0okSG+ZhiYe3KJGMkVCdhCL88OkwxjWKKclmLEX73He0ICLCGnalGCC2i/Qyrj1rwY7Evh3dkoewC6rRVJuJucruBzcofOXBpwJRqyEDKcQCU0mC1bjpud5LssqSNXliSmCedDvxHaqHQRw85xOTW+Www= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4096.namprd11.prod.outlook.com (20.179.150.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Wed, 3 Jul 2019 08:13:50 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 08:13:50 +0000 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, Jen Linkova , "6tisch@ietf.org" <6tisch@ietf.org> CC: V6 Ops List , 6man <6man@ietf.org> Thread-Topic: [6lo] ND cache entries creation on first-hop routers Thread-Index: AQHVMOxYqZ+Ae5ReXkiJP5a4XqZLuaa4gaXg Date: Wed, 3 Jul 2019 08:13:34 +0000 Deferred-Delivery: Wed, 3 Jul 2019 08:12:49 +0000 Message-ID: References: <5377.1562081856@localhost> In-Reply-To: <5377.1562081856@localhost> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e052d524-e024-45e2-7741-08d6ff8e615d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4096; x-ms-traffictypediagnostic: MN2PR11MB4096: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(376002)(346002)(136003)(189003)(199004)(13464003)(51444003)(476003)(76116006)(3846002)(6116002)(66946007)(2906002)(486006)(73956011)(110136005)(14454004)(66476007)(256004)(2501003)(4326008)(316002)(54906003)(66066001)(478600001)(52536014)(66574012)(66446008)(966005)(8676002)(68736007)(53546011)(446003)(64756008)(66556008)(11346002)(74316002)(86362001)(71200400001)(6246003)(6306002)(71190400001)(76176011)(8936002)(7696005)(9686003)(305945005)(55016002)(6506007)(6436002)(25786009)(33656002)(5660300002)(81166006)(81156014)(102836004)(186003)(99286004)(229853002)(26005)(7736002)(14444005)(6666004)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4096; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: RzOLfYa3gwsoBVuv5jePaamvIzHkf0JY4YL4ld++V2QygGYCAhd0590mItlE+of2MG9J2uBvRLrtTtNnlJJ/WTBfAt1vHeIuAdTisqlHeBss9APH83Tov/EGIDlDVkFP8OnBT8nYPhMqLvId5vj4TJ+6cnhJmAJJhRgBqh8L9guxbte5BOkMJxpE2I2yJLeB3rXsQMXNqg+SEkUfz19xvsxle14cVmQvzfQoBrfquwV2+Uo5umaViNcAsHJafXJusDalRXd6k1O5ABauWfgssH8qcpe7YlmnJlxW5e4RQ7bgZBMVvBwomoxvfC9nztx1pOKYL5WA5G+t95OtSfNvGD+Km1YSgBt5QbX3k1kwMPqaklbGwdFFnCSz+Gj80WM5SlXtKV4WDUlrAtGNQ1gaNLLF83Ui8kkcg82SmKnMh8o= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e052d524-e024-45e2-7741-08d6ff8e615d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 08:13:50.1779 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4096 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 08:13:57 -0000 Hello Michael 6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the ones co= ming from the outside of the subnet, i.e., from a place that is out of touc= h and virtually nowhere. This is because in an RFC 6775/8505-only network, there is no reactive oper= ation, a packet coming from the outside of the subnet for a node that is no= t registered to the router is just dropped. Just like an AP does not copy a= packet on the wireless for a MAC that is not associated. I'm baffled that the reactive ND is still the official technique for IPv6 l= ookup at 6MAN. The operations that you have to do in an enterprise-class ro= uter on a data packet, punt the packet to software, run ND, program the har= dware, protect ND cache and CPU against DOS, are just from another age. So = we have to run our own things (e.g., a LISP MSMR) on our fabrics when moder= nizing ND would do the trick in a standard fashion (see draft-thubert-6lo-u= nicast-lookup) . Your point below remains correct, since the attack you describe is from a n= ode that reaches the router at L2. Arguably, that attack is physically much= harder to perform than the DOS packet from outer space. All the best, Pascal > -----Original Message----- > From: 6lo <6lo-bounces@ietf.org> On Behalf Of Michael Richardson > Sent: mardi 2 juillet 2019 17:38 > To: 6lo@ietf.org; Jen Linkova ; 6tisch@ietf.org > Cc: V6 Ops List ; 6man <6man@ietf.org> > Subject: Re: [6lo] ND cache entries creation on first-hop routers >=20 >=20 > I think that the discussion here is particularly relevant to constrained > devices/routers on route-over MESH(RPL,etc.) networks. >=20 > I also think that for L=3D0 networks, which RPL creates with RPL DIO mess= ages > rather than (just) RAs, and 6LRs that need to support join operations (li= ke > draft-ietf-6tisch-minimal-security) this may matter. >=20 > In particular, in the minimal-security case, we need to partition the ND = cache > such that untrusted (unverified) malicious pledge nodes can not attack th= e ND > cache. >=20 > The behaviour 2.2.1. Host Sending Unsolicited NA, should probably never = flush > an old entry out of the ND. I think that under attack (whether from untr= usted > pledges, or from p0woned devices already on the network), it is better to > prefer communication from existing nodes rather than new ones. 2.2.1.2 > mentions this. >=20 > {typo: > -It's recommended that thsi functionality is configurable and > +It's recommended that this functionality is configurable and } >=20 > I didn't really understand 2.2.2: is it exploiting some corner case in th= e spec, or > maybe just some part I am not well clued in about. So maybe an extra > paragraph to explain things. >=20 > I kinda like the ping all routers trick. >=20 >=20 > Jen Linkova wrote: > > I wrote a short draft to discuss and document an operational issue > > related to the ND state machine and packet loss caused by how route= rs > > create ND cache entries for new host addressed: >=20 > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ >=20 > > (taking into account some vendors have implemented one of the propo= sed > > solution already, I guess it's a well-known problem but it might st= ill > > worth documenting) >=20 > > Comments are appreciated! >=20 > > -- > > SY, Jen Linkova aka Furry >=20 > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------= - >=20 >=20 > -- > Michael Richardson , Sandelman Software Works - > =3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jul 3 01:19:19 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AC71204E0; Wed, 3 Jul 2019 01:18:57 -0700 (PDT) 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, 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 header.b=YFlIqDq2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U2oDBrtu 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 mrhtmGZtrz_a; Wed, 3 Jul 2019 01:18:55 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B481202E3; Wed, 3 Jul 2019 01:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4860; q=dns/txt; s=iport; t=1562141935; x=1563351535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=paZqqZZkkJvBH+uzaboGLrQkVe4UIEok7NDfx4DN6jQ=; b=YFlIqDq2HG1So9O+JVNGlvqfxdOgnJ0SoS/XN/QVrPEoAt/KEps9LVX8 /QXDlaN3QvKBrp4w+xnHSarvtr8MgVy1Y5MWPxChoXaBFVLZdjcSeArUT O+3bVpeLjEd3o/vSa3P5E9msPJq4OP1KGNQWkXV4hG4cG3ucv5HwjhSQq o=; IronPort-PHdr: =?us-ascii?q?9a23=3AJfD8XxNeancz6oiuSw0l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAClYxxd/4cNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgUNQA2pVIAQLKAqHWQOEUooMglt+iE+?= =?us-ascii?q?NeYEuFIEQA1QJAQEBDAEBGAsKAgEBgUuCdQKCHyM0CQ4BAwEBBAEBAgEFbYo?= =?us-ascii?q?3DIVKAQEBBAEBECgGAQEsCwELBAIBCA4DBAEBARUJECEGCx0IAgQBDQUIEwe?= =?us-ascii?q?DAYFqAx0BAgyZNwKBOIhggiOCeQEBBYEyARNBgw0NC4ISAwaBNAGEcYQkgSu?= =?us-ascii?q?BHheBQD+BEUaBTkk1PoIaRwEBAgEBgRgJFSk9gn2CJowDEp1nQAkCghaGVok?= =?us-ascii?q?2hA6XbY0whzyBco4AAgQCBAUCDgEBBYFQOIFYcBU7gmyCQYNxhRSFP3IBAYE?= =?us-ascii?q?nikeBMQGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,446,1557187200"; d="scan'208";a="293778675" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 08:18:53 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x638Iro4026611 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 08:18:53 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 03:18:53 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 03:18:52 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 04:18:52 -0400 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=Duy6eeFDcB7HwHEwzbSBM82FHeVgYs5A02VLiKBo83Td0O0GCnPrjUNb82/Z2Z/FRB9XoRNJEvMqwrUNU+RdKtTVcYuV9pp3EmHGNdFmhmcsOxJEk4hZ3eBtp/AlKflphES1ZXXiYKEVczdhGRJUixceFaP+hfVuwLyLt7xw/A8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NhTeLO+ykq3TEcN1CRBOnjQA0KD2P0FV7ufdVTT3k/E=; b=EJuuMeDXKYwjy3V7lrjfo/+WEeAQ9peRuDGVXBOHUAslT+1IdkzGIz5AK8vaMZ7yzH5bw3J/N6kXVanb67SEmwZGZKhSeelA7Z4dIaeLJJ44tXJ6jr2vhdsCBkYl9dAdXJ5wr2DZaG8KbKZGpgBelJ1z2qtzcgTTBwHbPnyhjCQ= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NhTeLO+ykq3TEcN1CRBOnjQA0KD2P0FV7ufdVTT3k/E=; b=U2oDBrtuGlVjSrUH7wzEfO7KSFJM/jVaMUDFJQog45uG9ehG9Yrbsig9jOynkwskCUcXCzGOyTwLWbx1EKKGhk4mc31lFRkd2/QYzpNeb+EThNbL+PayPVclZwEVqzb9q1mFWT/z9Q9wGrRr3VvG+jpCAvrhhQAgOBa6MZOnDlg= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4063.namprd11.prod.outlook.com (20.179.149.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 3 Jul 2019 08:18:50 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 08:18:50 +0000 From: "Pascal Thubert (pthubert)" To: Jen Linkova , Michael Richardson CC: "6tisch@ietf.org" <6tisch@ietf.org>, 6man <6man@ietf.org>, V6 Ops List , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] ND cache entries creation on first-hop routers Thread-Index: AQHVMOxYqZ+Ae5ReXkiJP5a4XqZLuaa4dcOAgAAWmHA= Date: Wed, 3 Jul 2019 08:18:34 +0000 Deferred-Delivery: Wed, 3 Jul 2019 08:18:31 +0000 Message-ID: References: <5377.1562081856@localhost> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe8a5b4a-074c-457b-bd12-08d6ff8f1435 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4063; x-ms-traffictypediagnostic: MN2PR11MB4063: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(366004)(39860400002)(189003)(199004)(13464003)(51444003)(74316002)(7736002)(81166006)(81156014)(102836004)(14444005)(256004)(305945005)(2906002)(6506007)(99286004)(7696005)(26005)(6436002)(8936002)(76176011)(9686003)(55016002)(68736007)(53936002)(6246003)(478600001)(33656002)(6306002)(186003)(8676002)(53546011)(229853002)(5660300002)(66066001)(6666004)(11346002)(71190400001)(446003)(3846002)(6116002)(66574012)(486006)(966005)(73956011)(66946007)(76116006)(52536014)(316002)(25786009)(54906003)(66556008)(110136005)(66476007)(64756008)(4326008)(476003)(66446008)(14454004)(86362001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4063; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +UC5dapSfGMmAT/Zu1S+QsamW0psRlqimjfkWhdw5OW1OSiACaG9F6nifq7oxEig2KDFhfcaxhQVpjqXO2pPgzu4XUc/BD9ihazgg8gC/HtvdiKwVVd3D5m0jJP7LTRp+SHYM/qNy5NMsFN0cJ5V4QqUKHNUCWDj1MKrq6krIP28MD3VD4ig3/kAGUeZQhDC338a0BgaHcqQCASiHA5RimSGLRL72N/EdsWfPb53ZKkv7U7ixIr7dvJJzLdP2lQU/wNU8RnG0N9rJpHxwhI5OMAe8ycA+O/SYF7IkWZwDDvJPrPN0y2vY4g4HVd83Tvg4qYkdXAekCXfTearzW0u/8P/8MmG2wVIGvfIm3t59Q3GMMI8Fdv5mLk3SJoBNVhNSPrXfX0PwRGLkspi4//0L7i2mNsA2ru7JfwO7MKlDcY= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fe8a5b4a-074c-457b-bd12-08d6ff8f1435 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 08:18:50.2207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4063 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 08:18:58 -0000 Hello Jen The routers that Michael is talking about are real routers, deployed in lar= ge volumes in the field, e.g., in Smartgrid networks.=20 They are not running ND as RFC 4861/4862 but as RFC 6775/8505, and then ope= rate RPL routing within the ML subnet. It would be great to have a section that describes that new ND operation an= d shows how it changes the deal. I'd be happy to help you on that if you ne= ed. There are some hints in https://datatracker.ietf.org/doc/draft-thubert-6man= -ipv6-over-wireless/. All the best, Pascal > -----Original Message----- > From: 6lo <6lo-bounces@ietf.org> On Behalf Of Jen Linkova > Sent: mercredi 3 juillet 2019 08:52 > To: Michael Richardson > Cc: 6tisch@ietf.org; 6man <6man@ietf.org>; V6 Ops List ; > 6lo@ietf.org > Subject: Re: [6lo] ND cache entries creation on first-hop routers >=20 > On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson > wrote: > > I think that the discussion here is particularly relevant to > > constrained devices/routers on route-over MESH(RPL,etc.) networks. > > > > I also think that for L=3D0 networks, which RPL creates with RPL DIO > > messages rather than (just) RAs, and 6LRs that need to support join > > operations (like draft-ietf-6tisch-minimal-security) this may matter. >=20 > Disclaimer: I have very limited knowledge in that area. >=20 > > In particular, in the minimal-security case, we need to partition the > > ND cache such that untrusted (unverified) malicious pledge nodes can > > not attack the ND cache. >=20 > The next version of the draft will have much more details on discussing t= he > security considerations indeed. >=20 > > The behaviour 2.2.1. Host Sending Unsolicited NA, should probably > > never flush an old entry out of the ND. >=20 > I'd say that the router behaviour for creating a STALE entry upon receivi= ng an > unsolicited NA should be the same as for creating an entry for any other > reason (e.g. for receiving an RS with SLLAO). > The same safety rules shall apply. >=20 > > I think that under attack > > (whether from untrusted pledges, or from p0woned devices already on > > the network), it is better to prefer communication from existing nodes > > rather than new ones. 2.2.1.2 mentions this. >=20 > I guess your routers do purge old stale entries? >=20 > > {typo: > > -It's recommended that thsi functionality is configurable and > > +It's recommended that this functionality is configurable and } >=20 > Thanks, will fix in -01. >=20 > > I didn't really understand 2.2.2: is it exploiting some corner case in > > the spec, or maybe just some part I am not well clued in about. So > > maybe an extra paragraph to explain things. >=20 > It's just using the standard ND process: when the node B receives an NS f= rom > node A and that NS contains the node B address as a target address and > SLLAO contains node A LLA, the node B would respond with NA and would > create a STALE entry for the node A - > https://tools.ietf.org/html/rfc4861#section-7.2.3 >=20 > > I kinda like the ping all routers trick. >=20 > I think it's a hack ;( we do have a mechanism for communicating neighbour= s > addresses/reachability called ND. It would be nice to utilise its machine= ry. > Pinging creates additional overhead on routers and could get filtered. > But I'd not be surprised if it's the only way we have realistically to mi= tigate the > issue.. >=20 > > > > Jen Linkova wrote: > > > I wrote a short draft to discuss and document an operational issu= e > > > related to the ND state machine and packet loss caused by how rou= ters > > > create ND cache entries for new host addressed: > > > > > > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > > > > (taking into account some vendors have implemented one of the > proposed > > > solution already, I guess it's a well-known problem but it might = still > > > worth documenting) > > > > > Comments are appreciated! > > > > > -- > > > SY, Jen Linkova aka Furry > > > > > -----------------------------------------------------------------= --- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6 > > > > > -------------------------------------------------------------------- > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > > > > > >=20 >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Wed Jul 3 03:38:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6893812004F; Wed, 3 Jul 2019 03:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 8Ew0o12QNOzi; Wed, 3 Jul 2019 03:38:08 -0700 (PDT) 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 561CF12004C; Wed, 3 Jul 2019 03:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562150284; x=1562755084; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=02icBGvR U12e3h24cm6KdahXzcrGbgSgjsZ5ChQhv7k=; b=it6hm9aDzjYHYra2lsrAAWS+ 7rhTZUmoVNY5iiRKAm/zaOVQ4ZBs/IHkDM8fidjMp7zL0C9BFfUAHKRNdevKle1R zD0qMFiy/N73lKf4QYcwIYC3zCV/JNR1nYfMiB98z71eEDgpxZol5Fha0bvGvhhz B+LeCxorrFkJfB9T5fU= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 03 Jul 2019 12:38:04 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 03 Jul 2019 12:38:02 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006314110.msg; Wed, 03 Jul 2019 12:38:00 +0200 X-MDRemoteIP: 2001:470:1f09:495:a0a2:6b78:e053:efcf X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 03 Jul 2019 12:38:00 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1087b927de=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Wed, 03 Jul 2019 12:37:59 +0200 From: JORDI PALET MARTINEZ To: 6man <6man@ietf.org>, IPv6 Operations Message-ID: <3EE88939-F399-48C4-838A-6731D9A188DC@consulintel.es> Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 References: <12187.1558972629@localhost> <00C00FE5-C7CD-4B99-A2C9-CCBFCB1E4850@isc.org> <6053.1561748461@localhost> <0167874A-F2B4-434A-B674-792FE3AD0E2D@gmail.com> In-Reply-To: <0167874A-F2B4-434A-B674-792FE3AD0E2D@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 10:38:11 -0000 Hi all, =EF=BB=BFEl 2/7/19 2:30, "ipv6 en nombre de Fred Baker" escribi=C3=B3: =20 =20 On Jun 30, 2019, at 8:06 PM, Jen Linkova wrote: > First I think we need to clarify what 'IPv6-only' means. =20 To my mind, that is mostly complex because people make it complex, or b= ecause we allow them to. -> I tried to fix this some time ago, but my draft expired. I've updated it= now and just posted it: https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/?include_text= =3D1 -> by the way, I'm actually not sure if this is in scope of 6man or v6ops .= .. I tend to think v6ops, but just in case ! =20 Imagine I have two hosts, each of which can only communicate using IPv6= . They only have IPv6 addresses, and they possibly only have IPv6 stacks, b= ut they don't have anything else. If they can communicate in a domain, from= their perspective it is a domain that will support end to end IPv6 communi= cation. If they have to do something in addition, the domain doesn't work f= or IPv6-only hosts. =20 Now, it could be that the communications are translated to IPv4, X.25, = or SNA in between. Yup, could happen. But we can communicate end to end usi= ng only IPv6, right? =20 And, oh yes, someone using IPv4 (or X.25, or SNA) could go through a tr= anslator and communicate with an IPv6-only host in such a domain. It's IPv6= -only up to that translator. =20 The question boils down to - imagine I had only IPv6 to work with. Coul= d we communicate? An IPv6-only host, or IPv6-only network, could communicat= e with that restriction. Everything else is noise - and if I have to deal w= ith noise, it's not IPv6-only. -----------------------------------------------------------------------= --------- The fact that there is a highway to hell and a stairway to heaven is an= interesting comment on projected traffic volume... =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 Wed Jul 3 04:03:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DBE12021C; Wed, 3 Jul 2019 04:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 fj5uX_6yOKu7; Wed, 3 Jul 2019 04:03:15 -0700 (PDT) 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 9E95212004F; Wed, 3 Jul 2019 04:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562151788; x=1562756588; 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=ymsFfpRjeCg5v7hOII0eyFiVpRfN0yTw/j5sAX9Bxa4=; b=i0P5sdHEVNHlf jA261pYlbS1ndT//YAVwPO1mb67v5frFEqNdjCunBPRpZ0CSs5eSPrvNdXhsd9yy 34GSekik6jRJ1Mf0OnH6v1Zw2KEjVjDfAZBdjAGlopYOfI6JSZqAxAmZTR/CyWOz p0KrYCmuVXubH2NhSO+vQlwam1G0F0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 03 Jul 2019 13:03:08 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 03 Jul 2019 13:03:07 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006314133.msg; Wed, 03 Jul 2019 13:03:06 +0200 X-MDRemoteIP: 2001:470:1f09:495:a0a2:6b78:e053:efcf X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 03 Jul 2019 13:03:06 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1087b927de=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Wed, 03 Jul 2019 13:03:04 +0200 From: JORDI PALET MARTINEZ To: Brian E Carpenter , "Mudric, Dusan (Dusan)" , Lea Roberts , JORDI PALET MARTINEZ CC: "draft-palet-v6ops-rfc6177-bis@ietf.org" , IPv6 Operations Message-ID: <0601C33E-0BB0-4C42-BCD2-B86FD90BBA6A@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 11:03:19 -0000 Hi all, I've been too busy to tackle a new version of this document, but now workin= g on it. My recall on this, please correct me if I'm wrong (Brian, Mudric), is that = you believe that: 1) We should define end-site in the document? 2) End-sites must be able to request a longer prefix if needed and the ISP = must grant it? Anything I may be missing? Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 28/8/18 6:27, "v6ops en nombre de Brian E Carpenter" escribi=C3=B3: On 2018-08-28 06:23, Mudric, Dusan (Dusan) wrote: > Section 4. > " b. An end-user should be able to receive any prefix length up to= /48 > simply by asking." >=20 > Can this be defined in a way to make sure that new applications and = devices will always work at end sites without a need for asking ISPs for ex= tra address space? Otherwise, the end-user might not get what he/she asks f= or, without paying for the "higher grade" service. Can the definition impos= e up to /48 LAP when needed at end sites? For example, can an application r= equest a home router to request an ISP for /48 prefix and, when requested, = ISP must grant it? =20 Unfortunately we can never say "must" in this context. What ISPs will p= rovide for what fee is well outside the IETF's competence. As observed on anot= her thread, applications need to be agile, even if they work better if such= a request was granted. =20 I'd say that once this update is done, it may be time to revisit RFC4084. =20 Regards Brian =20 >=20 > Regards, > Dusan Mudric. >=20 >> -----Original Message----- >> From: v6ops On Behalf Of Lea Roberts >> Sent: Thursday, July 19, 2018 2:08 PM >> To: Brian E Carpenter ; JORDI PALET >> MARTINEZ >> Cc: draft-palet-v6ops-rfc6177-bis@ietf.org; IPv6 Operations >> >> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.tx= t >> >> hi Brian and Jordi - >> >> excellent comments and I agree also. >> >> thank you!! >> /Lea >> >> On Thu, 19 Jul 2018, JORDI PALET MARTINEZ wrote: >> >>> Hi Brian, >>> >>> >>> >>> Thanks a lot for commenting and sorry the late answer ... too busy = last >> weeks. >>> >>> >>> >>> Comments in-line below (subjected to my co-author agreement), basic= ally, >> agree with all your inputs, except a couple of points. >>> >>> >>> >>> Thanks! >>> >>> >>> >>> Regards, >>> >>> Jordi >>> >>> >>> >>> >>> >>> >>> >>> =EF=BB=BF-----Mensaje original----- >>> >>> De: v6ops en nombre de Brian E Carpenter >> >>> >>> Organizaci?n: University of Auckland >>> >>> Fecha: domingo, 8 de julio de 2018, 17:43 >>> >>> Para: , IPv6 Operations >> >>> >>> Asunto: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.tx= t >>> >>> >>> >>> Hi, >>> >>> >>> >>> Thanks for this draft. >>> >>> >>> >>> > Abstract >>> >>> >>> >>> This needs to be shorter. Three paragraphs is too much. >>> >>> >>> >>> For the next version, I've reduced 50% the length of the 1st paragr= aph. 3rd >> paragraph, I recall is mandatory (IDNits). >>> >>> >>> >>> >>> >>> > ... policy should reflect that assignment of a single subnet i= s >>> >>> > no longer appropriate unless the recipient explicitly agrees t= o the >>> >>> > limitations implied by such an assignment. >>> >>> >>> >>> I *strongly* suggest deleting the "unless" clause. It leaves a >>> >>> loophole, and it could easily be hidden in shrink-wrap terms >>> >>> and conditions so that a subscriber would agree without even >>> >>> knowing about it. Reduce this simply to: >>> >>> >>> >>> ... policy should reflect that assignment of a single subnet = is >>> >>> never appropriate. >>> >>> >>> >>> Agreed and done. >>> >>> >>> >>> >>> >>> > 1. Introduction >>> >>> .... >>> >>> > 1. It is extremely discouraged that /128s be given out. W= hile there >>> >>> > may be some cases where assigning only a single address= may be >>> >>> > justified, a site, by definition, implies multiple subn= ets and >>> >>> > multiple devices. >>> >>> >>> >>> I find this a bit weak. Try: >>> >>> >>> >>> 1. It is extremely discouraged that /128s be given out. Whi= le there >>> >>> may be some applications where assigning only a single ad= dress may >> be >>> >>> tolerated, a site, by definition, implies multiple subnet= s and >>> >>> multiple devices. Also, a /128 prevents any form of priva= cy-based >>> >>> addressing. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > 4. This revision has been created to more clearly assert t= he >>> >>> > requirement to ensure that address assignments to end-s= ites >>> >>> > provide a sufficiently big number of subnets (/64 on cl= assic >>> >>> > networks) to each end-site, taking under consideration = the end- >>> >>> > site's future expected needs, new deployment expectatio= ns and >> new >>> >>> > protocol requirements, among others. Once all these ar= e >>> >>> > considered, it seems unlikely that a single subnet (/64= ) or even >>> >>> > a small number of them should be assigned, unless very = clearly >>> >>> > justified and agreed to by the end-site. >>> >>> >>> >>> The "unless" clause is dangerous because of shrink-wrap terms an= d >>> >>> conditions. I suggest deleting it. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > 2. Considerations Regarding the Prefix Length >>> >>> .... >>> >>> > This consideration should be noticed, across this document,= in the >>> >>> > sense that end-sites usually have subnets that use, by defa= ult, >>> >>> > SLAAC, and consequently, the LAP is mandatorily a /64. Oth= er >>> >>> > technologies, may have a different LAP, which must be used >>> >>> > accordingly. >>> >>> >>> >>> I suggest s/Other/Future/ since /64 prevails everywhere today. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > 3. On /48 Assignments to End-Sites >>> >>> .... >>> >>> > An important >>> >>> > goal in IPv6 is to significantly change the default and min= imal end >>> >>> > site assignment, from "a single address" to "multiple netwo= rks" and >>> >>> > to ensure that end-sites can easily obtain address space. >>> >>> >>> >>> I suggest adding something like this: >>> >>> >>> >>> As the operational costs of carrier-grade NAT and address+port s= haring >>> >>> have shown, availability of multiple addresses and prefixes to e= nd sites >>> >>> that need them will be a considerable saving to their ISPs. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > It might be tempting to give home sites a single /64, since= that is >>> >>> > already significantly more address space compared with toda= y's IPv4 >>> >>> > practice. However, this precludes the expectation that eve= n home >>> >>> > sites will grow to support multiple subnets going forward. = Hence, it >>> >>> >>> >>> s/expectation/certainty/ >>> >>> >>> >>> Agreed! >>> >>> >>> >>> .... >>> >>> > A key goal of the recommendations in [RFC3177] is to >>> >>> > ensure that upon renumbering, one does not have to deal wit= h >>> >>> > renumbering into a smaller subnet size. >>> >>> >>> >>> Perhaps add: >>> >>> >>> >>> In particular this would apply to any site that switches to >>> >>> an ISP that provides a longer prefix. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > It should be noted that similar arguments apply to the mana= gement of >>> >>> > zone files in the DNS. In particular, managing the reverse >>> >>> > (ip6.arpa) tree is simplified when all links are numbered u= sing the >>> >>> > same subnet ids >>> >>> >>> >>> s/numbered/renumbered/ >>> >>> >>> >>> Agreed! >>> >>> >>> >>> .... >>> >>> > years, and we don't recover back the /48's, we will be able= to use >>> >>> > IPv6 addressing space for over 100.000 years. >>> >>> >>> >>> Perhaps add: >>> >>> >>> >>> This document does not advocate careless use of address space, b= ut >>> >>> there is objectively no reason to be restrictve. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> .... >>> >>> > Today typically, a home has already a considerable number o= f possible >>> >>> > subnets (a common CE has 4 LAN ports, 2 WiFi radios which s= upport >>> >>> > several SSIDs each one, VoIP subnet, IPTV subnet, additiona= l VLANs) >>> >>> > and if downstream routers are used, there is a need for fur= ther >>> >>> > subnets. This means that in a short term, assigning a /60 = (16 >>> >>> > subnets), it is already a really bad decision, as it may en= force IPv6 >>> >>> > NAT between the main CE and downstream routers. >>> >>> >>> >>> I suggest deleting "as it may enforce IPv6 NAT between the main = CE and >>> >>> downstream routers". Firstly it puts NAT into the reader's mind.= Secondly, >>> >>> it isn't the only solution - IIDs shorter than 64 could also be = implemented. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > 4. Impact on IPv6 Standards >>> >>> >>> >>> I propose to simply delete this section. >>> >>> >>> >>> Firstly, RFC3056 is deprecated so it's irrelevant today. >>> >>> Secondly, the argument about ULAs (RFC4193) doesn't hold up. >>> >>> ULAs are like any other /48 prefix - if you are forced to >>> >>> renumber into a longer prefix, you lose some subnet bits. >>> >>> That is already covered in the middle of section 3 (the >>> >>> "key goal" sentence quoted above). >>> >>> >>> >>> >>> >>> I recall we deprecated the 6to4 anycast, but not 6to4, in fact 6to4= to 6to4 >> traffic is still useful for peer to peer. >>> >>> >>> >>> > 6. Security Considerations >>> >>> > >>> >>> > This document has no known security implications. >>> >>> >>> >>> Really? More prefix space offers more potential for scanning >>> >>> attacks. More prefix space also allows the use of slightly >>> >>> randomized prefixes and/or prefix-per host. >>> >>> >>> >>> Also of course, a /128 would prevent any form of privacy-based >>> >>> addressing. >>> >>> >>> >>> I've introduced new text on those points. >>> >>> >>> >>> > 8. Acknowledgements >>> >>> > >>> >>> > The authors of this document will like to acknowledge the a= uthors of >>> >>> > previous versions (Thomas Narten and Geoff Huston) >>> >>> >>> >>> RFC3177 was signed by the whole IAB and IESG seated in 2001, and= its >>> >>> Acknowledgements read: >>> >>> >>> >>> >> This document originated from the IETF IPv6 directorate, w= ith much >>> >>> >> input from the IAB and IESG. The original text forming th= e basis of >>> >>> >> this document was contributed by Fred Baker and Brian Carp= enter. >>> >>> >> Allison Mankin and Thomas Narten merged the original contr= ibutions >>> >>> >> into a single document, and Alain Durand edited the docume= nt >> through >>> >>> >> its final stages. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> Regards >>> >>> Brian >>> >>> >>> >>> _______________________________________________ >>> >>> v6ops mailing list >>> >>> v6ops@ietf.org >>> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIDaQ&c=3DBFpWQw8bsuKp >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3SLM >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D >>> >>> >>> >>> >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__www.consulintel.es&d=3DDwIDaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3 >> Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DGMRLdItF8yKbUdE9 >> NuXE-U48uk7OHNuEijym9jhE--s&e=3D >>> The IPv6 Company >>> >>> This electronic message contains information which may be privilege= d or >> confidential. The information is intended to be for the exclusive us= e of the >> individual(s) named above and further non-explicilty authorized disc= losure, >> copying, distribution or use of the contents of this information, ev= en if >> partially, including attached files, is strictly prohibited and will= be considered a >> criminal offense. If you are not the intended recipient be aware tha= t any >> disclosure, copying, distribution or use of the contents of this inf= ormation, >> even if partially, including attached files, is strictly prohibited,= will be >> considered a criminal offense, so you must reply to the original sen= der to >> inform about this communication and delete it. >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIDaQ&c=3DBFpWQw8bsuKp >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3SLM >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Wed Jul 3 05:44:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE9112000F for ; Wed, 3 Jul 2019 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSXRGxr8YjR8 for ; Wed, 3 Jul 2019 05:43:58 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450: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 7E710120043 for ; Wed, 3 Jul 2019 05:43:58 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id p11so2630763wre.7 for ; Wed, 03 Jul 2019 05:43:58 -0700 (PDT) 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=86Nh8LMyURAYiQkcfq/ezS5NXhww+xINUasP7Sgce2w=; b=WqKYqUzL8nw13DpSkEaqNxG0IIyJ4mfzuj6fYVSxLn5EeqfBRlEzkVAafOg67q78Dz CfwfN5SfDHaYcfRKwscZTALoG4exDKm1M7rXqap3UweaCYArrnZ4kAzkhSRSGXzN6HBc C4t2ETQrtEGLc9vn1gKQukCO0ryYGzbEAm5bxEs7Mb4XBJRKLkeCN97ui5jNp6htfODs /ky6I+U5cQsASvUAfth5zndlcgVi1ai8wC7y2e0OAPrPJfyqZst+rJqDe6JZbyhpV4EZ 1W80yDqCPOo4pcHcTy3GVRyxFcN2MY1uq+tGXJzfa6YD741D91sL/macC7deyRZheh4Y 0qTw== 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=86Nh8LMyURAYiQkcfq/ezS5NXhww+xINUasP7Sgce2w=; b=QV1zMSHJux2hythzWbarPsMBWtyZtiIkJCW2lohlU7qvUY16uJTl1iD7jDZ56623JU /f4QX3OqyFHLlKXRfQywbVjWQAqRYbG6rBPfBWmXYOCf+K3ICLQi23AC4Ikcb53RDQyg RY0yN70z+uki0Y52AiEeU+u/my6mBf9PhI3Z1B+eJDDx0nduuIRFhlpQbNNa108O8VbM 2q/R62FMBzZckY9oK7Y4jRDbaNsJLiwTF6/zhIBlPUlMb9jHnOGj7fI3NbwCLrXmt79B kZN0SoB/BGFb02gcmIFd0ufE07VBvPzem0vnmOei0Nc1drP+D+092A67RHiinvIX/nLw yadg== X-Gm-Message-State: APjAAAXASfFrC9X2seaihpQVDGwK+F7fmryDSgIptsBibnq2SaHXsGzz NAzMJQQEBIqL19/0cOk79sPY5A8iKLDXZJfwg6uiXQ== X-Google-Smtp-Source: APXvYqzN6CCvch+sSAkaqyqCBOgBy7wFpaYkl32guboHfHyBoY3ujYUBGyohEwt2hBGOlxxukHXh+0FNanpBP59r6DM= X-Received: by 2002:adf:900e:: with SMTP id h14mr15080935wrh.58.1562157836606; Wed, 03 Jul 2019 05:43:56 -0700 (PDT) MIME-Version: 1.0 References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> In-Reply-To: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> From: Lorenzo Colitti Date: Wed, 3 Jul 2019 21:43:44 +0900 Message-ID: To: Fred Baker Cc: Jen Linkova , V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000ef7c12058cc63677" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:44:02 -0000 --000000000000ef7c12058cc63677 Content-Type: text/plain; charset="UTF-8" I would definitely like to see this issue discussed in Montreal. Actually I think the primary motivating factor for this draft was not in the IOT space, but operational issues observed with mobile hosts (phones, laptops) just after they connect to an IPv6-only network. This unforeseen consequence of the specifications causes common implementations to be much slower in determining Internet connectivity on IPv6-only networks than on networks with IPv4. The reason this works in IPv4 is that in IPv4 there is only one address. So when the host ARPs for the router for the first time, the router puts the host's address in its ARP cache, the return ND cache entry is already primed. This does not work in IPv6 the only packets that go directly to the router come from the host's link-local address, not the global addresses that the host is using to talk off-link. I think this document belongs in v6ops, at least initially. It fits squarely within the charter of finding operational problems with the IPv6 specifications. On Wed, Jul 3, 2019 at 2:54 AM Fred Baker wrote: > Thanks for this. As usual, Ron and I are looking for supportive commentary > on the list in vetting agenda items. My big question at this point is > whether (following Michael's lead) it belongs in v6ops, 6man, or 6lo. > Operationally, do you see it in non-IOT-attacks? > > > On Jul 2, 2019, at 8:03 AM, Jen Linkova wrote: > > > > Hello, > > > > I wrote a short draft to discuss and document an operational issue > > related to the ND state machine and packet loss caused by how routers > > create ND cache entries for new host addressed: > > > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > > > (taking into account some vendors have implemented one of the proposed > > solution already, I guess it's a well-known problem but it might still > > worth documenting) > > > > Comments are appreciated! > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > -------------------------------------------------------------------------------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000ef7c12058cc63677 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would definitely like to see this issue discussed in Mon= treal. Actually I think the primary motivating factor for this draft was no= t in the IOT space, but operational issues observed with mobile hosts (phon= es, laptops) just after they connect to an IPv6-only network. This unforese= en consequence of the specifications causes common implementations to be mu= ch slower in determining Internet connectivity on IPv6-only networks than o= n networks with IPv4.

The reason this works in IPv4 is t= hat in IPv4 there is only one address. So when the host ARPs for the router= for the first time, the router puts the host's address in its ARP cach= e, the return ND cache entry is already primed. This does not work in IPv6 = the only packets that go directly to the router come from the host's li= nk-local address, not the global addresses that the host is using to talk o= ff-link.

I think this document belongs in v6ops, a= t least initially. It fits squarely within the charter of finding operation= al problems with the IPv6 specifications.

On Wed, Jul 3, 2019 at 2:54 = AM Fred Baker <fredbaker.iet= f@gmail.com> wrote:
Thanks for this. As usual, Ron and I are looking for supportive = commentary on the list in vetting agenda items. My big question at this poi= nt is whether (following Michael's lead) it belongs in v6ops, 6man, or = 6lo. Operationally, do you see it in non-IOT-attacks?

> On Jul 2, 2019, at 8:03 AM, Jen Linkova <furry13@gmail.com> wrote:
>
> Hello,
>
> I wrote a short draft to discuss and document an operational issue
> related to the ND state machine and packet loss caused by how routers<= br> > create ND cache entries for new host addressed:
>
> https://datatracker.ietf.org= /doc/draft-linkova-v6ops-nd-cache-init/
>
> (taking into account some vendors have implemented one of the proposed=
> solution already, I guess it's a well-known problem but it might s= till
> worth documenting)
>
> Comments are appreciated!
>
> --
> SY, Jen Linkova aka Furry
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

---------------------------------------------------------------------------= -----
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
=C2=A0 =C2=A0 =C2=A0Sun Tzu

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000ef7c12058cc63677-- From nobody Wed Jul 3 05:49:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CBF120043 for ; Wed, 3 Jul 2019 05:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 h3-B_UVjM0N5 for ; Wed, 3 Jul 2019 05:49:16 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 B410712000F for ; Wed, 3 Jul 2019 05:49:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x63CnEO6018828 for ; Wed, 3 Jul 2019 14:49:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CCCF3205074 for ; Wed, 3 Jul 2019 14:49:14 +0200 (CEST) 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 C216F205003 for ; Wed, 3 Jul 2019 14:49:14 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x63CnErR003857 for ; Wed, 3 Jul 2019 14:49:14 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <162e470d-a1da-c100-3806-e4ab7640f5e2@gmail.com> Date: Wed, 3 Jul 2019 14:49:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:49:19 -0000 Le 02/07/2019 à 17:03, Jen Linkova a écrit : > Hello, > > I wrote a short draft to discuss and document an operational issue > related to the ND state machine and packet loss caused by how > routers create ND cache entries for new host addressed: > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > (taking into account some vendors have implemented one of the > proposed solution already, I guess it's a well-known problem but it > might still worth documenting) > > Comments are appreciated! > I did notice that the first Echo Reply of a ping on a cellular link always gets lost. I put that on the fault of the enourmous numbers of routers and switches in between - until the path gets set up straight. That said, I am reading through this draft trying to identify whether the indicated ND problem (router lacking ND entry for host's GUA makes drop first incoming packet to GUA) happens on a ptp link like 4G, or on a shared link like WiFi. On what was it tried? > The router ND cache, however, might contain an entry for the device > link-local address (if the device has been performing the ND process > for the roiter LLA) but there are no entries for the device GUA. But has the host DADed (sent NAs) when it formed its GUA? I guess that would be heard by router, to create that ND cache entry. Alex From nobody Wed Jul 3 05:53:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9120E12001A for ; Wed, 3 Jul 2019 05:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 6vbdgpOZg1Gm for ; Wed, 3 Jul 2019 05:52:58 -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 06D8A12000F for ; Wed, 3 Jul 2019 05:52:57 -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 x63Cqujc028469 for ; Wed, 3 Jul 2019 14:52:56 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 49B9C2050A7 for ; Wed, 3 Jul 2019 14:52:56 +0200 (CEST) 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 3F523204FF2 for ; Wed, 3 Jul 2019 14:52:56 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x63CquM7006093 for ; Wed, 3 Jul 2019 14:52:56 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <5aac7a6d-eae0-de5f-9d25-735bb50b86df@gmail.com> Date: Wed, 3 Jul 2019 14:52:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:53:01 -0000 I forgot: people will tell you to use this Address Registration option to solve the problem. There is an RFC for it, it's about IoT and 6lo and similar. I disagree with the option. Alex Le 02/07/2019 à 17:03, Jen Linkova a écrit : > Hello, > > I wrote a short draft to discuss and document an operational issue > related to the ND state machine and packet loss caused by how routers > create ND cache entries for new host addressed: > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > (taking into account some vendors have implemented one of the proposed > solution already, I guess it's a well-known problem but it might still > worth documenting) > > Comments are appreciated! > From nobody Wed Jul 3 05:54:41 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52156120086 for ; Wed, 3 Jul 2019 05:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghzc5tGbT5XW for ; Wed, 3 Jul 2019 05:54:28 -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 4D6DC1202CC for ; Wed, 3 Jul 2019 05:54:28 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id n9so2716091wru.0 for ; Wed, 03 Jul 2019 05:54:28 -0700 (PDT) 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=u4UHD5iytKcxcjpEO7vfhJebWvTEJ+xQzO0rXirujEg=; b=htcq2w0z4Vmw9GZClbS5wOZXClirbfUfsdWkt8E2mfxrKx86ipE//Jnqt8uTHhh1tY 2PFVTwv+EvdNS3YgtMzeyT90uS4LVv7O+Oz/erKm3POeheSVJzXilhOVPeFxzBeRvfwV unT+eJGQcgZlTCpz93LbSwXbqHZdPWQ1BcVNNJPxfDCwb+nm9KkbUTDx0BtkhJcW7WEx ashIlZ5mOxyPiyyQhIkbij6D+PdVXRcynFXvHMgwfTZooL7neAbVrM+vZNVv2u8o6YY7 Js3qD1/YfpAMDkkQ860KQ7ycTcm9O6WUXD1U3caPjlPN4ljpInP4L09GrL+wzazKAJtX ZcKg== 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=u4UHD5iytKcxcjpEO7vfhJebWvTEJ+xQzO0rXirujEg=; b=Dv5Kfn6aBrLt+RbhwZt3biOiB1b+z9u946xjCAIH0ZbRES28HvSM2MPUKBtVQQAkmR w1n8O7w1mvaqfLumgcfrOS4QJ/C6DF5DZr9QJCztyyr8WEx5FDHCcgNJ62ZmfN/tHV+Y vD9uR2nP+N9vbLWK1hZ/NK0z0M0ZwKRwspz1PAGPnXD5R4LTZi2Z5WsLQbLxXuAO3tgj p1hzYYGXMI2XBotuQyoVF9AzwTQS263gZbs7+WGcAD+UBpoTbVTYxndQQqd/UFwiQ9mQ /xyom0I7VhrxT1gv2f5r7MQ9CkaRsTvbhApE3imLuNH/bAkoVd0x8hKIrL2Cf1Q8xPOs 0txg== X-Gm-Message-State: APjAAAUprzHl6hKN9P+MiJKWFVU2xJerUWzPADicSoMrBf4LfP1kBuD3 lJRCFZ45A5G7jMQE9xbt0gAkAtZSrmew+y6afij0dA== X-Google-Smtp-Source: APXvYqwLxkEYweDRCto+WAnL30C/wf7Cf8QQn8sZCaoptciESVU1JgSe7Cstzw7EAIc9ewzd6LIw02mB23sHIMepoAU= X-Received: by 2002:adf:900e:: with SMTP id h14mr15114312wrh.58.1562158466547; Wed, 03 Jul 2019 05:54:26 -0700 (PDT) MIME-Version: 1.0 References: <5377.1562081856@localhost> In-Reply-To: From: Lorenzo Colitti Date: Wed, 3 Jul 2019 21:54:14 +0900 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, Jen Linkova , "6tisch@ietf.org" <6tisch@ietf.org>, V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000007b87d7058cc65c07" Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:54:32 -0000 --0000000000007b87d7058cc65c07 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 3, 2019 at 5:14 PM Pascal Thubert (pthubert) wrote: > 6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the ones > coming from the outside of the subnet, i.e., from a place that is out of > touch and virtually nowhere. > This is because in an RFC 6775/8505-only network, there is no reactive > operation, a packet coming from the outside of the subnet for a node that > is not registered to the router is just dropped. Just like an AP does not > copy a packet on the wireless for a MAC that is not associated. > There are problems with registration-based models as well though. First, complexity. Recovering state in the presence of router crashes is complex. Also, depending on what guarantees the network needs to provide to hosts, a registration-based model will likely use more router memory in the common case that most hosts are well-behaved (because it cannot aggressively time out entries that with classic ND can simply be thrown away after a while). Second, an explicit registration model where the router can refuse to create an address entry provides a supported path for operators to limit the number of IP addresses used by hosts, which has the negative consequences described in RFC 7934. In fact, such a model is explicitly NOT RECOMMENDED by RFC 7934 for general-purpose hosts. The relevant text is "it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests." --0000000000007b87d7058cc65c07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2019 at 5:14 PM Pascal Thu= bert (pthubert) <pthubert@cisco.co= m> wrote:
6LoWPAN ND is immune to the remote DOS attacks = on the ND cache, the ones coming from the outside of the subnet, i.e., from= a place that is out of touch and virtually nowhere.
This is because in an RFC 6775/8505-only network, there is no reactive oper= ation, a packet coming from the outside of the subnet for a node that is no= t registered to the router is just dropped. Just like an AP does not copy a= packet on the wireless for a MAC that is not associated.
<= div>
There are problems with registration-based models as wel= l though.

First, complexity. Recovering state in t= he presence of router crashes is complex. Also, depending on what guarantee= s the network needs to provide to hosts, a registration-based model will li= kely use more router memory in the common case that most hosts are well-beh= aved (because it cannot aggressively time out entries that with classic ND = can simply be thrown away after a while).

Second, = an explicit registration model where the router can refuse to create an add= ress entry provides a supported path for operators to limit the number of I= P addresses used by hosts, which has the negative consequences described in= RFC 7934. In fact, such a model is explicitly NOT RECOMMENDED by RFC 7934 = for general-purpose hosts. The relevant text is "it is RECOMMENDED tha= t the network give the host the ability to use new addresses without requir= ing explicit requests."
--0000000000007b87d7058cc65c07-- From nobody Wed Jul 3 05:56:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3FD1202C0; Wed, 3 Jul 2019 05:56:00 -0700 (PDT) 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, 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 header.b=YhZ3+xEb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fagxOLIR 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 SeBi882ht1Jf; Wed, 3 Jul 2019 05:55:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925A51202C5; Wed, 3 Jul 2019 05:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3190; q=dns/txt; s=iport; t=1562158557; x=1563368157; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mkW62OTw8C7JSV2VlEpRdD0rWrzeavew2kOAtxECnaY=; b=YhZ3+xEb2RPrbYVORiagmcbnYa43lQKxJTKXDrU0j8Bq5i6jfD2SkMeZ 7R4QqYeoTzrvHRX5lVl3uD6ucT9JzZ4HcDTHQm+5YGG3H+njQS6ObjokW yNxqS1rXh4ljD2c2emXsI1CChmpHabo2u5jlaThsddyD1k0cB5jkA0NfK E=; IronPort-PHdr: =?us-ascii?q?9a23=3AFNUVKBf0CqIePxTxye1am1IIlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAADVpBxd/51dJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBQyknA2pVIAQLKIdjA4RSiXOCW5dGgS4UgRA?= =?us-ascii?q?DVAkBAQEMAQEYCwoCAQGEQAKCIiM0CQ4BAwEBBAEBAgEFbYo3DIVKAQEBBAE?= =?us-ascii?q?BECgGAQEsCwELBAIBCA4DBAEBFgkQJwsdCAIEAQ0FCBMHgwGBagMdAQIMmVY?= =?us-ascii?q?CgTiIYIIjgnkBAQWBMgETQYMIGIISAwaBNAGEcYZtF4FAP4FXgkw+gmEBAQI?= =?us-ascii?q?BAYEYHyg9gn2CJotznkwJAoIWhlaEaohal3GNMIc9j3YCBAIEBQIOAQEFgVA?= =?us-ascii?q?4gVhwFTuCbIJBgSYBCYJBhRSFP3IBAQGBJooxglEBAQ?= X-IronPort-AV: E=Sophos;i="5.63,446,1557187200"; d="scan'208";a="367684555" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 12:55:56 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x63Ctuwq002697 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 12:55:56 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 07:55:55 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 07:55:54 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 08:55:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r2/+TjhguKqsqWIoZIJxeokOLsY1LKPmm2njdUc55u8=; b=fagxOLIR7kEAhA5DcDu+boYAHRjf8A5g6ptHkKyrcxOstR3zgRhAEw8irctlKmMJrK5zl9XyUb/6tC8NYrV+5BCPHYWiUs3ETWkoXVBOAIeoiPNWnvN9O+Lp2uO7GF7il0I+i5fLm512dprjSzmEEjsOgwtHXwqjSaNlOJ5Aijc= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4128.namprd11.prod.outlook.com (20.179.150.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Wed, 3 Jul 2019 12:55:52 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 12:55:52 +0000 From: "Pascal Thubert (pthubert)" To: Jen Linkova , V6 Ops List CC: 6man <6man@ietf.org> Thread-Topic: [v6ops] ND cache entries creation on first-hop routers Thread-Index: AQHVMOfifvE1a4IuGkGPPJevTnDOSKa4zvPA Date: Wed, 3 Jul 2019 12:54:53 +0000 Deferred-Delivery: Wed, 3 Jul 2019 12:53:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba42fb7c-ffcd-4b83-d185-08d6ffb5c7f8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4128; x-ms-traffictypediagnostic: MN2PR11MB4128: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(366004)(346002)(376002)(199004)(189003)(13464003)(68736007)(33656002)(6246003)(86362001)(5660300002)(476003)(7736002)(446003)(486006)(66446008)(64756008)(73956011)(14454004)(76176011)(316002)(55016002)(99286004)(110136005)(25786009)(8936002)(53546011)(6436002)(6306002)(478600001)(256004)(71190400001)(74316002)(71200400001)(966005)(52536014)(6506007)(66946007)(9686003)(2906002)(102836004)(229853002)(66476007)(186003)(8676002)(66556008)(14444005)(11346002)(46003)(76116006)(81166006)(305945005)(4326008)(81156014)(66574012)(6116002)(7696005)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4128; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7G9vCQSgNjGVwJOz0YJIEvZy2NPI9OdU4dwLl7cxnxjJZTfOg4NBkko092r4BqSRVd9R2EOEKpVaNsFMnAhw1DPTN/xyJjy95FgeydC0qM/FVlmk8ZDURLe4nRKjXKLGUzaQ0yPz9iELiQL3RwqLZl6DhDCZo04t5MUkBKQ+foiIE2ejVy+7jurVXpxnU5D1ju2Oq9TuKEJx5pkdCoWEYyX1Ac5/MJ4y9ekDX/w/IXNJVSc5hEdgPqHD+OEi0L2edbAPnSzH6snjyl83kryyzCIGy/Xxoza3crxpe1AKuxGg08z2irEHYPF6QublBeVnEl0eWUjzyEutP3Y3hGSLmweM2KoXyy2J+ECa3MecOxM95gGCjO8uwl8n5iCKcddpKbYAjQWDwkZAAdGd47grXA4H4SassvQ30P18Jss6y34= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ba42fb7c-ffcd-4b83-d185-08d6ffb5c7f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 12:55:52.8040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4128 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:56:08 -0000 Hello Jen: In Introduction: "(previously unseen by the router)" Another case is that the cache may have been flushed. The same issue will h= appen again. In 2.2.3.2: " o Would not work for the host optimistic addresses ((see section 2.2 of [RFC4429] which prohibits using an Optimistic Address as the source address of a Router Solicitation with a SLLAO. " The "would not work" is exaggerated since the behavior of the router c/shou= ld be to lookup the source of the RS to answer with a unicast RA.=20 Some old implementations would always answer with a broadcast RA but hopefu= lly things have evolved with the realization that broadcast may have its ow= n issues, in particular with wireless and overlays. So this technique may w= ork if the router responds unicast and the optimistic node also introduces = a small delay before firing its probes to cover for the RA delay.=20 In 3. Recommendations I do not agree with the recommendation, because: - the host has no control or guarantee about whether the router will maint= ain the cache and for how long - multicast NA may be lost, more chances of that if the router is wireless= . You may want something a bit more robust with an acknowledgement and a li= fetime, see RFC 8505.=20 - the all-routers is still a L2 broadcast on Ethernet and Wi-Fi. We are act= ually trying to deprecate the NA(O) at the end of the autoconf sequence. - the proposed knob would have the routers learn all addresses of all hosts= including those that do not get traffic from that router. This augments th= e chances of cache saturation, which recreates the problem you want to avoi= d. Also note that the fiddling smart wireless well as smart fabrics may learn = the location of the address from snooping the ND activity (see https://tool= s.ietf.org/html/draft-bi-savi-wlan). A sense if order of events like a sequ= ence counter / time stamp is important for devices that move quickly. See f= or instance the discussion in https://tools.ietf.org/html/draft-ietf-rift-r= ift-06#section-5.3.3.1 . All in all there' s a limit to stretching old designs and a time where a ne= w one is needed. Ask plane makers... All the best, Pascal > -----Original Message----- > From: v6ops On Behalf Of Jen Linkova > Sent: mardi 2 juillet 2019 17:03 > To: V6 Ops List > Cc: 6man <6man@ietf.org> > Subject: [v6ops] ND cache entries creation on first-hop routers >=20 > Hello, >=20 > I wrote a short draft to discuss and document an operational issue relate= d to > the ND state machine and packet loss caused by how routers create ND cach= e > entries for new host addressed: >=20 > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ >=20 > (taking into account some vendors have implemented one of the proposed > solution already, I guess it's a well-known problem but it might still wo= rth > documenting) >=20 > Comments are appreciated! >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 3 06:00:58 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1F912006E for ; Wed, 3 Jul 2019 06:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, 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 RCf-hXz1LWMx for ; Wed, 3 Jul 2019 06:00:56 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 E62B2120046 for ; Wed, 3 Jul 2019 06:00:55 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id n4so2728363wrs.3 for ; Wed, 03 Jul 2019 06:00:55 -0700 (PDT) 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=7qv0I0P//pNSTWsJIvlHDSGT7OaAPlCbDLY73/MY7yM=; b=aC7uaOhUfnwML6Y/1l4wca7Q5LKq6ZB5mr8Fq9JGHnhB/OM5hgQ+IJbzm7jc2R0I8N u4SSJF3EDXMMmMGHzMziu0l6GsCDbbBeQ4Soj1hnsbJYCm03/wgcxAoJ/89j+WzMIACu P0SFExWOJCsRGxoWspEjk//JaRdHhakeKwKcOlWGl24yjYpTISp+2nmDk8r7Dlszur+k 6bzJh7qGuEpU/n9QQvlF3BWgBa/x+jD66wd+HRx6iamadggj/Gp1kAcBxp3uoxSlErDC toZ/suHYezimVvfcAQlMv8H2RhV82uZ5lu/oUUw47bZWgUT4AzfCyCOE6T9SugKu6tGT DeYg== 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=7qv0I0P//pNSTWsJIvlHDSGT7OaAPlCbDLY73/MY7yM=; b=KYQXJ3Rh4nyAoX+cFW6K5suIlQfa65+Zf5gbeKPh6TIi8av7Py/EXRb6LVshePNIAA v+sE2GsPRIDdId+mAiZn+YM5SiBn0yG4kgdIQjZlGd8o0tZI1XOZSj2lsCLkMQY/MPuC 0qWukuHUgEJkosQnUwbhv+vyUukeipLJHtGAXKPJx43Z8ANbB6YrTF0QU0Ze+W5Ws28C raYrPru2eAY7PPcfdH7FJK8NbHeMcGQchvLYdWMbF/Z3UXtT/boi4f06qPFvkfeHuSmk u7mE4QZLmnF2lOvcjtITAHdDRjETvaQDOsFO3d9HMjdK274CL+6XNZZqBmzAoA5iBzRJ bxoQ== X-Gm-Message-State: APjAAAVVI5DRhdLNLPDX1s/dX2cgZHf2u6KVg5JjBjyKnMvcyzZSM3zc 6V0dYOMCAIQ+3dlb/hi6+reAmAbuq8axFlEqVqZh6w== X-Google-Smtp-Source: APXvYqzHrrSMvm7hO/005Nd/4aYbP1KVWt6GfbG2mtCVAbHsgsIRYfoHZa/L38y1YG6FhrSr31rTKJWI5s5MmrbZALw= X-Received: by 2002:a5d:4681:: with SMTP id u1mr28388874wrq.102.1562158854178; Wed, 03 Jul 2019 06:00:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Wed, 3 Jul 2019 22:00:40 +0900 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Jen Linkova , V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000965c26058cc67398" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 13:00:58 -0000 --000000000000965c26058cc67398 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 3, 2019 at 9:56 PM Pascal Thubert (pthubert) wrote: > - multicast NA may be lost, more chances of that if the router is > wireless. You may want something a bit more robust with an acknowledgement > and a lifetime, see RFC 8505. > Not true on wifi. Multicast packets are always sent to the AP as unicast. --000000000000965c26058cc67398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2019 at 9:56 PM Pascal Thu= bert (pthubert) <pthubert@cisco.co= m> wrote:
-=C2=A0 multicast NA may be lost, more chances = of that if the router is wireless. You may want something a bit more robust= with an acknowledgement and a lifetime, see RFC 8505.

Not true on wifi. Multicast packets are always sent to the= AP as unicast.
--000000000000965c26058cc67398-- From nobody Wed Jul 3 06:08:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3775C120046; Wed, 3 Jul 2019 06:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=Ko4P///L; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IkqxlSW4 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 o3GvxlgQxGnu; Wed, 3 Jul 2019 06:07:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112BB120043; Wed, 3 Jul 2019 06:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6528; q=dns/txt; s=iport; t=1562159276; x=1563368876; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jF5i1zHlPNtKFdgHzM5OYfeZpnOVxroQ1p0A6nVfYV0=; b=Ko4P///L0qVDnelt6x5zfpabG0rB13bwQ9s3ZNPO0euoDcqyh20FuBlU /Uv+4FsDKhF8wsA6xqyhJVid9Mszbyp4nSrYZttTrrjkHKkgffsYo8UyP iuefGqbbTJIlDSRRxTTTs2X/r86/2CbagGqP4AQgqhs6g3JLqIM16qdkb Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AKiDtdRSpVbMoefbo+zdvXBZFQtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAACopxxd/5NdJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYEUL1ADalUgBAsohByDRwOEUolzgluJTYklhFSBLoE?= =?us-ascii?q?kA1QJAQEBDAEBLQIBAYRAAheCCyM0CQ4BAwEBBAEBAgEFbYo3DIVKAQEBBBI?= =?us-ascii?q?RChMBATcBDwIBCBEEAQEoAwICAh8RFAkIAgQOBQgagwGBHU0DHQECmV4CgTi?= =?us-ascii?q?IYHGBMoJ5AQEFhQ8NC4ISCYE0AYteF4FAP4FXgkw+ghqCLDSCVDKCJo5ohHy?= =?us-ascii?q?WG0AJAoIWkAyEDpdxll+OBAIEAgQFAg4BAQWBUDg3gSFwFTuCbIJBDBeDTop?= =?us-ascii?q?TcoEpjQIBAQ?= X-IronPort-AV: E=Sophos;i="5.63,446,1557187200"; d="scan'208,217";a="500899985" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 13:07:54 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x63D7she026568 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 13:07:54 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 08:07:54 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 08:07:53 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 08:07:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jF5i1zHlPNtKFdgHzM5OYfeZpnOVxroQ1p0A6nVfYV0=; b=IkqxlSW4xR4DD+0VYP4fBNvVw6e7CtE8LvOQ2tiMQlnQdJrj/WV4sIkxfWytdl8DWnoSS/sRgwpotOSkRaKEj3hmgRIxfHING053E+d9N5LcTkxavlYrZ+hs4C8bFFjpQcHjeOYbyDIxLwmj+fZEdweqCif0kXFceZoR3geBLgk= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Wed, 3 Jul 2019 13:07:52 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 13:07:52 +0000 From: "Pascal Thubert (pthubert)" To: Lorenzo Colitti CC: Jen Linkova , V6 Ops List , 6man <6man@ietf.org> Thread-Topic: [v6ops] ND cache entries creation on first-hop routers Thread-Index: AQHVMOfifvE1a4IuGkGPPJevTnDOSKa4zvPAgAAN3gCAAADZgA== Date: Wed, 3 Jul 2019 13:07:29 +0000 Deferred-Delivery: Wed, 3 Jul 2019 13:07:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aef471d1-88ec-4da8-c224-08d6ffb7752e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4221; x-ms-traffictypediagnostic: MN2PR11MB4221: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(376002)(366004)(199004)(189003)(186003)(25786009)(256004)(6116002)(9686003)(4326008)(102836004)(790700001)(99286004)(14454004)(486006)(11346002)(54896002)(6306002)(6436002)(6506007)(476003)(53546011)(446003)(236005)(66476007)(66446008)(33656002)(66946007)(71190400001)(66556008)(6666004)(76116006)(66574012)(71200400001)(4744005)(76176011)(229853002)(73956011)(55016002)(7696005)(7736002)(52536014)(2906002)(46003)(6246003)(478600001)(54906003)(6916009)(5660300002)(74316002)(8676002)(86362001)(81156014)(68736007)(316002)(53936002)(64756008)(8936002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4221; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Xmptkr7oK6XvdkNfydS13rKT/Vqz9Awh88m6UkhITjVCaxxxEe/KuZxzq30oMTn827dLHQ/s1+h4HeGcZ7U+vMkZSc8RzR80tBMWKr6Vpm1ehF195Od67kEOQxK0y519OJMe+d97vrOKMAAX89YUIWlDOsgadCA8J3nPb7WM6fLopTB3YmUpyD1IPK3Nz6WiJ8BPCGfqFXI7L5Q+rA7hEmtJJ4aJG3TGjRCw9TYLJFbPPtOhScCw5LOx+ANLbIeYkIKA5vXYVf9IVjrhOOQYe3w+X/LKeNpj10s8Jk6s0qoeI5ZnlBZKel0u49peazDCmE4qvcFfdZtwNf4mVIF/S9I7ouhcG6LuhRH56Ii4EB4p2/thfKoeqgVwTa9Hflus0LsOD+iqK3RFwAZ9x+sBoHI5KfUAzHCrsg9Wd689dRY= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356501387CDC3F0A091DE10ED8FB0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aef471d1-88ec-4da8-c224-08d6ffb7752e X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 13:07:52.9160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4221 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 13:07:58 -0000 --_000_MN2PR11MB356501387CDC3F0A091DE10ED8FB0MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGFyZSBjb3JyZWN0LCBhbmQgSSBzYWlkIOKAnSBtb3JlIGNoYW5jZXMgaWYgdGhlIHJvdXRl ciBpcyB3aXJlbGVzc+KAnSBtZWFuaW5nIHRoYXQgdGhlIHJvdXRlciBpcyBvbiB0aGUgU1RBIHNp ZGUgb3IgYSBMMyB3aXJlbGVzcyBicmlkZ2UuDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGFzY2FsDQoN CkZyb206IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPg0KU2VudDogbWVyY3Jl ZGkgMyBqdWlsbGV0IDIwMTkgMTU6MDENClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxw dGh1YmVydEBjaXNjby5jb20+DQpDYzogSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPjsg VjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPjsgNm1hbiA8Nm1hbkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbdjZvcHNdIE5EIGNhY2hlIGVudHJpZXMgY3JlYXRpb24gb24gZmlyc3QtaG9wIHJv dXRlcnMNCg0KT24gV2VkLCBKdWwgMywgMjAxOSBhdCA5OjU2IFBNIFBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbTxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPj4g d3JvdGU6DQotICBtdWx0aWNhc3QgTkEgbWF5IGJlIGxvc3QsIG1vcmUgY2hhbmNlcyBvZiB0aGF0 IGlmIHRoZSByb3V0ZXIgaXMgd2lyZWxlc3MuIFlvdSBtYXkgd2FudCBzb21ldGhpbmcgYSBiaXQg bW9yZSByb2J1c3Qgd2l0aCBhbiBhY2tub3dsZWRnZW1lbnQgYW5kIGEgbGlmZXRpbWUsIHNlZSBS RkMgODUwNS4NCg0KTm90IHRydWUgb24gd2lmaS4gTXVsdGljYXN0IHBhY2tldHMgYXJlIGFsd2F5 cyBzZW50IHRvIHRoZSBBUCBhcyB1bmljYXN0Lg0K --_000_MN2PR11MB356501387CDC3F0A091DE10ED8FB0MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44 NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGFy ZSBjb3JyZWN0LCBhbmQmbmJzcDtJIHNhaWQg4oCdIG1vcmUgY2hhbmNlcyBpZiB0aGUgcm91dGVy IGlzIHdpcmVsZXNz4oCdIG1lYW5pbmcgdGhhdCB0aGUgcm91dGVyIGlzIG9uIHRoZSBTVEEgc2lk ZSBvciBhIEwzIHdpcmVsZXNzIGJyaWRnZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIHRo ZSBiZXN0LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gTG9yZW56byBDb2xpdHRpICZsdDtsb3JlbnpvQGdvb2dsZS5j b20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBtZXJjcmVkaSAzIGp1aWxsZXQgMjAxOSAxNTowMTxi cj4NCjxiPlRvOjwvYj4gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7cHRodWJlcnRAY2lz Y28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSmVuIExpbmtvdmEgJmx0O2Z1cnJ5MTNAZ21haWwu Y29tJmd0OzsgVjYgT3BzIExpc3QgJmx0O3Y2b3BzQGlldGYub3JnJmd0OzsgNm1hbiAmbHQ7Nm1h bkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gTkQgY2FjaGUg ZW50cmllcyBjcmVhdGlvbiBvbiBmaXJzdC1ob3Agcm91dGVyczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCAzLCAyMDE5IGF0 IDk6NTYgUE0gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0 aHViZXJ0QGNpc2NvLmNvbSI+cHRodWJlcnRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mbmJzcDsgbXVsdGljYXN0 IE5BIG1heSBiZSBsb3N0LCBtb3JlIGNoYW5jZXMgb2YgdGhhdCBpZiB0aGUgcm91dGVyIGlzIHdp cmVsZXNzLiBZb3UgbWF5IHdhbnQgc29tZXRoaW5nIGEgYml0IG1vcmUgcm9idXN0IHdpdGggYW4g YWNrbm93bGVkZ2VtZW50IGFuZCBhIGxpZmV0aW1lLCBzZWUgUkZDIDg1MDUuDQo8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCB0 cnVlIG9uIHdpZmkuIE11bHRpY2FzdCBwYWNrZXRzIGFyZSBhbHdheXMgc2VudCB0byB0aGUgQVAg YXMgdW5pY2FzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB356501387CDC3F0A091DE10ED8FB0MN2PR11MB3565namp_-- From nobody Wed Jul 3 06:40:44 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1E1200F4; Wed, 3 Jul 2019 06:40:30 -0700 (PDT) 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, 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 header.b=XLLwMz8J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LS5LJpO1 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 KJhbwvCFH1v9; Wed, 3 Jul 2019 06:40:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96BD120091; Wed, 3 Jul 2019 06:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18462; q=dns/txt; s=iport; t=1562161227; x=1563370827; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3Hh0xrVYzXkIV1PBUSga4GHFCkEKsQUzCRYt34ujegs=; b=XLLwMz8J86Q3t+8Nelvb5F2KZgBxlpiXU9EYpSdcvl5XQbrkdgjRzV+o GlwAeW7jAtTP/R4S0ZodqHpSCUdoh56t+IFfR1JJNL1ad0W1RIdOnvCpW jiLCMCiQ/JCKSR9PrGqPawMvlpoJh6eBm0sun9H+feErUS2b3daTjQ86J M=; IronPort-PHdr: =?us-ascii?q?9a23=3Akx2S4RcHoNxOFCNjAowbYQgdlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAAClrxxd/5xdJa1lHQEBBQEHBQG?= =?us-ascii?q?BVQYBCwGBFC9QA2pVIAQLKIQcg0cDjkWVTYRUgS6BJANUCQEBAQwBAS0CAQG?= =?us-ascii?q?EQAIXggsjNgcOAQMBAQQBAQIBBW2KNwyFSwIEEhEKEwEBNwEPAgEIQgICAjA?= =?us-ascii?q?lAgQODRqDAYEdTQMdAQKZZgKBOIhgcYEygnkBAQWFDxiCEgmBNAGLXheBQD+?= =?us-ascii?q?BV4JMPoQeKIMIMoImjjkvhHyWWwkCghaUGpdxpGMCBAIEBQIOAQEFgVcELYF?= =?us-ascii?q?YcBWDJ4JBg3GKU3KBKYoxglEBAQ?= X-IronPort-AV: E=Sophos;i="5.63,446,1557187200"; d="scan'208,217";a="587140117" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 13:40:26 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x63DeQPn024537 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 13:40:26 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 08:40:25 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 08:40:24 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 09:40:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3Hh0xrVYzXkIV1PBUSga4GHFCkEKsQUzCRYt34ujegs=; b=LS5LJpO1R1DCHaS9kKnqSTjb7FRjwJdAauBMaqVc2oobe6MqHW5fT66oPTtcj0agEA3Opmk+3rBYJ3UpcZHdbdehncj9jPbfPXXnT8Grdj3fSRnmKfq9/b8zM+WdhKsmEU8DbUQ1gI6AtxNfbzdmLzI6Y5v0oqNzUExGxglWFDQ= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3728.namprd11.prod.outlook.com (20.178.253.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Wed, 3 Jul 2019 13:40:23 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 13:40:23 +0000 From: "Pascal Thubert (pthubert)" To: Lorenzo Colitti CC: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, Jen Linkova , "6tisch@ietf.org" <6tisch@ietf.org>, "V6 Ops List" , 6man <6man@ietf.org> Thread-Topic: [6lo] ND cache entries creation on first-hop routers Thread-Index: AQHVMOxYqZ+Ae5ReXkiJP5a4XqZLuaa4gaXggABZVwCAAAcrcA== Date: Wed, 3 Jul 2019 13:39:59 +0000 Deferred-Delivery: Wed, 3 Jul 2019 13:39:13 +0000 Message-ID: References: <5377.1562081856@localhost> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46355770-ab01-4240-e8c5-08d6ffbbffac x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3728; x-ms-traffictypediagnostic: MN2PR11MB3728: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(39860400002)(136003)(199004)(189003)(5660300002)(86362001)(6916009)(186003)(102836004)(6506007)(54906003)(486006)(71200400001)(71190400001)(4326008)(46003)(6666004)(66574012)(52536014)(99286004)(7696005)(6116002)(790700001)(8936002)(76116006)(76176011)(66556008)(66946007)(316002)(66476007)(64756008)(73956011)(66446008)(74316002)(68736007)(25786009)(53936002)(8676002)(11346002)(446003)(6246003)(7736002)(33656002)(476003)(81156014)(81166006)(14454004)(54896002)(6306002)(9686003)(229853002)(55016002)(478600001)(256004)(14444005)(6436002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3728; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: S74BJ/IuRhIfH5mF8+XJa0Mym7BrOLqAswGjkbCf3y3NiY6kL+143AfSB8sXvWaeWFAib/koWIsxqlj7ySnVXA0wgfDoui7cy3AJNfAuq3RM1UWwsc4T2ld0xN1DC5rd6YSgm+G8jhDHCnxbR6J/RiJvGg5xDXo17vEscGR9UajHlLrz0kVjfE7c3+P8unF0yzTQV9hT6JXf4iDcuHK1dXnZHaLLICINrngM+OT0SEqdUk1rAkBuOND0/ai/90Qwl2UJd6URVOUo0ol3r3nBtVIpV4efJCtqdXtnF4YFF2Et+oGgrP6Wefuf+XHFu8IEkLluY/q4XD1kuic02LP8ECPenlZnbKv1QG5I2JoOOtXY+NmMuL6P4ulP/BiiBJOQGOQJG9GJKrrgr/Hl4jmt84vrHXrRo7VwE/ZonKF972M= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356585C9575813C746593E03D8FB0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 46355770-ab01-4240-e8c5-08d6ffbbffac X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 13:40:23.1693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3728 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 13:40:30 -0000 --_000_MN2PR11MB356585C9575813C746593E03D8FB0MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWdhaW4gTG9yZW56bywNCg0KRmlyc3QsIGNvbXBsZXhpdHkuIFJlY292ZXJpbmcgc3RhdGUg aW4gdGhlIHByZXNlbmNlIG9mIHJvdXRlciBjcmFzaGVzIGlzIGNvbXBsZXguDQoNCg0KICAqICAg VHJ1ZTsgc28gZmFyIHdlIGhhdmUgbm90IGRlc2lnbmVkIGZvciB0aGUgY2FzZSB3aGVyZSB0aGUg cm91dGVyIGRpZXMgYW5kIG5vLW9uZSBrbm93cy4gSW4gdGhlIGZhYnJpYyBtb2RlbHMsIHRoZSBy b3V0ZXIgcmVsYXlzIHRvIGEgY2VudHJhbCBtYXBwaW5nIHN5c3RlbSB0aGF0IGl0IGNhbiBxdWVy eSBsYXRlci4gVGhlIGNhc2Ugb2YgYW4gaW50ZXJtZWRpYXRlIG5ldHdvcmsgY291bGQgYmUgYWRk cmVzc2VkIGUuZy4sIHdpdGggYSBSQShJ4oCZbSBiYWNrKSwgYW4gaW50ZXJlc3Rpbmcgc3ViamVj dCBpZiA2TUFOIHRha2VzIG92ZXIgdGhlIHdvcmsuIENvbXBhcmUgdGhpcyB3aXRoIHRoZSBjYXNl IHdoZXJlIHRoZSByb3V0ZXIgY3Jhc2hlcywgbG9zZXMgYWxsIE5EIGNhY2hlcywgYW5kIGhhcyAx MDBzIG9mIGZsb3dzIHRocm91Z2ggZm9yIHdoaWNoIGEgZnVsbCBORCBvcGVyYXRpb24gKHB1bnQs IGxvb2t1cCwgcHJvZ3JhbSkgbXVzdCBiZSBkb25lIG9uIHRoZSBmaXJzdCBwYWNrZXQuDQoNCkFs c28sIGRlcGVuZGluZyBvbiB3aGF0IGd1YXJhbnRlZXMgdGhlIG5ldHdvcmsgbmVlZHMgdG8gcHJv dmlkZSB0byBob3N0cywgYSByZWdpc3RyYXRpb24tYmFzZWQgbW9kZWwgd2lsbCBsaWtlbHkgdXNl IG1vcmUgcm91dGVyIG1lbW9yeSBpbiB0aGUgY29tbW9uIGNhc2UgdGhhdCBtb3N0IGhvc3RzIGFy ZSB3ZWxsLWJlaGF2ZWQgKGJlY2F1c2UgaXQgY2Fubm90IGFnZ3Jlc3NpdmVseSB0aW1lIG91dCBl bnRyaWVzIHRoYXQgd2l0aCBjbGFzc2ljIE5EIGNhbiBzaW1wbHkgYmUgdGhyb3duIGF3YXkgYWZ0 ZXIgYSB3aGlsZSkuDQoNCg0Kw5ggICAgVGhlIHJvdXRlciBjYW4gcmVqZWN0IGEgcmVnaXN0cmF0 aW9uIGlmIG91dCBvZiBtZW1vcnkgYW5kIHRoZSBub2RlIG5lZWRzIHRvIHJlZ2lzdGVyIHNvbWV3 aGVyZSBlbHNlIG9yIGZyZWUgYW4gb2xkIHJlZ2lzdHJhdGlvbiBvZiBoaXMuIEF0IGxlYXN0IHRo ZSB1c2Ugb2YgbWVtb3J5IGlzIGRldGVybWluaXN0aWMuIENvbXBhcmUgdGhpcyB3aXRoIGFuIE5E IGNhY2hlIHRoYXQgaGFzIGxlc3Mgcm9vbSB0aGFuIHRoZSBhY3RpdmUgZmxvd3MsIExSVSB3aWxs IGNyZWF0ZSBhIHBlcm1hbmVudCBzaXR1YXRpb24gb2YgZmx1c2gvbG9va3VwLg0KDQoNClNlY29u ZCwgYW4gZXhwbGljaXQgcmVnaXN0cmF0aW9uIG1vZGVsIHdoZXJlIHRoZSByb3V0ZXIgY2FuIHJl ZnVzZSB0byBjcmVhdGUgYW4gYWRkcmVzcyBlbnRyeSBwcm92aWRlcyBhIHN1cHBvcnRlZCBwYXRo IGZvciBvcGVyYXRvcnMgdG8gbGltaXQgdGhlIG51bWJlciBvZiBJUCBhZGRyZXNzZXMgdXNlZCBi eSBob3N0cywgd2hpY2ggaGFzIHRoZSBuZWdhdGl2ZSBjb25zZXF1ZW5jZXMgZGVzY3JpYmVkIGlu IFJGQyA3OTM0LiBJbiBmYWN0LCBzdWNoIGEgbW9kZWwgaXMgZXhwbGljaXRseSBOT1QgUkVDT01N RU5ERUQgYnkgUkZDIDc5MzQgZm9yIGdlbmVyYWwtcHVycG9zZSBob3N0cy4gVGhlIHJlbGV2YW50 IHRleHQgaXMgIml0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIG5ldHdvcmsgZ2l2ZSB0aGUgaG9z dCB0aGUgYWJpbGl0eSB0byB1c2UgbmV3IGFkZHJlc3NlcyB3aXRob3V0IHJlcXVpcmluZyBleHBs aWNpdCByZXF1ZXN0cy4iDQoNCg0KDQoNCsOYICBUaGUgcm91dGVyIGNhbiBhbHdheXMgcmVmcmFp biBmcm9tIGNyZWF0aW5nIGFuIE5DRSBpZiBpdCBkb2VzIG5vdCB3YW50IHRvLCBlLmcuLCBieSBw b2xpY2llcyB0aGF0IHByb3RlY3QgdGhlIE5EIGNhY2hlLiBUaGUgcmVnaXN0cmF0aW9uIGRvZXMg bm90IGNyZWF0ZSB0aGF0IHNpdHVhdGlvbi4gVGhhbmtzIHRvIHlvdXIgY29udHJpYnV0aW9uLCBS RkMgODUwNSBTSE9VTERzIGNvbmZvcm1hbmNlIHRvIFJGQyA3OTM0IGFuZCBoYXMg4oCcVGhlIGFi aWxpdHkgdG8gcmV0dXJuIGVycm9ycyB0byBhZGRyZXNzIHJlZ2lzdHJhdGlvbnMgaXMgbm90IGlu dGVuZGVkIHRvIGJlIHVzZWQgdG8gcmVzdHJpY3QgdGhlIGFiaWxpdHkgb2YgaG9zdHMgdG8gZm9y bSBhbmQgdXNlIG11bHRpcGxlIGFkZHJlc3Nlcy4g4oCcLiBUaGUgcmVzdCBpcyBpbiB0aGUgaGFu ZHMgb2YgdGhlIG5ldHdvcmsgYWRtaW5zLCBtYWtlIHN1cmUgdGhleSBkZXBsb3kgcmVzb3VyY2Vz IGFkZXF1YXRlbHkuDQoNCg0KDQpDaGVlcnM7DQoNCg0KDQpQYXNjYWwNCg== --_000_MN2PR11MB356585C9575813C746593E03D8FB0MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3 MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNjczMzU3 NjA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05NDc3 NjUxNzYgMTkwNTc5OTczNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlk aS1mb250LWZhbWlseTpBcmlhbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE4NDU0MzE5MDY7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjMxNzcyMDY3MiAtMTYzNzcw ODYzNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjM7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eTpBcmlhbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPkhpIGFnYWluIExvcmVuem8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Rmlyc3Qs IGNvbXBsZXhpdHkuIFJlY292ZXJpbmcgc3RhdGUgaW4gdGhlIHByZXNlbmNlIG9mIHJvdXRlciBj cmFzaGVzIGlzIGNvbXBsZXguDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UcnVlOyBzbyBm YXIgd2UgaGF2ZSBub3QgZGVzaWduZWQgZm9yIHRoZSBjYXNlIHdoZXJlIHRoZSByb3V0ZXIgZGll cyBhbmQgbm8tb25lIGtub3dzLiBJbiB0aGUgZmFicmljIG1vZGVscywgdGhlIHJvdXRlciByZWxh eXMgdG8gYSBjZW50cmFsIG1hcHBpbmcgc3lzdGVtDQogdGhhdCBpdCBjYW4gcXVlcnkgbGF0ZXIu IFRoZSBjYXNlIG9mIGFuIGludGVybWVkaWF0ZSBuZXR3b3JrIGNvdWxkIGJlIGFkZHJlc3NlZCBl LmcuLCB3aXRoIGEgUkEoSeKAmW0gYmFjayksIGFuIGludGVyZXN0aW5nIHN1YmplY3QgaWYgNk1B TiB0YWtlcyBvdmVyIHRoZSB3b3JrLiBDb21wYXJlIHRoaXMgd2l0aCB0aGUgY2FzZSB3aGVyZSB0 aGUgcm91dGVyIGNyYXNoZXMsIGxvc2VzIGFsbCBORCBjYWNoZXMsIGFuZCBoYXMgMTAwcyBvZiBm bG93cyB0aHJvdWdoDQogZm9yIHdoaWNoIGEgZnVsbCBORCBvcGVyYXRpb24gKHB1bnQsIGxvb2t1 cCwgcHJvZ3JhbSkgbXVzdCBiZSBkb25lIG9uIHRoZSBmaXJzdCBwYWNrZXQuPG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BbHNvLCBkZXBlbmRpbmcgb24g d2hhdCBndWFyYW50ZWVzIHRoZSBuZXR3b3JrIG5lZWRzIHRvIHByb3ZpZGUgdG8gaG9zdHMsIGEg cmVnaXN0cmF0aW9uLWJhc2VkIG1vZGVsIHdpbGwgbGlrZWx5IHVzZSBtb3JlIHJvdXRlciBtZW1v cnkgaW4gdGhlIGNvbW1vbiBjYXNlIHRoYXQgbW9zdCBob3N0cyBhcmUgd2VsbC1iZWhhdmVkIChi ZWNhdXNlIGl0IGNhbm5vdA0KIGFnZ3Jlc3NpdmVseSB0aW1lIG91dCBlbnRyaWVzIHRoYXQgd2l0 aCBjbGFzc2ljIE5EIGNhbiBzaW1wbHkgYmUgdGhyb3duIGF3YXkgYWZ0ZXIgYSB3aGlsZSkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO3Rl eHQtaW5kZW50OjBjbTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3Mi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhl IHJvdXRlciBjYW4gcmVqZWN0IGEgcmVnaXN0cmF0aW9uIGlmIG91dCBvZiBtZW1vcnkgYW5kIHRo ZSBub2RlIG5lZWRzIHRvIHJlZ2lzdGVyIHNvbWV3aGVyZSBlbHNlIG9yIGZyZWUgYW4gb2xkIHJl Z2lzdHJhdGlvbiBvZiBoaXMuIEF0IGxlYXN0IHRoZSB1c2Ugb2YgbWVtb3J5IGlzIGRldGVybWlu aXN0aWMuIENvbXBhcmUgdGhpcyB3aXRoDQogYW4gTkQgY2FjaGUgdGhhdCBoYXMgbGVzcyByb29t IHRoYW4gdGhlIGFjdGl2ZSBmbG93cywgTFJVIHdpbGwgY3JlYXRlIGEgcGVybWFuZW50IHNpdHVh dGlvbiBvZiBmbHVzaC9sb29rdXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+U2Vjb25kLCBh biBleHBsaWNpdCByZWdpc3RyYXRpb24gbW9kZWwgd2hlcmUgdGhlIHJvdXRlciBjYW4gcmVmdXNl IHRvIGNyZWF0ZSBhbiBhZGRyZXNzIGVudHJ5IHByb3ZpZGVzIGEgc3VwcG9ydGVkIHBhdGggZm9y IG9wZXJhdG9ycyB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIElQIGFkZHJlc3NlcyB1c2VkIGJ5IGhv c3RzLCB3aGljaCBoYXMgdGhlIG5lZ2F0aXZlDQogY29uc2VxdWVuY2VzIGRlc2NyaWJlZCBpbiBS RkMgNzkzNC4gSW4gZmFjdCwgc3VjaCBhIG1vZGVsIGlzIGV4cGxpY2l0bHkgTk9UIFJFQ09NTUVO REVEIGJ5IFJGQyA3OTM0IGZvciBnZW5lcmFsLXB1cnBvc2UgaG9zdHMuIFRoZSByZWxldmFudCB0 ZXh0IGlzICZxdW90O2l0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIG5ldHdvcmsgZ2l2ZSB0aGUg aG9zdCB0aGUgYWJpbGl0eSB0byB1c2UgbmV3IGFkZHJlc3NlcyB3aXRob3V0IHJlcXVpcmluZyBl eHBsaWNpdA0KIHJlcXVlc3RzLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSByb3V0ZXIgY2FuIGFsd2F5cyByZWZyYWluIGZy b20gY3JlYXRpbmcgYW4gTkNFIGlmIGl0IGRvZXMgbm90IHdhbnQgdG8sIGUuZy4sIGJ5IHBvbGlj aWVzIHRoYXQgcHJvdGVjdCB0aGUgTkQgY2FjaGUuIFRoZSByZWdpc3RyYXRpb24gZG9lcyBub3Qg Y3JlYXRlIHRoYXQgc2l0dWF0aW9uLiBUaGFua3MgdG8geW91ciBjb250cmlidXRpb24sIFJGQyA4 NTA1IFNIT1VMRHMgY29uZm9ybWFuY2UgdG8gUkZDIDc5MzQgYW5kIGhhcyDigJxUaGUgYWJpbGl0 eSB0byByZXR1cm4gZXJyb3JzIHRvIGFkZHJlc3MgcmVnaXN0cmF0aW9ucyBpcyBub3QgaW50ZW5k ZWQgdG8gYmUgdXNlZCB0byByZXN0cmljdCB0aGUgYWJpbGl0eSBvZiBob3N0cyB0byBmb3JtIGFu ZCB1c2UgbXVsdGlwbGUgYWRkcmVzc2VzLiDigJwuIFRoZSByZXN0IGlzIGluIHRoZSBoYW5kcyBv ZiB0aGUgbmV0d29yayBhZG1pbnMsIG1ha2Ugc3VyZSB0aGV5IGRlcGxveSByZXNvdXJjZXMgYWRl cXVhdGVseS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVyczs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlBhc2NhbDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_MN2PR11MB356585C9575813C746593E03D8FB0MN2PR11MB3565namp_-- From nobody Wed Jul 3 08:51:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423E01203A2; Wed, 3 Jul 2019 08:51:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 9m0nTVrKfayw; Wed, 3 Jul 2019 08:51:16 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 2678A120370; Wed, 3 Jul 2019 08:51:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EBAAAmzhxd/wUHmMZmDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQEBgVMEAQEBAQELAYFDUG11BDMKhBKDRwOEUolygluJTY15gS4?= =?us-ascii?q?UgRADGDwJAQEBDQEjCgIBAQKEPgIXggwjNAkOAQMBAQEEAQEBAQQBAgJpijcMg?= =?us-ascii?q?nhNLwoCMAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDyk?= =?us-ascii?q?eAQEYAQEBAQIBEhERDAEBJQcGBQELBAIBCA0EBAEBAQICJgICAh8RFQgIAgQBD?= =?us-ascii?q?QUIEweDAYFqAw4PAQICCpoPAoEIMIhfAQFwgTIaAoJdAQEFhQ8NC4ISAwYJAYE?= =?us-ascii?q?CKAGHbVSBf4EeF4FBPiZrRoJMPoIaRwQYgQs+FRWCXjKCJotyCAFLgiKaayxAC?= =?us-ascii?q?QKCFoZWgUGHdYFAgk6CK4ccg3kDEIoejTCBMIYNgXKOBAICAgIEBQIOAQEFgVA?= =?us-ascii?q?5gVhwFTuCbIJBg3GKGDtyAQGBJ4tUAYEVCwEB?= X-IPAS-Result: =?us-ascii?q?A2EBAAAmzhxd/wUHmMZmDgsBAQEBAQEBAQEBAQEHAQEBAQE?= =?us-ascii?q?BgVMEAQEBAQELAYFDUG11BDMKhBKDRwOEUolygluJTY15gS4UgRADGDwJAQEBD?= =?us-ascii?q?QEjCgIBAQKEPgIXggwjNAkOAQMBAQEEAQEBAQQBAgJpijcMgnhNLwoCMAEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDykeAQEYAQEBAQIBE?= =?us-ascii?q?hERDAEBJQcGBQELBAIBCA0EBAEBAQICJgICAh8RFQgIAgQBDQUIEweDAYFqAw4?= =?us-ascii?q?PAQICCpoPAoEIMIhfAQFwgTIaAoJdAQEFhQ8NC4ISAwYJAYECKAGHbVSBf4EeF?= =?us-ascii?q?4FBPiZrRoJMPoIaRwQYgQs+FRWCXjKCJotyCAFLgiKaayxACQKCFoZWgUGHdYF?= =?us-ascii?q?Agk6CK4ccg3kDEIoejTCBMIYNgXKOBAICAgIEBQIOAQEFgVA5gVhwFTuCbIJBg?= =?us-ascii?q?3GKGDtyAQGBJ4tUAYEVCwEB?= Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Jul 2019 11:51:12 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2019 11:51:09 -0400 Received: from PWEXCVMAP02.global.avaya.com (135.11.85.81) by AZ-US1EXHC02.global.avaya.com (135.11.85.13) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 3 Jul 2019 11:51:08 -0400 Received: from PWEXCVMAP02.global.avaya.com (135.11.85.81) by PWEXCVMAP02.global.avaya.com (135.11.85.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Wed, 3 Jul 2019 11:51:08 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by PWEXCVMAP02.global.avaya.com (135.11.85.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1531.3 via Frontend Transport; Wed, 3 Jul 2019 11:51:08 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.57) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Wed, 3 Jul 2019 10:51:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7lvNdTX6L3Mx3DvSf/UKqnh+q1/TcOlQd8bi/+0Bmgs=; b=K1gMkr+8eK/lbkKWhBVJrzZjcn7Wfiqw7Cms4lWvO+wekX7Pn1iUFzgwn0EDgdSYVNsGnsz3ParDOA434GshwCL2fQiKZOL9Zla8a4p4MEeGwpKjGMG+cMPh7XhPuKTPQOQidbhjeHE4jaidyEPYOCM2etqp+EfWggw1zTtOR9I= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB3290.namprd15.prod.outlook.com (20.179.51.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.17; Wed, 3 Jul 2019 15:51:06 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::697d:5307:1f7a:79bc]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::697d:5307:1f7a:79bc%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 15:51:06 +0000 From: "Mudric, Dusan (Dusan)" To: JORDI PALET MARTINEZ , Brian E Carpenter , Lea Roberts , "JORDI PALET MARTINEZ" CC: "draft-palet-v6ops-rfc6177-bis@ietf.org" , IPv6 Operations Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt Thread-Index: AQHVMY8hcok+ksVslk+ZIlaRClYvtaa5BJ8w Date: Wed, 3 Jul 2019 15:51:06 +0000 Message-ID: References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <0601C33E-0BB0-4C42-BCD2-B86FD90BBA6A@consulintel.es> In-Reply-To: <0601C33E-0BB0-4C42-BCD2-B86FD90BBA6A@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e60d1dd2-c6b5-42be-e5e7-08d6ffce426a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB3290; x-ms-traffictypediagnostic: DM6PR15MB3290: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(396003)(136003)(366004)(13464003)(59124004)(53754006)(189003)(199004)(6506007)(102836004)(55236004)(53546011)(446003)(476003)(11346002)(486006)(71200400001)(186003)(71190400001)(33656002)(966005)(26005)(66946007)(73956011)(76116006)(19627235002)(8936002)(66446008)(64756008)(66556008)(66476007)(478600001)(5024004)(14444005)(8676002)(30864003)(256004)(74316002)(76176011)(7696005)(305945005)(81156014)(81166006)(7736002)(99286004)(2906002)(229853002)(68736007)(6116002)(3846002)(2171002)(53936002)(66574012)(55016002)(6436002)(52536014)(53946003)(9686003)(6306002)(4326008)(6246003)(25786009)(86362001)(66066001)(5660300002)(54906003)(110136005)(316002)(14454004)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB3290; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: L5MZCBI4et/gn86xSSJifTlov5Dz6dit6aEg0HCUeLiVgKpkCqW7Adpk9eq1D0HsDuBNLbLUBDlQixNPJjVErmqR+hdoV2xGm2uIOQfAmzpCJEIpPeAm8USNpt7Bgu5VGIjo5JMZEoE3U8k1fcgz8xw5lEjk3/UN4DWDKMSYbPqQLAKw/bi71iQSvwixK9A1SWJf2lWz4Np5pksC25gVhSwMeh2Gac1HtlraZzq9JY8neIik6W76JjiXuYB42W4SECbqeglbIRMQzyNqniCJrG0kpIYM7YYAGVTW/x5tRTZOpWfwZG5GYQvngXolRW/SSSvgRb4coxjwXzs2BjTwrInQE73nhaCGqJ+eVT1EyBQm8lkmvu+uLvizO/mgVaIfSvbTm+tjaKHEtMTicjjGXb51sqjTW31W12LnhozxEMc= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e60d1dd2-c6b5-42be-e5e7-08d6ffce426a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 15:51:06.0462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3290 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 15:51:19 -0000 SGkgSm9yZGksDQoNCmRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzLCBzZWN0aW9uIDUuMiwg ZGVmaW5lczoNCiJyb3V0ZXJzIGRlc2lnbmVkIHRvIHJ1biBJUHY2IHNob3VsZA0KICAgc3VwcG9y dCB0aGUgZm9sbG93aW5nIGFkZHJlc3NpbmcgY29udmVudGlvbnM6DQogICBvICBUaGUgZGVmYXVs dCBwcmVmaXggbGVuZ3RoIG9uIGFueSBpbnRlcmZhY2Ugb3RoZXIgdGhhbiBhIGxvb3BiYWNrDQog ICAgICBzaG91bGQgYmUgYSAvNjQiDQoNCk1heSBiZSBhIG5ldyBidWxsZXQgY2FuIGJlIGFkZGVk IHRvIG1ha2Ugc3VyZSBhIHJvdXRlciBhc2tpbmcgZm9yIC80OCBvciAvNTYgcHJlZml4IHdpbGwg Z2V0IGl0LiBPdGhlcndpc2UsIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRvIGRvIFNMQUFDIHN1 Ym5ldHRpbmcuIEN1cnJlbnQgc3RhbmRhcmRzIGRvbid0IGFsbG93IFNMQUFDIGZvciBwcmVmaXhl cyBsb25nZXIgdGhhbiAvNjQuIE9yLCBpZiB0aGUgZGVmYXVsdCBwcmVmaXggbGVuZ3RoIGlzIC80 OCBvciAvNTYsIHRoZSBpc3N1ZSBvZiBub3QgZ2V0dGluZyBhIHNob3J0ZXIgcHJlZml4IGZyb20g SVNQcyB3aWxsIGJlIHNvbHZlZC4gUGVyc29uYWxseSwgSSBkb24ndCBsaWtlIHdhc3RpbmcgdGhl IGFkZHJlc3Mgc3BhY2UuIFlvdSBzdGF0ZWQgdGhlIHNhbWUgaW4gdGhlIEludHJvZHVjdGlvbiwg YnVsbGV0IDMuIEZyb20gdGhhdCBwZXJzcGVjdGl2ZSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHN0 YXJ0IHNtYWxsIGFuZCBiZSBhYmxlIHRvIGdyb3csIG9uIGFzIG5lZWRlZCBiYXNlcywgd2l0aG91 dCBiZWluZyBibG9ja2VkIGJ5IElTUHMuIFNvLCB0aWxsIHdlIGhhdmUgYSBzdGFuZGFyZCBmb3Ig U0xBQUNzIHdpdGggcHJlZml4ZXMgbG9uZ2VyIHRoYW4gLzY0LCBpdCBzaG91bGQgYmUgYWx3YXlz IHBvc3NpYmxlIHRvIGdldCAvNDggb3IgLzU2IHByZWZpeCwgd2hlbiBuZWVkZWQsIHdpdGhvdXQg YW55IGxpbWl0YXRpb25zLiBBdCB0aGUgbW9tZW50IEkgZG9uJ3Qgc2VlIGhvdyB0aGF0IGNhbiBi ZSBlbmZvcmNlZCB3aXRob3V0IHNldHRpbmdzIHNvbWUgZGVmYXVsdHMgdG8gLzQ4IG9yIC81NiAo bm90IHBvcHVsYXIgYXBwcm9hY2gpLg0KDQpSZWdhcmRzLA0KRHVzYW4uDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSk9SREkgUEFMRVQgTUFSVElORVogPGpvcmRpLnBh bGV0QGNvbnN1bGludGVsLmVzPg0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMywgMjAxOSA3OjAz IEFNDQo+IFRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29t PjsgTXVkcmljLCBEdXNhbg0KPiAoRHVzYW4pIDxkbXVkcmljQGF2YXlhLmNvbT47IExlYSBSb2Jl cnRzIDxsZWEucm9iZXJ0c0BzdGFuZm9yZC5lZHU+Ow0KPiBKT1JESSBQQUxFVCBNQVJUSU5FWiA8 am9yZGkucGFsZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0 LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnOyBJUHY2IE9wZXJhdGlvbnMNCj4gPHY2 b3BzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1w YWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMC50eHQNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEkndmUg YmVlbiB0b28gYnVzeSB0byB0YWNrbGUgYSBuZXcgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50LCBi dXQgbm93DQo+IHdvcmtpbmcgb24gaXQuDQo+IA0KPiBNeSByZWNhbGwgb24gdGhpcywgcGxlYXNl IGNvcnJlY3QgbWUgaWYgSSdtIHdyb25nIChCcmlhbiwgTXVkcmljKSwgaXMgdGhhdCB5b3UNCj4g YmVsaWV2ZSB0aGF0Og0KPiANCj4gMSkgV2Ugc2hvdWxkIGRlZmluZSBlbmQtc2l0ZSBpbiB0aGUg ZG9jdW1lbnQ/DQo+IA0KPiAyKSBFbmQtc2l0ZXMgbXVzdCBiZSBhYmxlIHRvIHJlcXVlc3QgYSBs b25nZXIgcHJlZml4IGlmIG5lZWRlZCBhbmQgdGhlIElTUA0KPiBtdXN0IGdyYW50IGl0Pw0KPiAN Cj4gQW55dGhpbmcgSSBtYXkgYmUgbWlzc2luZz8NCj4gDQo+IFJlZ2FyZHMsDQo+IEpvcmRpDQo+ IEBqb3JkaXBhbGV0DQo+IA0KPiANCj4gDQo+IO+7v0VsIDI4LzgvMTggNjoyNywgInY2b3BzIGVu IG5vbWJyZSBkZSBCcmlhbiBFIENhcnBlbnRlciIgPHY2b3BzLQ0KPiBib3VuY2VzQGlldGYub3Jn IGVuIG5vbWJyZSBkZSBicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IGVzY3JpYmnDszoNCj4g DQo+ICAgICBPbiAyMDE4LTA4LTI4IDA2OjIzLCBNdWRyaWMsIER1c2FuIChEdXNhbikgd3JvdGU6 DQo+ICAgICA+IFNlY3Rpb24gNC4NCj4gICAgID4gIiAgIGIuICBBbiBlbmQtdXNlciBzaG91bGQg YmUgYWJsZSB0byByZWNlaXZlIGFueSBwcmVmaXggbGVuZ3RoIHVwIHRvIC80OA0KPiAgICAgPiAg ICAgICAgc2ltcGx5IGJ5IGFza2luZy4iDQo+ICAgICA+DQo+ICAgICA+IENhbiAgdGhpcyBiZSBk ZWZpbmVkIGluIGEgd2F5IHRvIG1ha2Ugc3VyZSB0aGF0IG5ldyBhcHBsaWNhdGlvbnMgYW5kDQo+ IGRldmljZXMgd2lsbCBhbHdheXMgd29yayBhdCBlbmQgc2l0ZXMgd2l0aG91dCBhIG5lZWQgZm9y IGFza2luZyBJU1BzIGZvciBleHRyYQ0KPiBhZGRyZXNzIHNwYWNlPyBPdGhlcndpc2UsIHRoZSBl bmQtdXNlciBtaWdodCBub3QgZ2V0IHdoYXQgaGUvc2hlIGFza3MgZm9yLA0KPiB3aXRob3V0IHBh eWluZyBmb3IgdGhlICJoaWdoZXIgZ3JhZGUiIHNlcnZpY2UuIENhbiB0aGUgZGVmaW5pdGlvbiBp bXBvc2UgdXANCj4gdG8gLzQ4IExBUCB3aGVuIG5lZWRlZCBhdCBlbmQgc2l0ZXM/IEZvciBleGFt cGxlLCBjYW4gYW4gYXBwbGljYXRpb24NCj4gcmVxdWVzdCBhIGhvbWUgcm91dGVyIHRvIHJlcXVl c3QgYW4gSVNQIGZvciAvNDggcHJlZml4IGFuZCwgd2hlbiByZXF1ZXN0ZWQsDQo+IElTUCBtdXN0 IGdyYW50IGl0Pw0KPiANCj4gICAgIFVuZm9ydHVuYXRlbHkgd2UgY2FuIG5ldmVyIHNheSAibXVz dCIgaW4gdGhpcyBjb250ZXh0LiBXaGF0IElTUHMgd2lsbA0KPiBwcm92aWRlDQo+ICAgICBmb3Ig d2hhdCBmZWUgaXMgd2VsbCBvdXRzaWRlIHRoZSBJRVRGJ3MgY29tcGV0ZW5jZS4gQXMgb2JzZXJ2 ZWQgb24NCj4gYW5vdGhlcg0KPiAgICAgdGhyZWFkLCBhcHBsaWNhdGlvbnMgbmVlZCB0byBiZSBh Z2lsZSwgZXZlbiBpZiB0aGV5IHdvcmsgYmV0dGVyIGlmIHN1Y2ggYQ0KPiAgICAgcmVxdWVzdCB3 YXMgZ3JhbnRlZC4NCj4gDQo+ICAgICBJJ2Qgc2F5IHRoYXQgb25jZSB0aGlzIHVwZGF0ZSBpcyBk b25lLCBpdCBtYXkgYmUgdGltZSB0byByZXZpc2l0DQo+ICAgICBSRkM0MDg0Lg0KPiANCj4gICAg IFJlZ2FyZHMNCj4gICAgICAgICBCcmlhbg0KPiANCj4gICAgID4NCj4gICAgID4gUmVnYXJkcywN Cj4gICAgID4gRHVzYW4gTXVkcmljLg0KPiAgICAgPg0KPiAgICAgPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gICAgID4+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgTGVhIFJvYmVydHMNCj4gICAgID4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5 IDE5LCAyMDE4IDI6MDggUE0NCj4gICAgID4+IFRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tPjsgSk9SREkgUEFMRVQNCj4gICAgID4+IE1BUlRJTkVaIDxq b3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnPg0KPiAgICAgPj4gQ2M6 IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnOyBJUHY2IE9wZXJhdGlvbnMN Cj4gICAgID4+IDx2Nm9wc0BpZXRmLm9yZz4NCj4gICAgID4+IFN1YmplY3Q6IFJlOiBbdjZvcHNd IEktRCBBY3Rpb246IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzLTAwLnR4dA0KPiAgICAg Pj4NCj4gICAgID4+IGhpIEJyaWFuIGFuZCBKb3JkaSAtDQo+ICAgICA+Pg0KPiAgICAgPj4gZXhj ZWxsZW50IGNvbW1lbnRzIGFuZCBJIGFncmVlIGFsc28uDQo+ICAgICA+Pg0KPiAgICAgPj4gdGhh bmsgeW91ISENCj4gICAgID4+IC9MZWENCj4gICAgID4+DQo+ICAgICA+PiBPbiBUaHUsIDE5IEp1 bCAyMDE4LCBKT1JESSBQQUxFVCBNQVJUSU5FWiB3cm90ZToNCj4gICAgID4+DQo+ICAgICA+Pj4g SGkgQnJpYW4sDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gVGhh bmtzIGEgbG90IGZvciBjb21tZW50aW5nIGFuZCBzb3JyeSB0aGUgbGF0ZSBhbnN3ZXIgLi4uIHRv byBidXN5IGxhc3QNCj4gICAgID4+IHdlZWtzLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAg ID4+Pg0KPiAgICAgPj4+IENvbW1lbnRzIGluLWxpbmUgYmVsb3cgKHN1YmplY3RlZCB0byBteSBj by1hdXRob3IgYWdyZWVtZW50KSwNCj4gYmFzaWNhbGx5LA0KPiAgICAgPj4gYWdyZWUgd2l0aCBh bGwgeW91ciBpbnB1dHMsIGV4Y2VwdCBhIGNvdXBsZSBvZiBwb2ludHMuDQo+ICAgICA+Pj4NCj4g ICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gVGhhbmtzIQ0KPiAgICAgPj4+DQo+ICAgICA+ Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+IFJlZ2FyZHMsDQo+ICAgICA+Pj4NCj4gICAgID4+PiBK b3JkaQ0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4g77u/LS0tLS1NZW5zYWplIG9yaWdp bmFsLS0tLS0NCj4gICAgID4+Pg0KPiAgICAgPj4+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0Bp ZXRmLm9yZz4gZW4gbm9tYnJlIGRlIEJyaWFuIEUgQ2FycGVudGVyDQo+ICAgICA+PiA8YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gT3JnYW5pemFjaT9u OiBVbml2ZXJzaXR5IG9mIEF1Y2tsYW5kDQo+ICAgICA+Pj4NCj4gICAgID4+PiBGZWNoYTogZG9t aW5nbywgOCBkZSBqdWxpbyBkZSAyMDE4LCAxNzo0Mw0KPiAgICAgPj4+DQo+ICAgICA+Pj4gUGFy YTogPGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnPiwgSVB2NiBPcGVyYXRp b25zDQo+ICAgICA+PiA8djZvcHNAaWV0Zi5vcmc+DQo+ICAgICA+Pj4NCj4gICAgID4+PiBBc3Vu dG86IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlz LTAwLnR4dA0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIEhp LA0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIFRoYW5rcyBm b3IgdGhpcyBkcmFmdC4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+ PiAgICA+IEFic3RyYWN0DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4gICAgVGhpcyBuZWVkcyB0byBiZSBzaG9ydGVyLiBUaHJlZSBwYXJhZ3JhcGhzIGlzIHRvbyBt dWNoLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+IEZvciB0aGUg bmV4dCB2ZXJzaW9uLCBJJ3ZlIHJlZHVjZWQgNTAlIHRoZSBsZW5ndGggb2YgdGhlIDFzdCBwYXJh Z3JhcGguDQo+IDNyZA0KPiAgICAgPj4gcGFyYWdyYXBoLCBJIHJlY2FsbCBpcyBtYW5kYXRvcnkg KElETml0cykuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4g ICAgID4+Pg0KPiAgICAgPj4+ICAgID4gLi4uIHBvbGljeSBzaG91bGQgcmVmbGVjdCB0aGF0IGFz c2lnbm1lbnQgb2YgYSBzaW5nbGUgc3VibmV0IGlzDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ IG5vIGxvbmdlciBhcHByb3ByaWF0ZSB1bmxlc3MgdGhlIHJlY2lwaWVudCBleHBsaWNpdGx5IGFn cmVlcyB0byB0aGUNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gbGltaXRhdGlvbnMgaW1wbGll ZCBieSBzdWNoIGFuIGFzc2lnbm1lbnQuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ DQo+ICAgICA+Pj4gICAgSSAqc3Ryb25nbHkqIHN1Z2dlc3QgZGVsZXRpbmcgdGhlICJ1bmxlc3Mi IGNsYXVzZS4gSXQgbGVhdmVzIGENCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIGxvb3Bob2xlLCBh bmQgaXQgY291bGQgZWFzaWx5IGJlIGhpZGRlbiBpbiBzaHJpbmstd3JhcCB0ZXJtcw0KPiAgICAg Pj4+DQo+ICAgICA+Pj4gICAgYW5kIGNvbmRpdGlvbnMgc28gdGhhdCBhIHN1YnNjcmliZXIgd291 bGQgYWdyZWUgd2l0aG91dCBldmVuDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBrbm93aW5nIGFi b3V0IGl0LiBSZWR1Y2UgdGhpcyBzaW1wbHkgdG86DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAg ICAgPj4+DQo+ICAgICA+Pj4gICAgICAgLi4uIHBvbGljeSBzaG91bGQgcmVmbGVjdCB0aGF0IGFz c2lnbm1lbnQgb2YgYSBzaW5nbGUgc3VibmV0IGlzDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICAg ICBuZXZlciBhcHByb3ByaWF0ZS4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4g ICAgID4+PiBBZ3JlZWQgYW5kIGRvbmUuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gMS4gIEludHJvZHVjdGlvbg0K PiAgICAgPj4+DQo+ICAgICA+Pj4gICAgLi4uLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgPiAg ICAxLiAgSXQgaXMgZXh0cmVtZWx5IGRpc2NvdXJhZ2VkIHRoYXQgLzEyOHMgYmUgZ2l2ZW4gb3V0 LiAgV2hpbGUNCj4gdGhlcmUNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAgICAgIG1heSBi ZSBzb21lIGNhc2VzIHdoZXJlIGFzc2lnbmluZyBvbmx5IGEgc2luZ2xlIGFkZHJlc3MgbWF5DQo+ IGJlDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgICAgICBqdXN0aWZpZWQsIGEgc2l0ZSwg YnkgZGVmaW5pdGlvbiwgaW1wbGllcyBtdWx0aXBsZSBzdWJuZXRzIGFuZA0KPiAgICAgPj4+DQo+ ICAgICA+Pj4gICAgPiAgICAgICAgbXVsdGlwbGUgZGV2aWNlcy4NCj4gICAgID4+Pg0KPiAgICAg Pj4+DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBJIGZpbmQgdGhpcyBhIGJpdCB3ZWFrLiBUcnk6 DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgICAgMS4gIEl0 IGlzIGV4dHJlbWVseSBkaXNjb3VyYWdlZCB0aGF0IC8xMjhzIGJlIGdpdmVuIG91dC4gIFdoaWxl IHRoZXJlDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICAgICAgICAgbWF5IGJlIHNvbWUgYXBwbGlj YXRpb25zIHdoZXJlIGFzc2lnbmluZyBvbmx5IGEgc2luZ2xlIGFkZHJlc3MNCj4gbWF5DQo+ICAg ICA+PiBiZQ0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgICAgICAgIHRvbGVyYXRlZCwgYSBzaXRl LCBieSBkZWZpbml0aW9uLCBpbXBsaWVzIG11bHRpcGxlIHN1Ym5ldHMgYW5kDQo+ICAgICA+Pj4N Cj4gICAgID4+PiAgICAgICAgICAgbXVsdGlwbGUgZGV2aWNlcy4gQWxzbywgYSAvMTI4IHByZXZl bnRzIGFueSBmb3JtIG9mIHByaXZhY3ktYmFzZWQNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgICAg ICAgICBhZGRyZXNzaW5nLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAg Pj4+IEFncmVlZCENCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+PiAg ICA+ICAgIDQuICBUaGlzIHJldmlzaW9uIGhhcyBiZWVuIGNyZWF0ZWQgdG8gbW9yZSBjbGVhcmx5 IGFzc2VydCB0aGUNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAgICAgIHJlcXVpcmVtZW50 IHRvIGVuc3VyZSB0aGF0IGFkZHJlc3MgYXNzaWdubWVudHMgdG8gZW5kLXNpdGVzDQo+ICAgICA+ Pj4NCj4gICAgID4+PiAgICA+ICAgICAgICBwcm92aWRlIGEgc3VmZmljaWVudGx5IGJpZyBudW1i ZXIgb2Ygc3VibmV0cyAoLzY0IG9uIGNsYXNzaWMNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4g ICAgICAgIG5ldHdvcmtzKSB0byBlYWNoIGVuZC1zaXRlLCB0YWtpbmcgdW5kZXIgY29uc2lkZXJh dGlvbiB0aGUNCj4gZW5kLQ0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgPiAgICAgICAgc2l0ZSdz IGZ1dHVyZSBleHBlY3RlZCBuZWVkcywgbmV3IGRlcGxveW1lbnQgZXhwZWN0YXRpb25zDQo+IGFu ZA0KPiAgICAgPj4gbmV3DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgICAgICBwcm90b2Nv bCByZXF1aXJlbWVudHMsIGFtb25nIG90aGVycy4gIE9uY2UgYWxsIHRoZXNlIGFyZQ0KPiAgICAg Pj4+DQo+ICAgICA+Pj4gICAgPiAgICAgICAgY29uc2lkZXJlZCwgaXQgc2VlbXMgdW5saWtlbHkg dGhhdCBhIHNpbmdsZSBzdWJuZXQgKC82NCkgb3IgZXZlbg0KPiAgICAgPj4+DQo+ICAgICA+Pj4g ICAgPiAgICAgICAgYSBzbWFsbCBudW1iZXIgb2YgdGhlbSBzaG91bGQgYmUgYXNzaWduZWQsIHVu bGVzcyB2ZXJ5IGNsZWFybHkNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAgICAgIGp1c3Rp ZmllZCBhbmQgYWdyZWVkIHRvIGJ5IHRoZSBlbmQtc2l0ZS4NCj4gICAgID4+Pg0KPiAgICAgPj4+ DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBUaGUgInVubGVzcyIgY2xhdXNlIGlzIGRhbmdlcm91 cyBiZWNhdXNlIG9mIHNocmluay13cmFwIHRlcm1zIGFuZA0KPiAgICAgPj4+DQo+ICAgICA+Pj4g ICAgY29uZGl0aW9ucy4gSSBzdWdnZXN0IGRlbGV0aW5nIGl0Lg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+IEFncmVlZCENCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ ICAgICA+Pj4NCj4gICAgID4+PiAgICA+IDIuICBDb25zaWRlcmF0aW9ucyBSZWdhcmRpbmcgdGhl IFByZWZpeCBMZW5ndGgNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIC4uLi4NCj4gICAgID4+Pg0K PiAgICAgPj4+ICAgID4gICAgVGhpcyBjb25zaWRlcmF0aW9uIHNob3VsZCBiZSBub3RpY2VkLCBh Y3Jvc3MgdGhpcyBkb2N1bWVudCwgaW4gdGhlDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAg IHNlbnNlIHRoYXQgZW5kLXNpdGVzIHVzdWFsbHkgaGF2ZSBzdWJuZXRzIHRoYXQgdXNlLCBieSBk ZWZhdWx0LA0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgPiAgICBTTEFBQywgYW5kIGNvbnNlcXVl bnRseSwgdGhlIExBUCBpcyBtYW5kYXRvcmlseSBhIC82NC4gIE90aGVyDQo+ICAgICA+Pj4NCj4g ICAgID4+PiAgICA+ICAgIHRlY2hub2xvZ2llcywgbWF5IGhhdmUgYSBkaWZmZXJlbnQgTEFQLCB3 aGljaCBtdXN0IGJlIHVzZWQNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAgYWNjb3JkaW5n bHkuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgSSBzdWdn ZXN0IHMvT3RoZXIvRnV0dXJlLyBzaW5jZSAvNjQgcHJldmFpbHMgZXZlcnl3aGVyZSB0b2RheS4N Cj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+PiBBZ3JlZWQhDQo+ICAg ICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgPiAzLiAgT24gLzQ4IEFz c2lnbm1lbnRzIHRvIEVuZC1TaXRlcw0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgLi4uLg0KPiAg ICAgPj4+DQo+ICAgICA+Pj4gICAgPiAgICBBbiBpbXBvcnRhbnQNCj4gICAgID4+Pg0KPiAgICAg Pj4+ICAgID4gICAgZ29hbCBpbiBJUHY2IGlzIHRvIHNpZ25pZmljYW50bHkgY2hhbmdlIHRoZSBk ZWZhdWx0IGFuZCBtaW5pbWFsIGVuZA0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgPiAgICBzaXRl IGFzc2lnbm1lbnQsIGZyb20gImEgc2luZ2xlIGFkZHJlc3MiIHRvICJtdWx0aXBsZSBuZXR3b3Jr cyINCj4gYW5kDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgIHRvIGVuc3VyZSB0aGF0IGVu ZC1zaXRlcyBjYW4gZWFzaWx5IG9idGFpbiBhZGRyZXNzIHNwYWNlLg0KPiAgICAgPj4+DQo+ICAg ICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIEkgc3VnZ2VzdCBhZGRpbmcgc29tZXRoaW5n IGxpa2UgdGhpczoNCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+PiAg ICBBcyB0aGUgb3BlcmF0aW9uYWwgY29zdHMgb2YgY2Fycmllci1ncmFkZSBOQVQgYW5kIGFkZHJl c3MrcG9ydA0KPiBzaGFyaW5nDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBoYXZlIHNob3duLCBh dmFpbGFiaWxpdHkgb2YgbXVsdGlwbGUgYWRkcmVzc2VzIGFuZCBwcmVmaXhlcyB0byBlbmQNCj4g c2l0ZXMNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIHRoYXQgbmVlZCB0aGVtIHdpbGwgYmUgYSBj b25zaWRlcmFibGUgc2F2aW5nIHRvIHRoZWlyIElTUHMuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0K PiAgICAgPj4+DQo+ICAgICA+Pj4gQWdyZWVkIQ0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAg ID4+Pg0KPiAgICAgPj4+ICAgID4gICAgSXQgbWlnaHQgYmUgdGVtcHRpbmcgdG8gZ2l2ZSBob21l IHNpdGVzIGEgc2luZ2xlIC82NCwgc2luY2UgdGhhdCBpcw0KPiAgICAgPj4+DQo+ICAgICA+Pj4g ICAgPiAgICBhbHJlYWR5IHNpZ25pZmljYW50bHkgbW9yZSBhZGRyZXNzIHNwYWNlIGNvbXBhcmVk IHdpdGggdG9kYXkncw0KPiBJUHY0DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgIHByYWN0 aWNlLiAgSG93ZXZlciwgdGhpcyBwcmVjbHVkZXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgZXZlbg0K PiBob21lDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgIHNpdGVzIHdpbGwgZ3JvdyB0byBz dXBwb3J0IG11bHRpcGxlIHN1Ym5ldHMgZ29pbmcgZm9yd2FyZC4gIEhlbmNlLA0KPiBpdA0KPiAg ICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIHMvZXhwZWN0YXRpb24v Y2VydGFpbnR5Lw0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+IEFn cmVlZCENCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICAuLi4u DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgIEEga2V5IGdvYWwgb2YgdGhlIHJlY29tbWVu ZGF0aW9ucyBpbiBbUkZDMzE3N10gaXMgdG8NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAg ZW5zdXJlIHRoYXQgdXBvbiByZW51bWJlcmluZywgb25lIGRvZXMgbm90IGhhdmUgdG8gZGVhbCB3 aXRoDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgIHJlbnVtYmVyaW5nIGludG8gYSBzbWFs bGVyIHN1Ym5ldCBzaXplLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAg Pj4+ICAgIFBlcmhhcHMgYWRkOg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAg ICAgPj4+ICAgIEluIHBhcnRpY3VsYXIgdGhpcyB3b3VsZCBhcHBseSB0byBhbnkgc2l0ZSB0aGF0 IHN3aXRjaGVzIHRvDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBhbiBJU1AgdGhhdCBwcm92aWRl cyBhIGxvbmdlciBwcmVmaXguDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAg ICA+Pj4gQWdyZWVkIQ0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ ICAgID4gICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgc2ltaWxhciBhcmd1bWVudHMgYXBwbHkg dG8gdGhlDQo+IG1hbmFnZW1lbnQgb2YNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAgem9u ZSBmaWxlcyBpbiB0aGUgRE5TLiAgSW4gcGFydGljdWxhciwgbWFuYWdpbmcgdGhlIHJldmVyc2UN Cj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAgKGlwNi5hcnBhKSB0cmVlIGlzIHNpbXBsaWZp ZWQgd2hlbiBhbGwgbGlua3MgYXJlIG51bWJlcmVkIHVzaW5nIHRoZQ0KPiAgICAgPj4+DQo+ICAg ICA+Pj4gICAgPiAgICBzYW1lIHN1Ym5ldCBpZHMNCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAg ICA+Pj4NCj4gICAgID4+PiAgICBzL251bWJlcmVkL3JlbnVtYmVyZWQvDQo+ICAgICA+Pj4NCj4g ICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gQWdyZWVkIQ0KPiAgICAgPj4+DQo+ICAgICA+ Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIC4uLi4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAg ID4gICAgeWVhcnMsIGFuZCB3ZSBkb24ndCByZWNvdmVyIGJhY2sgdGhlIC80OCdzLCB3ZSB3aWxs IGJlIGFibGUgdG8gdXNlDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgIElQdjYgYWRkcmVz c2luZyBzcGFjZSBmb3Igb3ZlciAxMDAuMDAwIHllYXJzLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4N Cj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIFBlcmhhcHMgYWRkOg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgYWR2b2Nh dGUgY2FyZWxlc3MgdXNlIG9mIGFkZHJlc3Mgc3BhY2UsIGJ1dA0KPiAgICAgPj4+DQo+ICAgICA+ Pj4gICAgdGhlcmUgaXMgb2JqZWN0aXZlbHkgbm8gcmVhc29uIHRvIGJlIHJlc3RyaWN0dmUuDQo+ ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gQWdyZWVkIQ0KPiAgICAg Pj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIC4uLi4NCj4gICAgID4+Pg0K PiAgICAgPj4+ICAgID4gICAgVG9kYXkgdHlwaWNhbGx5LCBhIGhvbWUgaGFzIGFscmVhZHkgYSBj b25zaWRlcmFibGUgbnVtYmVyIG9mDQo+IHBvc3NpYmxlDQo+ICAgICA+Pj4NCj4gICAgID4+PiAg ICA+ICAgIHN1Ym5ldHMgKGEgY29tbW9uIENFIGhhcyA0IExBTiBwb3J0cywgMiBXaUZpIHJhZGlv cyB3aGljaA0KPiBzdXBwb3J0DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgIHNldmVyYWwg U1NJRHMgZWFjaCBvbmUsIFZvSVAgc3VibmV0LCBJUFRWIHN1Ym5ldCwgYWRkaXRpb25hbA0KPiBW TEFOcykNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAgYW5kIGlmIGRvd25zdHJlYW0gcm91 dGVycyBhcmUgdXNlZCwgdGhlcmUgaXMgYSBuZWVkIGZvciBmdXJ0aGVyDQo+ICAgICA+Pj4NCj4g ICAgID4+PiAgICA+ICAgIHN1Ym5ldHMuICBUaGlzIG1lYW5zIHRoYXQgaW4gYSBzaG9ydCB0ZXJt LCBhc3NpZ25pbmcgYSAvNjAgKDE2DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+ICAgIHN1Ym5l dHMpLCBpdCBpcyBhbHJlYWR5IGEgcmVhbGx5IGJhZCBkZWNpc2lvbiwgYXMgaXQgbWF5IGVuZm9y Y2UgSVB2Ng0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgPiAgICBOQVQgYmV0d2VlbiB0aGUgbWFp biBDRSBhbmQgZG93bnN0cmVhbSByb3V0ZXJzLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAg ID4+Pg0KPiAgICAgPj4+ICAgIEkgc3VnZ2VzdCBkZWxldGluZyAiYXMgaXQgbWF5IGVuZm9yY2Ug SVB2NiBOQVQgYmV0d2VlbiB0aGUgbWFpbiBDRQ0KPiBhbmQNCj4gICAgID4+Pg0KPiAgICAgPj4+ ICAgIGRvd25zdHJlYW0gcm91dGVycyIuIEZpcnN0bHkgaXQgcHV0cyBOQVQgaW50byB0aGUgcmVh ZGVyJ3MgbWluZC4NCj4gU2Vjb25kbHksDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBpdCBpc24n dCB0aGUgb25seSBzb2x1dGlvbiAtIElJRHMgc2hvcnRlciB0aGFuIDY0IGNvdWxkIGFsc28gYmUN Cj4gaW1wbGVtZW50ZWQuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4gQWdyZWVkIQ0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAg ID4gNC4gIEltcGFjdCBvbiBJUHY2IFN0YW5kYXJkcw0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4g ICAgID4+Pg0KPiAgICAgPj4+ICAgIEkgcHJvcG9zZSB0byBzaW1wbHkgZGVsZXRlIHRoaXMgc2Vj dGlvbi4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBGaXJz dGx5LCBSRkMzMDU2IGlzIGRlcHJlY2F0ZWQgc28gaXQncyBpcnJlbGV2YW50IHRvZGF5Lg0KPiAg ICAgPj4+DQo+ICAgICA+Pj4gICAgU2Vjb25kbHksIHRoZSBhcmd1bWVudCBhYm91dCBVTEFzIChS RkM0MTkzKSBkb2Vzbid0IGhvbGQgdXAuDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBVTEFzIGFy ZSBsaWtlIGFueSBvdGhlciAvNDggcHJlZml4IC0gaWYgeW91IGFyZSBmb3JjZWQgdG8NCj4gICAg ID4+Pg0KPiAgICAgPj4+ICAgIHJlbnVtYmVyIGludG8gYSBsb25nZXIgcHJlZml4LCB5b3UgbG9z ZSBzb21lIHN1Ym5ldCBiaXRzLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgVGhhdCBpcyBhbHJl YWR5IGNvdmVyZWQgaW4gdGhlIG1pZGRsZSBvZiBzZWN0aW9uIDMgKHRoZQ0KPiAgICAgPj4+DQo+ ICAgICA+Pj4gICAgImtleSBnb2FsIiBzZW50ZW5jZSBxdW90ZWQgYWJvdmUpLg0KPiAgICAgPj4+ DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+PiBJ IHJlY2FsbCB3ZSBkZXByZWNhdGVkIHRoZSA2dG80IGFueWNhc3QsIGJ1dCBub3QgNnRvNCwgaW4g ZmFjdCA2dG80IHRvDQo+IDZ0bzQNCj4gICAgID4+IHRyYWZmaWMgaXMgc3RpbGwgdXNlZnVsIGZv ciBwZWVyIHRvIHBlZXIuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4gICAgPiA2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCj4gICAgID4+Pg0KPiAgICAgPj4+ ICAgID4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4gICAgVGhpcyBkb2N1bWVudCBoYXMgbm8g a25vd24gc2VjdXJpdHkgaW1wbGljYXRpb25zLg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAg ID4+Pg0KPiAgICAgPj4+ICAgIFJlYWxseT8gTW9yZSBwcmVmaXggc3BhY2Ugb2ZmZXJzIG1vcmUg cG90ZW50aWFsIGZvciBzY2FubmluZw0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgYXR0YWNrcy4g TW9yZSBwcmVmaXggc3BhY2UgYWxzbyBhbGxvd3MgdGhlIHVzZSBvZiBzbGlnaHRseQ0KPiAgICAg Pj4+DQo+ICAgICA+Pj4gICAgcmFuZG9taXplZCBwcmVmaXhlcyBhbmQvb3IgcHJlZml4LXBlciBo b3N0Lg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIEFsc28g b2YgY291cnNlLCBhIC8xMjggd291bGQgcHJldmVudCBhbnkgZm9ybSBvZiBwcml2YWN5LWJhc2Vk DQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBhZGRyZXNzaW5nLg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+IEkndmUgaW50cm9kdWNlZCBuZXcgdGV4dCBvbiB0aG9z ZSBwb2ludHMuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAg PiA4LiAgQWNrbm93bGVkZ2VtZW50cw0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgPg0KPiAgICAg Pj4+DQo+ICAgICA+Pj4gICAgPiAgICBUaGUgYXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50IHdpbGwg bGlrZSB0byBhY2tub3dsZWRnZSB0aGUgYXV0aG9ycw0KPiBvZg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4gICAgPiAgICBwcmV2aW91cyB2ZXJzaW9ucyAoVGhvbWFzIE5hcnRlbiBhbmQgR2VvZmYgSHVz dG9uKQ0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIFJGQzMx Nzcgd2FzIHNpZ25lZCBieSB0aGUgd2hvbGUgSUFCIGFuZCBJRVNHIHNlYXRlZCBpbiAyMDAxLCBh bmQgaXRzDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICBBY2tub3dsZWRnZW1lbnRzIHJlYWQ6DQo+ ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gICAgPj4gICAgVGhpcyBk b2N1bWVudCBvcmlnaW5hdGVkIGZyb20gdGhlIElFVEYgSVB2NiBkaXJlY3RvcmF0ZSwgd2l0aA0K PiBtdWNoDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+PiAgICBpbnB1dCBmcm9tIHRoZSBJQUIg YW5kIElFU0cuICBUaGUgb3JpZ2luYWwgdGV4dCBmb3JtaW5nIHRoZSBiYXNpcw0KPiBvZg0KPiAg ICAgPj4+DQo+ICAgICA+Pj4gICAgPj4gICAgdGhpcyBkb2N1bWVudCB3YXMgY29udHJpYnV0ZWQg YnkgRnJlZCBCYWtlciBhbmQgQnJpYW4NCj4gQ2FycGVudGVyLg0KPiAgICAgPj4+DQo+ICAgICA+ Pj4gICAgPj4gICAgQWxsaXNvbiBNYW5raW4gYW5kIFRob21hcyBOYXJ0ZW4gbWVyZ2VkIHRoZSBv cmlnaW5hbA0KPiBjb250cmlidXRpb25zDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICA+PiAgICBp bnRvIGEgc2luZ2xlIGRvY3VtZW50LCBhbmQgQWxhaW4gRHVyYW5kIGVkaXRlZCB0aGUgZG9jdW1l bnQNCj4gICAgID4+IHRocm91Z2gNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgID4+ICAgIGl0cyBm aW5hbCBzdGFnZXMuDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4g QWdyZWVkIQ0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIFJl Z2FyZHMNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgICAgICBCcmlhbg0KPiAgICAgPj4+DQo+ICAg ICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ICAgICA+Pj4NCj4gICAgID4+PiAgICB2Nm9wcyBtYWls aW5nIGxpc3QNCj4gICAgID4+Pg0KPiAgICAgPj4+ICAgIHY2b3BzQGlldGYub3JnDQo+ICAgICA+ Pj4NCj4gICAgID4+PiAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtDQo+ICAgICA+Pg0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f djZvcHMmZD1Ed0lEYVEmYz1CRnBXUXc4YnN1S3ANCj4gICAgID4+DQo+IGwxU2dpWkg2NFEmcj1V VDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09LQ0KPiAgICAgPj4N Cj4gNXJnWXFfbllNYlNIMkhYSG5IRkNGaTJLRFl6T0NsaFNpTG4wYXU4V3UwJnM9aUVxMXRVRGJl UUw0ZjNTTE0NCj4gICAgID4+IGYxLXhpaGpKWVQwS0FBTl9CV1RsOS03NzljJmU9DQo+ICAgICA+ Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+ DQo+ICAgICA+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KPiAgICAgPj4+IElQdjQgaXMgb3Zlcg0KPiAgICAgPj4+IEFyZSB5b3UgcmVhZHkgZm9yIHRo ZSBuZXcgSW50ZXJuZXQgPw0KPiAgICAgPj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwLQ0KPiAgICAgPj4NCj4gM0FfX3d3dy5jb25zdWxpbnRlbC5lcyZk PUR3SURhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDMNCj4gICAgID4+IEJrOWNiTGVh SnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT0tDQo+ICAgICA+Pg0KPiA1cmdZcV9u WU1iU0gySFhIbkhGQ0ZpMktEWXpPQ2xoU2lMbjBhdThXdTAmcz1HTVJMZEl0Rjh5S2JVZEU5DQo+ ICAgICA+PiBOdVhFLVU0OHVrN09ITnVFaWp5bTlqaEUtLXMmZT0NCj4gICAgID4+PiBUaGUgSVB2 NiBDb21wYW55DQo+ICAgICA+Pj4NCj4gICAgID4+PiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBj b250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZA0KPiBvcg0KPiAgICAg Pj4gY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mDQo+IHRoZQ0KPiAgICAgPj4gaW5kaXZpZHVhbChzKSBuYW1lZCBh Ym92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkDQo+IGRpc2Nsb3N1cmUs DQo+ICAgICA+PiBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBv ZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmDQo+ICAgICA+PiBwYXJ0aWFsbHksIGluY2x1ZGlu ZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZQ0KPiBj b25zaWRlcmVkIGENCj4gICAgID4+IGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdA0KPiBhbnkNCj4gICAgID4+IGRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMNCj4gaW5mb3JtYXRpb24sDQo+ICAgICA+PiBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5n IGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlDQo+ICAgICA+ PiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhl IG9yaWdpbmFsIHNlbmRlcg0KPiB0bw0KPiAgICAgPj4gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVu aWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0K PiAgICAgPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ICAgICA+Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ICAgICA+Pj4gdjZvcHNAaWV0Zi5vcmcN Cj4gICAgID4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtDQo+ICAgICA+Pg0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMm ZD1Ed0lEYVEmYz1CRnBXUXc4YnN1S3ANCj4gICAgID4+DQo+IGwxU2dpWkg2NFEmcj1VVDNCazlj YkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09LQ0KPiAgICAgPj4NCj4gNXJn WXFfbllNYlNIMkhYSG5IRkNGaTJLRFl6T0NsaFNpTG4wYXU4V3UwJnM9aUVxMXRVRGJlUUw0ZjNT TE0NCj4gICAgID4+IGYxLXhpaGpKWVQwS0FBTl9CV1RsOS03NzljJmU9DQo+IA0KPiAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgIHY2b3Bz IG1haWxpbmcgbGlzdA0KPiAgICAgdjZvcHNAaWV0Zi5vcmcNCj4gICAgIGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJRmFRJmM9QkZwV1F3OGJzdUtwbA0KPiAxU2dpWkg2 NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09cnpBYw0K PiBLUGhUcVh4R1ZRZC0NCj4gM0RvWmxNdXRlalE1Q1dvSW1KTnVDdWI3ajBzJnM9ZVVFMExTMEdD eTdyRVRscG1qRGN2emtaZVZUVjR0QlcNCj4gTm5GYWk0TWVKVDQmZT0NCj4gDQo+IA0KPiANCj4g DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gSVB2 NCBpcyBvdmVyDQo+IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gM0FfX3d3dy50 aGVpcHY2Y29tcGFueS5jb20mZD1Ed0lGYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRDQo+ICZy PVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1yekFjS1BoVHFY eEcNCj4gVlFkLQ0KPiAzRG9abE11dGVqUTVDV29JbUpOdUN1YjdqMHMmcz1ZMVVKd1RWSlY4TWlB Nk83VG5rSV83VEpKOVNaSlg2aVgNCj4gR0NHOGZrQUdfMCZlPQ0KPiBUaGUgSVB2NiBDb21wYW55 DQo+IA0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGlj aCBtYXkgYmUgcHJpdmlsZWdlZCBvcg0KPiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBp cyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1 YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBk aXNjbG9zdXJlLA0KPiBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50 cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmDQo+IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0 dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVy ZWQgYQ0KPiBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IGJlIGF3YXJlIHRoYXQgYW55DQo+IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1 dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sDQo+IGV2ZW4g aWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQsIHdpbGwgYmUNCj4gY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBt dXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8NCj4gaW5mb3JtIGFib3V0IHRoaXMg Y29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiANCj4gDQoNCg== From nobody Wed Jul 3 10:37:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2011204D5 for ; Wed, 3 Jul 2019 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 zkAQY7TJ0fCL for ; Wed, 3 Jul 2019 10:37:01 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACBC120483 for ; Wed, 3 Jul 2019 10:37:01 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id w79so2753855oif.10 for ; Wed, 03 Jul 2019 10:37:01 -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=+MqqyMaEQb9OasL8JyIorNn+f15JbuKKK/7upFO8Edg=; b=ocG+n838vNkgOinlS8MaGtSYsiAxl/ttStVhgcN+iTM0LZd8jx1G6J1jGUmN4Bc6vA Q8H1xluHTFxA9EaUziNKRjJ5+tBjOgoqACzlOWx/MKK9wVqJO6GszDzxuSOrC/lRAWjN DBmzrhBgHOSyeCwXSEGgPhT/H8qFCVgoFIwLgk1g+Yl2wvJzOfB1PQex0VzSdEk0BQv8 I7xtOBHJIEfcaePGy/vbzghmt25r89N6RR5RSrGYr2EztORNz/V4rgS/2GHj3N9q1JkA iOX8hdPMuYwM0TAQmU1sMDJP6+34d3tfz74NXMxr051ZGU6W6y+pDd5g6e410SYtLs7m UhfA== 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=+MqqyMaEQb9OasL8JyIorNn+f15JbuKKK/7upFO8Edg=; b=c1HAHtxgKGIWK6E4G7YyWLRvUgMc2T8O2YGimw7Cr+T2b7AzgRfslNbMcX1adJMNWE Iaq4qZ6kJpoCD76qaMGtALth4Lsyn/kcX8vJbf9nonl9mH+DNcPhVaf/1l04v49xN+Il Ta3fSZA7/2nDZgCGuD7OgVg1fnVsfj22LOarHprk4F3USYQkw2wWvEae5NddpSAuFAt7 VKesilET1SIgC7sbQCfX3d0tEbdIh0RwZhq2HEi/HYv42YiIIItWEAzm1jhCt+2xMVLl 7/lcUjnwt37jr+gUfcW+Ji4iaLcxx+ti4YaFPgZE32yQtKxXZZcbeYw3Sw2DLigUYcdC afmQ== X-Gm-Message-State: APjAAAXEW+U7JqT6vCWEm3t7py9sjFcGjQ5RJpDG9yNUR06qqKPio+Vw 2twpXTYiy+obFFdl8WvYYuA= X-Google-Smtp-Source: APXvYqxhQERCgbTJTbMMPMEfEd8XYET7NVDKZkGO9j2lbhYhw5jnmP4a6I2vX39Mc5Wc46Hf5ZnEIw== X-Received: by 2002:aca:bc02:: with SMTP id m2mr8147811oif.139.1562175420489; Wed, 03 Jul 2019 10:37:00 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1006? ([2600:8802:5903:df16::1006]) by smtp.gmail.com with ESMTPSA id l12sm956891otp.74.2019.07.03.10.36.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 10:36:59 -0700 (PDT) From: Fred Baker Message-Id: <48DE276D-F3E6-4A42-B4E5-8CFE7ACEB491@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9319A4FE-322A-479D-8A27-CBCF200188E6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 3 Jul 2019 10:36:55 -0700 In-Reply-To: Cc: Jen Linkova , V6 Ops List To: Lorenzo Colitti References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 17:37:09 -0000 --Apple-Mail=_9319A4FE-322A-479D-8A27-CBCF200188E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2019, at 5:43 AM, Lorenzo Colitti wrote: > I would definitely like to see this issue discussed in Montreal. I have added it to the v6ops agenda: = https://datatracker.ietf.org/meeting/105/materials/agenda-105-v6ops-03.htm= l = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_9319A4FE-322A-479D-8A27-CBCF200188E6 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+AFAl0c57cACgkQEhdRnd2G P+A8GxAAsvZSvINDWD380VVfEIlsRVd3mWQ4k71v5ArUDW0ejoIsQgvBilTkDU22 WfNOY/Fo/vYtynmqKe1V+WnGT7y9t6YwLJYoKrK3XlqBknTTeyyS7ol5YGeWK5Eh zIeLP4/dmrfF5ydUo+WU/YWTz4LbP3KO4/wtYJjn9dI9Fku1/ornLPgxS5uMi0Cx ibBO01IJEEYazNNqe3NXB+VaLvzzWncTSK81m6xCpWW7GmL7WB6Ygdw3YekXqYF2 s3tsxBHoJkKYghZbzutT+92GG1JNyg26URgY1rOEOWslqCtqSojsjeDXt0Qj4hj2 N17Tdyjcr1dLw51jyjXnUsa/bfQ2j603DJ9e/tNyIs9nunnluK17w38gcnQCF5GT 4yzMKL/Op2+hkRvgvcc0DetpjbTikAm9AKWxOBHUjfeiwPBHtm8ks6tWw3IXxt03 e0KKgg9oZ6otAJCIu3YAhAzIdiXDwFRhr68uXxyJoD9ITt1HP/Mg0ASwaHtTzUxs 1dIdKqayM/cvmDG+gYA7CkNXvKvwjX3dQmUKCQDk5gVglLqNlM5IrzsaNA2hoJSQ GSHP+qGAVA8KYTxM45RWpmpM3NzV2sc7G22LF/3KgaZeivUVp6YUziNs174xWPVR 24a3v+TINRBrUuNFcW9GmwwgxNmVfGisYcoNnsZ1VpdzcbIS5fU= =STtb -----END PGP SIGNATURE----- --Apple-Mail=_9319A4FE-322A-479D-8A27-CBCF200188E6-- From nobody Wed Jul 3 11:29:58 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F0F1200D7; Wed, 3 Jul 2019 11:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 k3u8udofIb1Q; Wed, 3 Jul 2019 11:29:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C9B120332; Wed, 3 Jul 2019 11:29:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A7DE338192; Wed, 3 Jul 2019 14:27:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56506BB7; Wed, 3 Jul 2019 14:29:52 -0400 (EDT) From: Michael Richardson To: Jen Linkova , V6 Ops List , 6man <6man@ietf.org> In-Reply-To: References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 18:29:56 -0000 --=-=-= Content-Type: text/plain Jen Linkova wrote: >> My big question at this point is whether (following Michael's lead) it >> belongs in v6ops, 6man, or 6lo. > Well...IMHO it's in the grey area between v6ops and 6man. It's an > operational issue. Caused by ND state machine design (I'm really not a > fun of a situation when legitimate packets are dropped by design). The > solution might be in v6ops or in 6man - we can either say 'oh, just > let hosts ping the routers or tweak their probing logic' or we might > look at ND state machine to see if anything could be done there. It's not an IoT issue, it's just that constrained 6LRs have significantly (orders of magnitude) fewer NC entries than typical routers, so we have greater concerns. If we can fix the ND state machine in some way, it would likely help. >> Operationally, do you see it in non-IOT-attacks? > I have no experience and very, very limited knowledge of IOT area. I > do see it as an operational issue on IPv6-only WiFi. > I'd have never expected it but users do notice when it takes 5-10 > seconds for their phones to start using WiFi. I'd be happy to consider > it a cosmetic issue ("everything will start working, just be patient" > but by number of complains it competes with 'Spotify client is broken' > one... > So I believe we shall at least try. So, you didn't answer the question ;-) Are we seeing neigh-cache exhaustion attacks on IPv6 capable WIFI today? 5-10 seconds seems really high... it is really explained by just the pathology you described? Is it because the probes are not retried soon enough after the first set failed? Or is it because there are NC exhaustion? In the IoT context, a sleepy device that wakes up and wants to do an exchange out to the Internet, would benefit from anything that puts the neigh cache entries in place faster. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0c9CAACgkQgItw+93Q 3WVcqAf/XEQOK/hfowg5NsLft6D2d0WzxLjI0GlBS8PJerh2IlTWABqa+SUbvNpA B2Rjo7UFj+CRBL8QTO8lGanweGrsdMujdvfw2aLJnY+soJir4TQlWjiPcqHp+eaQ F3QQKLU5l9tMp/U+Kv2bCZzsXB9h/9VndwS2p85NhTKe9pTFpsRrENZeaW3fHSd+ MTu8DIabMXRhlOPooIgQ1jXcG+6sKcvjEwqvtaawT71hlpiXESx7GD022fgX2xqC K++ncW7mkHbmbliAIcjYgNN2IRxGVcaTkGGy4C7jHe4g3ShMWVyivfSI9BwY+sP7 yj547yvtXkA60Amqb11KCffZEdlPFg== =PMtC -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 3 11:59:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF71205F0; Wed, 3 Jul 2019 11:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 8CrB_0LKvudU; Wed, 3 Jul 2019 11:59:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F261312047B; Wed, 3 Jul 2019 11:59:20 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 1757838192; Wed, 3 Jul 2019 14:57:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BF4C6BB7; Wed, 3 Jul 2019 14:59:18 -0400 (EDT) From: Michael Richardson To: Jen Linkova , 6lo@ietf.org, 6tisch@ietf.org, V6 Ops List , 6man <6man@ietf.org> In-Reply-To: References: <5377.1562081856@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 18:59:31 -0000 --=-=-= Content-Type: text/plain Jen Linkova wrote: >> I didn't really understand 2.2.2: is it exploiting some corner case in the >> spec, or maybe just some part I am not well clued in about. So maybe an >> extra paragraph to explain things. > It's just using the standard ND process: when the node B receives an > NS from node A and that NS contains the node B address as a target > address and SLLAO contains node A LLA, > the node B would respond with NA and would create a STALE entry for > the node A - https://tools.ietf.org/html/rfc4861#section-7.2.3 I read through https://tools.ietf.org/html/rfc4861#section-7.3.3 and it says: The first time a node sends a packet to a neighbor whose entry is STALE, the sender changes the state to DELAY and sets a timer to expire in DELAY_FIRST_PROBE_TIME seconds. If the entry is still in the DELAY state when the timer expires, the entry's state changes to PROBE. If reachability confirmation is received, the entry's state changes to REACHABLE. Upon entering the PROBE state, a node sends a unicast Neighbor Solicitation message to the neighbor using the cached link-layer address. While in the PROBE state, a node retransmits Neighbor Solicitation messages every RetransTimer milliseconds until reachability confirmation is obtained. Probes are retransmitted even if no additional packets are sent to the neighbor. If no response is received after waiting RetransTimer milliseconds after sending the MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry SHOULD be deleted. Subsequent traffic to that neighbor will recreate the entry and perform address resolution again. Is PROBE and DELAY different states? It almost feels like a typo here. >> I kinda like the ping all routers trick. > I think it's a hack ;( we do have a mechanism for communicating > neighbours addresses/reachability called ND. It would be nice to > utilise its machinery. > Pinging creates additional overhead on routers and could get filtered. > But I'd not be surprised if it's the only way we have realistically to > mitigate the issue.. Yes, it's a hack. It leverages existing behaviour, can be deployed unilaterally by mobile phone makers, and does not require any new state in the end device, as they don't even have to listen for the ECHO REPLY. Let me suggest a different hack: use stateful DHCPv6. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0c+wYACgkQgItw+93Q 3WWGTQf/QBESd48itHFqKe4qg7e07NgtLzjD6sMpxF4Akge/7WklC8P7S/K1MaiI E/m8d4YdqlyilBRjKaPzHGNPdK7rppeiKbUidjUPsC9+tYj9BhPRhP34Us5SVA8s sdnDULlPKWQpHcQ11g6at/2sf6Gsr/cDaP0wcdE/Su+b60WE6Pc4vgSOPP7Oa3DR AudNzyqJO1P1/Zf53NlJSpGZbcu7Ny8bjm7CMgEUqm/m31XytqV6/LKx3dvzlNHf 6RULv+0AhA+W6TNhKJJxPk5F84eUnr8EK06rQvPV7CmA5V6iXAs7A8g25qjmNeYl 1h9MtxDhsXuzRry9qcbu9vi6lp+jSg== =sbJ5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 3 12:02:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5407D120654; Wed, 3 Jul 2019 12:02:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 cD0uoFPLW5nq; Wed, 3 Jul 2019 12:02:00 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 DF8E7120670; Wed, 3 Jul 2019 12:01:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2E0AACo+hxd/yYyC4dlHQEBBQEHBQGBU?= =?us-ascii?q?wgBCwGBQ1CBYgQzCodZA4RSX4kVgluJTY15gS6BJAMYPAkBAQENAS0CAQEChDo?= =?us-ascii?q?CAgKCRjQJDgEDAQEBBAEBAQEEAQICaYo3DINFOTIBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEFAjg4AQECAgESKAYBATgEDQEIFQMeMREmAQQ?= =?us-ascii?q?BEggahGsDDg8BAgKaIAKBCDCIXwEBgiIagl8BAQWFDg0LghIJCQGBKgGLdYFBP?= =?us-ascii?q?oERRoJMPoIagioCgzqCJql/QAkCghaQDIQOgiuHHIN5A4oujTCJL44EAgICAgQ?= =?us-ascii?q?FAg4BAQWBUDmBWHAVO4JsgkGDcYpTcoEpi1QBgSABAQ?= X-IPAS-Result: =?us-ascii?q?A2E0AACo+hxd/yYyC4dlHQEBBQEHBQGBUwgBCwGBQ1CBYgQ?= =?us-ascii?q?zCodZA4RSX4kVgluJTY15gS6BJAMYPAkBAQENAS0CAQEChDoCAgKCRjQJDgEDA?= =?us-ascii?q?QEBBAEBAQEEAQICaYo3DINFOTIBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEFAjg4AQECAgESKAYBATgEDQEIFQMeMREmAQQBEggahGsDDg8BA?= =?us-ascii?q?gKaIAKBCDCIXwEBgiIagl8BAQWFDg0LghIJCQGBKgGLdYFBPoERRoJMPoIagio?= =?us-ascii?q?CgzqCJql/QAkCghaQDIQOgiuHHIN5A4oujTCJL44EAgICAgQFAg4BAQWBUDmBW?= =?us-ascii?q?HAVO4JsgkGDcYpTcoEpi1QBgSABAQ?= Received: from mailauth.avaya.com (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Jul 2019 15:01:55 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2019 15:01:55 -0400 Received: from PWEXCVMAP01.global.avaya.com (135.11.85.80) by AZ-US1EXHC03.global.avaya.com (135.11.85.14) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 3 Jul 2019 15:01:55 -0400 Received: from PWEXCVMAP02.global.avaya.com (135.11.85.81) by PWEXCVMAP01.global.avaya.com (135.11.85.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Wed, 3 Jul 2019 15:01:55 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by PWEXCVMAP02.global.avaya.com (135.11.85.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1531.3 via Frontend Transport; Wed, 3 Jul 2019 15:01:55 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.55) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Wed, 3 Jul 2019 14:01:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4vQi1wLCHTFRgX6X3CeuPf7QB+MiJFHmvBTq1YIhZQ0=; b=nPHiu8iESSREdZ4dCtxfKqa9Elx8pWEjsiRmNCA8gBRZoMnLDj3xkQlpg91G8qa0ukjL/yMcY3jkV0mXl53bLTW0X97UOpeSHW29yyPec9vrtYm2+3B+4/4A2qhaL8ASMQt3PD35itq1scoltVhW7lWK1SPLjPFndbr7b2IKhK0= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2572.namprd15.prod.outlook.com (20.179.160.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.15; Wed, 3 Jul 2019 19:01:51 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::697d:5307:1f7a:79bc]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::697d:5307:1f7a:79bc%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 19:01:51 +0000 From: "Mudric, Dusan (Dusan)" To: 6man <6man@ietf.org>, IPv6 Operations Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AdUx0cT0aqZJH36KQ+aPddD1wR/aYA== Date: Wed, 3 Jul 2019 19:01:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c020a28b-3da8-42aa-498d-08d6ffe8e84f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2572; x-ms-traffictypediagnostic: DM6PR15MB2572: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(39860400002)(346002)(396003)(189003)(199004)(478600001)(26005)(68736007)(3846002)(6116002)(52536014)(66476007)(186003)(73956011)(76116006)(99286004)(66946007)(450100002)(256004)(86362001)(8936002)(81156014)(81166006)(8676002)(102836004)(55236004)(66446008)(25786009)(66556008)(6506007)(53546011)(7696005)(64756008)(5660300002)(14454004)(74316002)(55016002)(110136005)(71190400001)(71200400001)(6246003)(66066001)(2906002)(53936002)(316002)(33656002)(6436002)(9686003)(486006)(476003)(7736002)(305945005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2572; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TCMjGpZgTEDkaYvbL344+cO7ebEb8cJGCFyL/HQlU5n5hO5LoU7T39INFwuQK2NSo+UJp6W6WClP5Eskm7/ARqCxVtX+onVGTsPl6ojVkQFheOQruEKrxCIv2qOfH0pLj2x3+oiwNqkcWEw8exKJEzE931GPrU1zLDTAqsJgFtG3FcCYnEwxkQHp3cCEVT0veJfCZ2KlaPYFYabXzbt3zTaQq9dnQQMN/yraXAKhB9m3vtChi69tTq8CB7C1VWOd5HV/oNtetG7i4xaE+7ekcyjVL58RT/Y3CIRaEkfCvRRWa60zVB6nWQiAwygz9AbMikqfydyut3a0p30d5oEKy55gzLUHc3kkcwLyOHzW3cTzpYxDG9/LN+0O52hJgpQ6c21ocXGuYAZMbFc9ITEPQmegsAfsmzBcu6yePRoR3D0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c020a28b-3da8-42aa-498d-08d6ffe8e84f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 19:01:51.3610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2572 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 19:02:10 -0000 >=20 > On Tue, Jul 2, 2019 at 9:49 AM Jen Linkova wrote: >=20 > > I've been told that an IPv6-only > > host might want to exclude some addresses from synthesis and use IPv4 > > to reach them, so I'm trying to understand how *an IPv6-only* host > > (which, IMHO, can only use IPv6) reach anything using IPv4. > > >=20 > Right. That was the gist of my earlier comment. I believe we all agree th= at > in the most common deployment scenario (i.e., an IPv6-only host with no > IPv4), an exclusion list is not useful, because the host really can't rea= ch > anything that's not reachable via IPv6. >=20 > From: v6ops On Behalf Of JORDI PALET > MARTINEZ > And, oh yes, someone using IPv4 (or X.25, or SNA) could go through a > translator and communicate with an IPv6-only host in such a domain. It's > IPv6-only up to that translator. [Dusan] Please clarify how IPv4-only host can reach IPv6 only host, and vic= e versa. Also, how IPv6 only host can know IPv4 address of IPv4 only host, = assuming IPv4 only host is in a public domain? From nobody Wed Jul 3 12:12:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD39812038D; Wed, 3 Jul 2019 12:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 sd_ykjA_OyXn; Wed, 3 Jul 2019 12:11:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18321200F3; Wed, 3 Jul 2019 12:11:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A7E8438192; Wed, 3 Jul 2019 15:09:37 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 62CE4B93; Wed, 3 Jul 2019 15:11:31 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" cc: "6lo\@ietf.org" <6lo@ietf.org>, Jen Linkova , "6tisch\@ietf.org" <6tisch@ietf.org>, V6 Ops List , 6man <6man@ietf.org> In-Reply-To: References: <5377.1562081856@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 19:11:36 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > 6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the > ones coming from the outside of the subnet, i.e., from a place that is > out of touch and virtually nowhere. > This is because in an RFC 6775/8505-only network, there is no reactive > operation, a packet coming from the outside of the subnet for a node > that is not registered to the router is just dropped. Just like an AP > does not copy a packet on the wireless for a MAC that is not > associated. There are a few attacks on the ND cache that I can think of. One of them that we see on the IETF network is the script kiddies who sequentially scan IP addresses. We have a lot of them, and so we flood the wifi with ARP queries (v4) and NS (v6). We have mitigations for this. In the route-over 6tisch/RPL space, we don't (as you indicate), use NS by the router, we know who is on our network, and we would just have no /128 routes, and just drop the packets. Is this the attack that you are speak of as a remote DOS? > Your point below remains correct, since the attack you describe is from > a node that reaches the router at L2. Arguably, that attack is > physically much harder to perform than the DOS packet from outer > space. When I mentioned attacks on the ND cache, I am referring to those that can occur from within the 6tisch network from malicious pledge nodes. We have to limit the NCE usage by untrusted nodes so that we have space for as many registered nodes. I think you are agreeing with me above. I believe that the issue that Jen is describing would for unaware leaves that were sleepy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0c/eMACgkQgItw+93Q 3WUEOAgAjmTAnmn+jEHZTwqrre02RuT7NICdkvcFFFzqttjRh/tK4h/Z2LgM5Wyv y7JWGouXIPnT7984uWHKQlNlqFkZ1cnZ36l0FIrOZRL36DbolxrIkAStUFkiTLq7 oAxs2DKIqFstJNIL3Y6fFdyr1U29d22Ly3OgPBK4V7vrUebZGo8A+gfGszdhZrKq 4VFpYyHsAT+x7QG6+gVwuSRmkg5ENSpVdAM+N/Sc3mS2fdf/0AnitnYzYLjqvOgy XFv0gfzFVt7fhjWa7z/DQ16OYW0ACc11EuuhcHbiIEQmFRJgp9SbWPpqdbe9k0Mf whxUh0/zIw0HJNLYUr2r0IVoFx3deQ== =0KRM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 3 12:32:27 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D579A1203F6; Wed, 3 Jul 2019 12:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 GNrIZHMVMFOA; Wed, 3 Jul 2019 12:32:16 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 9650E12016E; Wed, 3 Jul 2019 12:32:16 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id z23so3547336ote.13; Wed, 03 Jul 2019 12:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Q9kwFBgNBkS5yOd2f9M8yVd2uEf72PFor1cKIb72w8=; b=HmUngBuhkjyrokd/FjlFXDRTMTONOttCr0y8zdSnNo8dlsop1dZVVIMGSEbEFKXL2B sVjj6omVnCjXFL70j4p/pJsIiOQKscqyzDuHFRcHijug7wnzs8Fze7vBxk5BAXQnNeGk UG35w6PvFERK+Z0Elf1AMuuUQv4jxvOBpbTRuztq07//n1WKRdkracOb0nAiUdMPHwoB lzGVHbVHjbObLcvQVfoC2hu3WnwLII56IJtso4+1VQGE8hSlYSHKbvafHM2SUgzNUV44 xG/2DQbCFdODCkb5Unfzqz2zSz/ZktU9ouNM0YAOYeomkNvx8LjtSBXvRbtXgdS24bJi 1YtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Q9kwFBgNBkS5yOd2f9M8yVd2uEf72PFor1cKIb72w8=; b=mpttBQ27jTwfwQlkl2SHd+nfP4YQT5Kt0IYUYhHsxLiMgA1Q0WvthHJhlNRF2fCMlg 8yjtDBZWNh0ho7qyXWVYoWL/xXWAg91KSnM+zOkbIH5UgfRvsRySstL6MxUapswu9gsm SJymywlvHs00vnVgfNtIt8394lP8IFwiCIMkhTvs0bQG8CDJtVF6eK8q8HKkCe1MgAg7 /mHcB4L7lEUaJ+L3MBxcoCo+45MnNGNgtrBdCuhH1nHJ7x82habEwhoL1MCroMaHwZPj Aw1DjXPDdEIvbfDI/cDUvmNSCeF82LBZvvB1TxRyhRfYEdJr3nBTJWDJP1d/8rabAjhX YwTg== X-Gm-Message-State: APjAAAUw5ayiXnisujKaG9RMAprAQy6zS9FbqxqPg6HtHIM9KhrosAcG wzV0dzzargZ53tJcImup2cE17xVG X-Google-Smtp-Source: APXvYqzfqEB9Ig59zx5Cm0o3xrDUN0ismkgPCuhA8euUi7OiI2JssAcrp8p2QFLEBANyviHW6C0iow== X-Received: by 2002:a9d:d87:: with SMTP id 7mr29375988ots.263.1562182336026; Wed, 03 Jul 2019 12:32:16 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1006? ([2600:8802:5903:df16::1006]) by smtp.gmail.com with ESMTPSA id j8sm1051202otl.9.2019.07.03.12.32.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 12:32:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3560.7\)) From: Fred Baker In-Reply-To: Date: Wed, 3 Jul 2019 12:32:14 -0700 Cc: 6man <6man@ietf.org>, IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> References: To: "Mudric, Dusan (Dusan)" X-Mailer: Apple Mail (2.3560.7) Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 19:32:18 -0000 > On Jul 3, 2019, at 12:01 PM, Mudric, Dusan (Dusan) = wrote: >=20 > [Dusan] Please clarify how IPv4-only host can reach IPv6 only host, = and vice versa. Also, how IPv6 only host can know IPv4 address of IPv4 = only host, assuming IPv4 only host is in a public domain? Simple. Using a Translator, either at layer 3 or above it. Any other way = doesn't work. = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... From nobody Wed Jul 3 13:39:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001FF120695; Wed, 3 Jul 2019 13:38:45 -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_HELO_NONE=0.001, 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 kSv3syNN5Rcb; Wed, 3 Jul 2019 13:38:44 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 53D9A120662; Wed, 3 Jul 2019 13:38:42 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id o13so1777634pgp.12; Wed, 03 Jul 2019 13:38:42 -0700 (PDT) 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=fZWjYspQX44xnXTEIYKrD0yhxlZb/34/gZGPoI+SzIk=; b=V+T3oAXcRVLd6KKACu83Gl+9i1dZ32yghX2krt60HsVlt2RFJ+bAZDZctW1pj0mO/X JQ3xunU/GaxGbRqEFlEg5VN/yNS+7uZmkZGsrNkN/WYt7+t8eowYh76T2xp8YUDR3S4+ ffrQlTwZK8r4+MO6CB9UpG4F0ETwTloEC8/Pib28zB0PhN7rl4IehnajIkbGl+RC4slI b5nNvxn45M7dmV/BRxXQFlCg+f8ySMyDc0qkyhogJixQ5pT8yHlQ6vumBQaJ86TEZg7J TbQMu99OqXyqktRdRiyFyPut5cwTkRD5W90TfBcxHeL5aKuoemAazklOXAz0IZXY5c5P STQA== 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=fZWjYspQX44xnXTEIYKrD0yhxlZb/34/gZGPoI+SzIk=; b=ZYm9j2OVRz3MhakCsGpypfBhCateF+sA3BKDKlHZwGIRgkFg3ZbuR9x9PW1A2XOEsS pzZJIc7+Kzc/f5/Uq8SVNW3kM2x7Af+GC4QVnH4gAb0rXgL9Fnpt6jRZR5m6CZpUHG16 YwA7DoS9YhCYJCBeANu2oJhpU4UjpzEvo6N9RUH8NbWm8dcpX19KDZOc7rapYqSM8KUB gtwaStDRzo9ZnYrbNw4p9mx1wO2+lFnHMRZWsYkvTEIg2W7I1d0W8ruqjQul/q0mCqDm bHHCIO+70OKJqhMT2YzS1aEW9nmL9tikOaYAjDs+ZqTmpbL2SQNtPVYKxhdR4vIPCPmT rwYQ== X-Gm-Message-State: APjAAAWgYmejJldTDt6T6+dzViZRjA2R3aqzYKrTsfJHgXNQbxuhSP2t sRUHeAm7jUo8rdUt1QESKBxvTnEj X-Google-Smtp-Source: APXvYqwbfby7MsS1Ty0YZt21o7OY5qFgE9lV1qWpy1J1XYah0XEQDDabj0bxBCzT2iSdq78gAOmyEQ== X-Received: by 2002:a63:205f:: with SMTP id r31mr30679080pgm.159.1562186321322; Wed, 03 Jul 2019 13:38:41 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id 85sm3196094pfv.130.2019.07.03.13.38.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 13:38:40 -0700 (PDT) To: "Pascal Thubert (pthubert)" , Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, Jen Linkova , "6tisch@ietf.org" <6tisch@ietf.org> Cc: V6 Ops List , 6man <6man@ietf.org> References: <5377.1562081856@localhost> From: Brian E Carpenter Message-ID: <0e80ea5d-d659-2d3e-43ac-674531f171eb@gmail.com> Date: Thu, 4 Jul 2019 08:38:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 20:38:51 -0000 On 03-Jul-19 20:13, Pascal Thubert (pthubert) wrote: ... > I'm baffled that the reactive ND is still the official technique for IPv6 lookup at 6MAN. How can it be otherwise when a node can give itself a new address at any time without notice? I'm not arguing with you about RFC 6775/8505 networks, but that doesn't apply everywhere. Brian From nobody Wed Jul 3 13:46:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1673B120168; Wed, 3 Jul 2019 13:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 z_bywmBuJVx9; Wed, 3 Jul 2019 13:46:11 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 E648812069B; Wed, 3 Jul 2019 13:46:10 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id s27so1810760pgl.2; Wed, 03 Jul 2019 13:46:10 -0700 (PDT) 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=VdiQtjYEjc+ZRJt8ZRXYr0AEHGNTWkwyCYvuCOc4qDU=; b=RqwC6mrTCWihIPCo6aKA1NtcKqcK7JcvgCwGepF5rmwElNosurXGmoPEqlWZEnMrFW cyNwY1oOXDqxxd5/6OKyWMNOJXzk385EZlqIPPmV77aCn7xRc6ZuZqjXvCyi3C7CEs7Z K5+xz92U4Nq/iqMqdQxGeBwj56/plak4kBdpuNe9h6Bkl7FE9RfV5pnllhdManthoTez frnq8g1BJCAIbLoa0MYz1HUv9PMhVy6b6OcCIk3MCkb8FObzZAvm0eFSgTYJK8T8nLB9 lI4hkNvZGwsGf1l2cPW1jT6SndumViAYy5Pr9x9t1ScFH9e9cvX3nXoG8Vd44kWbCBPY qQkA== 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=VdiQtjYEjc+ZRJt8ZRXYr0AEHGNTWkwyCYvuCOc4qDU=; b=MrJy4MxBPYqyO/NWdOp24d0G3LPiyq3ZiS6tfCkF46BD8kY9f2KhmoOW4swrKlbsPw KCM1FcTTK+GB3dDECFk0FmTHT6KBoEXi0iTynSVULNE9mgDDS20SfpDNni2A7nhXNrdH j7ZK3GpAbrWqzizG7vJCFZFkIUjGNMTsVTmVAUr719b6c2PvdgUIrOaq7KmQPg4ycLH+ tLxWaAxV3eS2G4PV0q8G5opMId2cx1s4h5lkSJcw9zLoG0SEU79bJJ0f8e6Rr9s0ZxiL YmeqGtkiN+lkxDNOR+4tBReg7ZARIFem4m6HlV/XR4ht+au0LfbY/4Pem/+EV5ThhCd/ iRJA== X-Gm-Message-State: APjAAAVPmtWmXpCgU2nuuSG7VIJOHl0bP2lPxMMWj5yTMmhLjrJrsb+D L5/Zz2ou+Od+VFlIV7ItAk9WvM0f X-Google-Smtp-Source: APXvYqwgonWNdLYrIeMOwwKeteDfs/f/MUTi5jGlWdlsOf02seNv3XxGwlFImSnYWI61nTPAI9eEiQ== X-Received: by 2002:a63:d512:: with SMTP id c18mr40566856pgg.239.1562186769932; Wed, 03 Jul 2019 13:46:09 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id 30sm5155747pjk.17.2019.07.03.13.46.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 13:46:09 -0700 (PDT) To: JORDI PALET MARTINEZ , "Mudric, Dusan (Dusan)" , Lea Roberts , JORDI PALET MARTINEZ Cc: "draft-palet-v6ops-rfc6177-bis@ietf.org" , IPv6 Operations References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <0601C33E-0BB0-4C42-BCD2-B86FD90BBA6A@consulintel.es> From: Brian E Carpenter Message-ID: Date: Thu, 4 Jul 2019 08:46:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <0601C33E-0BB0-4C42-BCD2-B86FD90BBA6A@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 20:46:15 -0000 I don't recall saying that, to be honest. Regards Brian Carpenter On 03-Jul-19 23:03, JORDI PALET MARTINEZ wrote: > Hi all, >=20 > I've been too busy to tackle a new version of this document, but now wo= rking on it. >=20 > My recall on this, please correct me if I'm wrong (Brian, Mudric), is t= hat you believe that: >=20 > 1) We should define end-site in the document? >=20 > 2) End-sites must be able to request a longer prefix if needed and the = ISP must grant it? >=20 > Anything I may be missing? >=20 > Regards, > Jordi > @jordipalet > =20 > =20 >=20 > =EF=BB=BFEl 28/8/18 6:27, "v6ops en nombre de Brian E Carpenter" escribi=C3=B3= : >=20 > On 2018-08-28 06:23, Mudric, Dusan (Dusan) wrote: > > Section 4. > > " b. An end-user should be able to receive any prefix length u= p to /48 > > simply by asking." > >=20 > > Can this be defined in a way to make sure that new applications = and devices will always work at end sites without a need for asking ISPs = for extra address space? Otherwise, the end-user might not get what he/sh= e asks for, without paying for the "higher grade" service. Can the defini= tion impose up to /48 LAP when needed at end sites? For example, can an a= pplication request a home router to request an ISP for /48 prefix and, wh= en requested, ISP must grant it? > =20 > Unfortunately we can never say "must" in this context. What ISPs wi= ll provide > for what fee is well outside the IETF's competence. As observed on = another > thread, applications need to be agile, even if they work better if = such a > request was granted. > =20 > I'd say that once this update is done, it may be time to revisit > RFC4084. > =20 > Regards > Brian > =20 > >=20 > > Regards, > > Dusan Mudric. > >=20 > >> -----Original Message----- > >> From: v6ops On Behalf Of Lea Roberts > >> Sent: Thursday, July 19, 2018 2:08 PM > >> To: Brian E Carpenter ; JORDI PALET= > >> MARTINEZ > >> Cc: draft-palet-v6ops-rfc6177-bis@ietf.org; IPv6 Operations > >> > >> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-0= 0.txt > >> > >> hi Brian and Jordi - > >> > >> excellent comments and I agree also. > >> > >> thank you!! > >> /Lea > >> > >> On Thu, 19 Jul 2018, JORDI PALET MARTINEZ wrote: > >> > >>> Hi Brian, > >>> > >>> > >>> > >>> Thanks a lot for commenting and sorry the late answer ... too b= usy last > >> weeks. > >>> > >>> > >>> > >>> Comments in-line below (subjected to my co-author agreement), b= asically, > >> agree with all your inputs, except a couple of points. > >>> > >>> > >>> > >>> Thanks! > >>> > >>> > >>> > >>> Regards, > >>> > >>> Jordi > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> =EF=BB=BF-----Mensaje original----- > >>> > >>> De: v6ops en nombre de Brian E Carpent= er > >> > >>> > >>> Organizaci?n: University of Auckland > >>> > >>> Fecha: domingo, 8 de julio de 2018, 17:43 > >>> > >>> Para: , IPv6 Operations= > >> > >>> > >>> Asunto: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-0= 0.txt > >>> > >>> > >>> > >>> Hi, > >>> > >>> > >>> > >>> Thanks for this draft. > >>> > >>> > >>> > >>> > Abstract > >>> > >>> > >>> > >>> This needs to be shorter. Three paragraphs is too much. > >>> > >>> > >>> > >>> For the next version, I've reduced 50% the length of the 1st pa= ragraph. 3rd > >> paragraph, I recall is mandatory (IDNits). > >>> > >>> > >>> > >>> > >>> > >>> > ... policy should reflect that assignment of a single subn= et is > >>> > >>> > no longer appropriate unless the recipient explicitly agre= es to the > >>> > >>> > limitations implied by such an assignment. > >>> > >>> > >>> > >>> I *strongly* suggest deleting the "unless" clause. It leaves= a > >>> > >>> loophole, and it could easily be hidden in shrink-wrap terms= > >>> > >>> and conditions so that a subscriber would agree without even= > >>> > >>> knowing about it. Reduce this simply to: > >>> > >>> > >>> > >>> ... policy should reflect that assignment of a single sub= net is > >>> > >>> never appropriate. > >>> > >>> > >>> > >>> Agreed and done. > >>> > >>> > >>> > >>> > >>> > >>> > 1. Introduction > >>> > >>> .... > >>> > >>> > 1. It is extremely discouraged that /128s be given out= =2E While there > >>> > >>> > may be some cases where assigning only a single add= ress may be > >>> > >>> > justified, a site, by definition, implies multiple = subnets and > >>> > >>> > multiple devices. > >>> > >>> > >>> > >>> I find this a bit weak. Try: > >>> > >>> > >>> > >>> 1. It is extremely discouraged that /128s be given out. = While there > >>> > >>> may be some applications where assigning only a singl= e address may > >> be > >>> > >>> tolerated, a site, by definition, implies multiple su= bnets and > >>> > >>> multiple devices. Also, a /128 prevents any form of p= rivacy-based > >>> > >>> addressing. > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> > 4. This revision has been created to more clearly asse= rt the > >>> > >>> > requirement to ensure that address assignments to e= nd-sites > >>> > >>> > provide a sufficiently big number of subnets (/64 o= n classic > >>> > >>> > networks) to each end-site, taking under considerat= ion the end- > >>> > >>> > site's future expected needs, new deployment expect= ations and > >> new > >>> > >>> > protocol requirements, among others. Once all thes= e are > >>> > >>> > considered, it seems unlikely that a single subnet = (/64) or even > >>> > >>> > a small number of them should be assigned, unless v= ery clearly > >>> > >>> > justified and agreed to by the end-site. > >>> > >>> > >>> > >>> The "unless" clause is dangerous because of shrink-wrap term= s and > >>> > >>> conditions. I suggest deleting it. > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> > 2. Considerations Regarding the Prefix Length > >>> > >>> .... > >>> > >>> > This consideration should be noticed, across this docum= ent, in the > >>> > >>> > sense that end-sites usually have subnets that use, by = default, > >>> > >>> > SLAAC, and consequently, the LAP is mandatorily a /64. = Other > >>> > >>> > technologies, may have a different LAP, which must be u= sed > >>> > >>> > accordingly. > >>> > >>> > >>> > >>> I suggest s/Other/Future/ since /64 prevails everywhere toda= y. > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> > 3. On /48 Assignments to End-Sites > >>> > >>> .... > >>> > >>> > An important > >>> > >>> > goal in IPv6 is to significantly change the default and= minimal end > >>> > >>> > site assignment, from "a single address" to "multiple n= etworks" and > >>> > >>> > to ensure that end-sites can easily obtain address spac= e. > >>> > >>> > >>> > >>> I suggest adding something like this: > >>> > >>> > >>> > >>> As the operational costs of carrier-grade NAT and address+po= rt sharing > >>> > >>> have shown, availability of multiple addresses and prefixes = to end sites > >>> > >>> that need them will be a considerable saving to their ISPs. > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> > It might be tempting to give home sites a single /64, s= ince that is > >>> > >>> > already significantly more address space compared with = today's IPv4 > >>> > >>> > practice. However, this precludes the expectation that= even home > >>> > >>> > sites will grow to support multiple subnets going forwa= rd. Hence, it > >>> > >>> > >>> > >>> s/expectation/certainty/ > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> .... > >>> > >>> > A key goal of the recommendations in [RFC3177] is to > >>> > >>> > ensure that upon renumbering, one does not have to deal= with > >>> > >>> > renumbering into a smaller subnet size. > >>> > >>> > >>> > >>> Perhaps add: > >>> > >>> > >>> > >>> In particular this would apply to any site that switches to > >>> > >>> an ISP that provides a longer prefix. > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> > It should be noted that similar arguments apply to the = management of > >>> > >>> > zone files in the DNS. In particular, managing the rev= erse > >>> > >>> > (ip6.arpa) tree is simplified when all links are number= ed using the > >>> > >>> > same subnet ids > >>> > >>> > >>> > >>> s/numbered/renumbered/ > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> .... > >>> > >>> > years, and we don't recover back the /48's, we will be = able to use > >>> > >>> > IPv6 addressing space for over 100.000 years. > >>> > >>> > >>> > >>> Perhaps add: > >>> > >>> > >>> > >>> This document does not advocate careless use of address spac= e, but > >>> > >>> there is objectively no reason to be restrictve. > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> .... > >>> > >>> > Today typically, a home has already a considerable numb= er of possible > >>> > >>> > subnets (a common CE has 4 LAN ports, 2 WiFi radios whi= ch support > >>> > >>> > several SSIDs each one, VoIP subnet, IPTV subnet, addit= ional VLANs) > >>> > >>> > and if downstream routers are used, there is a need for= further > >>> > >>> > subnets. This means that in a short term, assigning a = /60 (16 > >>> > >>> > subnets), it is already a really bad decision, as it ma= y enforce IPv6 > >>> > >>> > NAT between the main CE and downstream routers. > >>> > >>> > >>> > >>> I suggest deleting "as it may enforce IPv6 NAT between the m= ain CE and > >>> > >>> downstream routers". Firstly it puts NAT into the reader's m= ind. Secondly, > >>> > >>> it isn't the only solution - IIDs shorter than 64 could also= be implemented. > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> > 4. Impact on IPv6 Standards > >>> > >>> > >>> > >>> I propose to simply delete this section. > >>> > >>> > >>> > >>> Firstly, RFC3056 is deprecated so it's irrelevant today. > >>> > >>> Secondly, the argument about ULAs (RFC4193) doesn't hold up.= > >>> > >>> ULAs are like any other /48 prefix - if you are forced to > >>> > >>> renumber into a longer prefix, you lose some subnet bits. > >>> > >>> That is already covered in the middle of section 3 (the > >>> > >>> "key goal" sentence quoted above). > >>> > >>> > >>> > >>> > >>> > >>> I recall we deprecated the 6to4 anycast, but not 6to4, in fact = 6to4 to 6to4 > >> traffic is still useful for peer to peer. > >>> > >>> > >>> > >>> > 6. Security Considerations > >>> > >>> > > >>> > >>> > This document has no known security implications. > >>> > >>> > >>> > >>> Really? More prefix space offers more potential for scanning= > >>> > >>> attacks. More prefix space also allows the use of slightly > >>> > >>> randomized prefixes and/or prefix-per host. > >>> > >>> > >>> > >>> Also of course, a /128 would prevent any form of privacy-bas= ed > >>> > >>> addressing. > >>> > >>> > >>> > >>> I've introduced new text on those points. > >>> > >>> > >>> > >>> > 8. Acknowledgements > >>> > >>> > > >>> > >>> > The authors of this document will like to acknowledge t= he authors of > >>> > >>> > previous versions (Thomas Narten and Geoff Huston) > >>> > >>> > >>> > >>> RFC3177 was signed by the whole IAB and IESG seated in 2001,= and its > >>> > >>> Acknowledgements read: > >>> > >>> > >>> > >>> >> This document originated from the IETF IPv6 directorat= e, with much > >>> > >>> >> input from the IAB and IESG. The original text formin= g the basis of > >>> > >>> >> this document was contributed by Fred Baker and Brian = Carpenter. > >>> > >>> >> Allison Mankin and Thomas Narten merged the original c= ontributions > >>> > >>> >> into a single document, and Alain Durand edited the do= cument > >> through > >>> > >>> >> its final stages. > >>> > >>> > >>> > >>> Agreed! > >>> > >>> > >>> > >>> Regards > >>> > >>> Brian > >>> > >>> > >>> > >>> _______________________________________________ > >>> > >>> v6ops mailing list > >>> > >>> v6ops@ietf.org > >>> > >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIDaQ&c=3DBFpWQw8bs= uKp > >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D-= > >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3SLM= > >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D > >>> > >>> > >>> > >>> > >>> > >>> > >>> ********************************************** > >>> IPv4 is over > >>> Are you ready for the new Internet ? > >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > >> 3A__www.consulintel.es&d=3DDwIDaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3D= UT3 > >> Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- > >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DGMRLdItF8yKbUdE9 > >> NuXE-U48uk7OHNuEijym9jhE--s&e=3D > >>> The IPv6 Company > >>> > >>> This electronic message contains information which may be privi= leged or > >> confidential. The information is intended to be for the exclusiv= e 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 prohibi= ted, will be > >> considered a criminal offense, so you must reply to the original= sender to > >> inform about this communication and delete it. > >>> > >>> > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIDaQ&c=3DBFpWQw8bs= uKp > >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D-= > >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3SLM= > >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =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= confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disc= losure, 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 recipi= ent be aware that any disclosure, copying, distribution or use of the con= tents of this information, even if partially, including attached files, i= s strictly prohibited, will be considered a criminal offense, so you must= reply to the original sender to inform about this communication and dele= te it. >=20 >=20 >=20 > . >=20 From nobody Wed Jul 3 13:50:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AAE12016C; Wed, 3 Jul 2019 13:50:30 -0700 (PDT) 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, 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 header.b=Y4Nxf5v9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eOalTAXu 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 6ZjEgUYSbCGt; Wed, 3 Jul 2019 13:50:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F42041200C7; Wed, 3 Jul 2019 13:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4992; q=dns/txt; s=iport; t=1562187028; x=1563396628; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=frPqTmC8QfsYNJ1xkVqgbVgEugV0mU3SIe8SQYmoYaI=; b=Y4Nxf5v9t8nsMzvfvaqIZPNt/ePJmH26gOcOeS6mdz9DDlUUTE4k0Ejp fwRbJEzFv/vCjgkwRDTDhYOOUfN6EKejXpQpaFj5wZGIsuRHAYh3MjzIH Bqyw+ZMn0neHtbMlitUypcTJzeXlShy/htiH9RHeT69qzUA+y2xRzyR7z 0=; IronPort-PHdr: =?us-ascii?q?9a23=3A9HW0QxD9qJ5QBVfC/Y/pUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAABIFB1d/5NdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGBQyQsA4E/IAQLKAqEEoNHA45HgjYll0aBLoE?= =?us-ascii?q?kA1QJAQEBDAEBLQIBAYFLgnUCF4ILIzUIDgEDAQEEAQECAQVtijcMhUoBAQE?= =?us-ascii?q?DARIREQwBASMUAQQLAgEIGAICJgICAjAVEAIEDgUigwCBawMODwECAZo3AoE?= =?us-ascii?q?4iGBxgTKCeQEBBYUPGIISCYEMKAGEcYQkgkkXgUA/gREnDBOCTD6EHiaDCjK?= =?us-ascii?q?CJo45L40djjoJAoIWk38bgiuHHIobhA+kYwIEAgQFAg4BAQWBUgI0gVhwFWU?= =?us-ascii?q?BgkGCQYNxilNygSmKE4EwAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.63,448,1557187200"; d="scan'208";a="368031448" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 20:50:26 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x63KoQOp025635 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 20:50:26 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 15:50:26 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 15:50:22 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 16:50:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=frPqTmC8QfsYNJ1xkVqgbVgEugV0mU3SIe8SQYmoYaI=; b=eOalTAXuaXnZ/YSkb9wkryLb803Y3zm9ePZstycCIwDd5/9wKSoSqr2j0AZ48n8+zhdPUqp4snwKxIvByAyZkNgACHdFfKIYLn6OKJAVkVbgmJXjfbZaP0NCwEObFLzuNFXSLhqqpeGarl2W+F3SkmWBq8Qc7Dn6uU+AhpwwgOM= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3646.namprd11.prod.outlook.com (20.178.253.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Wed, 3 Jul 2019 20:50:20 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 20:50:20 +0000 From: "Pascal Thubert (pthubert)" To: Michael Richardson CC: "6lo@ietf.org" <6lo@ietf.org>, Jen Linkova , "6tisch@ietf.org" <6tisch@ietf.org>, V6 Ops List , 6man <6man@ietf.org> Thread-Topic: [6lo] ND cache entries creation on first-hop routers Thread-Index: AQHVMOxYqZ+Ae5ReXkiJP5a4XqZLuaa4gaXggADCwICAABucoA== Date: Wed, 3 Jul 2019 20:50:20 +0000 Message-ID: <6E814A87-4127-4EE1-9291-A5C1041E4202@cisco.com> References: <5377.1562081856@localhost> , <16610.1562181091@localhost> In-Reply-To: <16610.1562181091@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [91.69.164.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3b3c5b75-a3a5-445b-c3a6-08d6fff81017 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3646; x-ms-traffictypediagnostic: MN2PR11MB3646: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(136003)(376002)(396003)(39860400002)(189003)(199004)(68736007)(14454004)(4326008)(25786009)(6246003)(316002)(66476007)(486006)(5660300002)(7736002)(53936002)(6116002)(6512007)(478600001)(3846002)(2906002)(6506007)(71190400001)(8936002)(102836004)(36756003)(6486002)(6436002)(256004)(26005)(76176011)(86362001)(476003)(229853002)(186003)(66574012)(71200400001)(81156014)(66946007)(33656002)(99286004)(446003)(14444005)(8676002)(305945005)(2616005)(11346002)(66556008)(54906003)(64756008)(73956011)(66446008)(76116006)(81166006)(66066001)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3646; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8i8jY1MbxWRUyZpwjF+GFDDFc2218FbceyAVXBdRS3z6T1jm+QdoFIEVL6lxN3CRBCnuFaktsN+oqu21irahOWp54a4IJv6/IwMZTY7aQPxLAuW+H0oM0EngW1UW1pskqfrCgZxp5HKrQ7JXhbk8cTQQVm8wceM3YK82B3ePMoPOQxoKp5dfBBQCoJbxLXuvEhvgbvHrenjjWjfMqYI2KnzUjUr+Ixv7pbHYsynXsJJZ/Wn9ZN7H1Q2Kv+sveAVBbq7z/VHrjZbsTs4eZMWqFfaKI8ns/KkUA8f125wK1pF6d1E0ArapAlJIYx+99yPSs3EKiMjp6zE61ikZUpwFxwN+kwymJXkDDQtmm5on/rKf1A+lO+kunAU4RvV/lQ/hw3Vx7u8CGUfSYUYaZdWM9AJrsi4yWI6ksP5H9oahceY= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3b3c5b75-a3a5-445b-c3a6-08d6fff81017 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 20:50:20.3660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3646 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 20:50:30 -0000 SGVsbG8gTWljaGFlbCANCg0KUGxlYXNlIHNlZSBiZWxvdyANCg0KPiANCj4gUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNCj4+IDZMb1dQQU4gTkQg aXMgaW1tdW5lIHRvIHRoZSByZW1vdGUgRE9TIGF0dGFja3Mgb24gdGhlIE5EIGNhY2hlLCB0aGUN Cj4+IG9uZXMgY29taW5nIGZyb20gdGhlIG91dHNpZGUgb2YgdGhlIHN1Ym5ldCwgaS5lLiwgZnJv bSBhIHBsYWNlIHRoYXQgaXMNCj4+IG91dCBvZiB0b3VjaCBhbmQgdmlydHVhbGx5IG5vd2hlcmUu DQo+IA0KPj4gVGhpcyBpcyBiZWNhdXNlIGluIGFuIFJGQyA2Nzc1Lzg1MDUtb25seSBuZXR3b3Jr LCB0aGVyZSBpcyBubyByZWFjdGl2ZQ0KPj4gb3BlcmF0aW9uLCBhIHBhY2tldCBjb21pbmcgZnJv bSB0aGUgb3V0c2lkZSBvZiB0aGUgc3VibmV0IGZvciBhIG5vZGUNCj4+IHRoYXQgaXMgbm90IHJl Z2lzdGVyZWQgdG8gdGhlIHJvdXRlciBpcyBqdXN0IGRyb3BwZWQuIEp1c3QgbGlrZSBhbiBBUA0K Pj4gZG9lcyBub3QgY29weSBhIHBhY2tldCBvbiB0aGUgd2lyZWxlc3MgZm9yIGEgTUFDIHRoYXQg aXMgbm90DQo+PiBhc3NvY2lhdGVkLg0KPiANCj4gVGhlcmUgYXJlIGEgZmV3IGF0dGFja3Mgb24g dGhlIE5EIGNhY2hlIHRoYXQgSSBjYW4gdGhpbmsgb2YuDQo+IE9uZSBvZiB0aGVtIHRoYXQgd2Ug c2VlIG9uIHRoZSBJRVRGIG5ldHdvcmsgaXMgdGhlIHNjcmlwdCBraWRkaWVzIHdobw0KPiBzZXF1 ZW50aWFsbHkgc2NhbiBJUCBhZGRyZXNzZXMuICBXZSBoYXZlIGEgbG90IG9mIHRoZW0sIGFuZCBz byB3ZSBmbG9vZCB0aGUNCj4gd2lmaSB3aXRoIEFSUCBxdWVyaWVzICh2NCkgYW5kIE5TICh2Niku ICBXZSBoYXZlIG1pdGlnYXRpb25zIGZvciB0aGlzLg0KPiANCj4gSW4gdGhlIHJvdXRlLW92ZXIg NnRpc2NoL1JQTCBzcGFjZSwgd2UgZG9uJ3QgKGFzIHlvdSBpbmRpY2F0ZSksIHVzZSBOUyBieSB0 aGUNCj4gcm91dGVyLCB3ZSBrbm93IHdobyBpcyBvbiBvdXIgbmV0d29yaywgYW5kIHdlIHdvdWxk IGp1c3QgaGF2ZSBubyAvMTI4IHJvdXRlcywNCj4gYW5kIGp1c3QgZHJvcCB0aGUgcGFja2V0cy4g IElzIHRoaXMgdGhlIGF0dGFjayB0aGF0IHlvdSBhcmUgc3BlYWsgb2YgYXMgYQ0KPiByZW1vdGUg RE9TPw0KDQpZZXMsIA0KDQpTY2FubmluZyBpbiB2NiBjYW4gaGFyZGx5IGJlIHVzZWQgdG8gZGlz Y292ZXIgYWRkcmVzc2VzIGJ1dCBpdCBjYW4gYmUgdXNlZCBhcyBhIERPUyBhdHRhY2sgYWdhaW5z dCB0aGUgQ1BVIGJlY2F1c2UgdGhlIHNpbGljb24gbmVlZHMgdG8gcHVudCBvbiBjYWNoZSBtaXNz LiBJdCBjYW4gYWxzbyBiZSB1c2VkIHRvIERPUyB0aGUgbmVpZ2hib3IgY2FjaGUuIEFuZCBpdCBp cyBoYXJkIHRvIGRpZmZlcmVudGlhdGUgZnJvbSBsZWdpdGltYXRlIG5ldyB0cmFmZmljLg0KDQpU aGUgcG9zc2liaWxpdHkgZm9yIHN1Y2ggYW4gYXR0YWNrIGNvbWVzIGZyb20gdGhlIHJlYWN0aXZl IG5hdHVyZSBvZiBORCwgd2hpY2ggd2FzIGRlc2lnbmVkIHdoZW4gSVAgcm91dGluZyB3YXMgaW4g c29mdHdhcmUgYW5kIHRoZSBuZXR3b3JrIGEgaGFwcHkgV29vZHN0b2NrLiBUaW1lcyBoYXZlIGNo YW5nZWQgYW5kIGEgbW9kZXJuIE5EIHNob3VsZCBwcm90ZWN0IGl0c2VsZiBhbmQgdGhlIGFkZHJl c3NlcyBpdCBtYW5hZ2VzICh0aGluayBTZU5EIGFuZCBTQVZJKSBhbmQgc2hvdWxkIGJlIGZyaWVu ZGx5IHRvIGZhYnJpY3MsIHRvIHdpcmVsZXNzIGFuZCB0byBoYXJkd2FyZSBmb3J3YXJkZXJzLiBX ZSBoYXZlIHRoYXQgb24gdGlueSBkZXZpY2VzIGJ1dCBpdOKAmXMgc3RpbGwgbWlzc2luZyBpbiB0 aGUgYmlnIGlyb25zLg0KDQo+IA0KPj4gWW91ciBwb2ludCBiZWxvdyByZW1haW5zIGNvcnJlY3Qs IHNpbmNlIHRoZSBhdHRhY2sgeW91IGRlc2NyaWJlIGlzIGZyb20NCj4+IGEgbm9kZSB0aGF0IHJl YWNoZXMgdGhlIHJvdXRlciBhdCBMMi4gQXJndWFibHksIHRoYXQgYXR0YWNrIGlzDQo+PiBwaHlz aWNhbGx5IG11Y2ggaGFyZGVyIHRvIHBlcmZvcm0gdGhhbiB0aGUgRE9TIHBhY2tldCBmcm9tIG91 dGVyDQo+PiBzcGFjZS4NCj4gDQo+IFdoZW4gSSBtZW50aW9uZWQgYXR0YWNrcyBvbiB0aGUgTkQg Y2FjaGUsIEkgYW0gcmVmZXJyaW5nIHRvIHRob3NlIHRoYXQgY2FuDQo+IG9jY3VyIGZyb20gd2l0 aGluIHRoZSA2dGlzY2ggbmV0d29yayBmcm9tIG1hbGljaW91cyBwbGVkZ2Ugbm9kZXMuICBXZSBo YXZlIHRvDQo+IGxpbWl0IHRoZSBOQ0UgdXNhZ2UgYnkgdW50cnVzdGVkIG5vZGVzIHNvIHRoYXQg d2UgaGF2ZSBzcGFjZSBmb3IgYXMgbWFueQ0KPiByZWdpc3RlcmVkIG5vZGVzLg0KPiBJIHRoaW5r IHlvdSBhcmUgYWdyZWVpbmcgd2l0aCBtZSBhYm92ZS4NCj4gDQoNClllcyBJIGNlcnRhaW5seSBm b2xsb3dlZCB5b3UgdGhlcmUgYW5kIGFncmVlLiBXZSBoYWQgdGhhdCBkaXNjdXNzaW9uIGZvciA2 VGlTQ0ggbWluaW1hbCBzZWN1cml0eS4gTXkgcG9pbnQgd2FzIHRoYXQgdGhpcyBsb2NhbCBET1Mg YXR0YWNrIHJlcXVpcmVzIGEgcGh5c2ljYWwgcHJlc2VuY2UgYW5kIGlzIG11Y2ggaGFyZGVyIHRv IGFjaGlldmUgdGhhbiB0aGUgcmVtb3RlIERPUy4NCg0KDQo+IEkgYmVsaWV2ZSB0aGF0IHRoZSBp c3N1ZSB0aGF0IEplbiBpcyBkZXNjcmliaW5nIHdvdWxkIGZvciB1bmF3YXJlIGxlYXZlcyB0aGF0 DQo+IHdlcmUgc2xlZXB5Lg0KDQpVbmF3YXJlIExlYXZlcyB0aGF0IGZvbGxvdyB0aGUgUk9MTCBz cGVjcyByZWdpc3RlciB0aGVpciBhZGRyZXNzZXMgYW5kIHNsZWVwLiBUaGV5IGNhbiBzbGVlcCBm b3IgdGhlIHdob2xlIGxpZmV0aW1lIG9mIHRoZWlyIHJlZ2lzdHJhdGlvbiwgdGhlIHJvdXRlciB3 aWxsIG1haW50YWluIGFuIE5EIGVudHJ5IGFuZCB0aGUgbmV0d29yayB3aWxsIHByb3RlY3QgdGhl IGFkZHJlc3Mgb3duZXJzaGlwLg0KVG8geW91ciBwb2ludCB0aGUgbm9kZSBtdXN0IHdha2UgdXAg YW5kIHJlZnJlc2ggdGhlIHJlZ2lzdHJhdGlvbiBiZWZvcmUgaXQgZXhwaXJlcy4NCg0KV2hhdOKA mXMgbGVmdCBvZiBKZW7igJlzIGlzc3VlIHdpdGggcmVnaXN0cmF0aW9uIGlzIHRoZSBhc3ltbWV0 cmljYWwgcm91dGluZy4gSW4gdGhlIFJPTEwgc3BlY3MgdGhlIHJvdXRlciB0aGF0IGhhcyB0aGUg cmVnaXN0cmF0aW9uIGluamVjdHMgdGhlIHJvdXRlIGluIHRoZSBNTFNOIGFuZCBnZXRzIHRoZSB0 cmFmZmljIGJhY2sgc28gdGhlIGlzc3VlIGRvZXMgbm90IGV4aXN0LiBJbiBhIHRyYW5zaXQgbmV0 d29yayB0aGUgcm91dGVyIHdvdWxkIGZvcndhcmQgdGhlIHJlZ2lzdHJhdGlvbiBzdGF0ZSB0byBh IDZMQlIgdGhhdCBjYW4gYW5zd2VyIHVuaWNhc3QgbG9va3VwcyBmcm9tIG90aGVyIHJvdXRlcnMs IHN0aWxsIGluY3VycmluZyBhIGRlbGF5LCBvciBtYXkgcHVzaCBhIHN0YXRlIHRvIG90aGVyIHJv dXRlcnMgb3IgdG8gYSBsb2FkIGJhbGFuY2VyIHNvIHRoZSByb3V0ZXIgd2l0aCB0aGUgcmVnaXN0 cmF0aW9uIGdldHMgdGhlIHRyYWZmaWMgZmlyc3QuDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGFzY2Fs IA0KDQo+IC0tDQo+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwg U2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg== From nobody Wed Jul 3 14:03:55 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30A212023F; Wed, 3 Jul 2019 14:03:22 -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, 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 header.b=DrlF5VKL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xyMRzc12 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 s10wAvgtsLOK; Wed, 3 Jul 2019 14:03:20 -0700 (PDT) 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 15742120667; Wed, 3 Jul 2019 14:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1828; q=dns/txt; s=iport; t=1562187800; x=1563397400; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WhJzmC+WD/YjOJYZ685frNJZJSMy6M/yummXVqacYJo=; b=DrlF5VKLvQSkobos5MeXPx3ZQJ3wAd8SchYAokxn4tNbs1RyjHQlh/pI PUiyFZkHhFdZ8cCYK8Azrx8RKDies/luaA2xe00P7by7dJdQNx8pnVt60 sBpV0+eVRN6kUHG2bp2+AOp5ULUgLD7kgXtSH13eb7n3yRVrXHrC8iBGV g=; IronPort-PHdr: =?us-ascii?q?9a23=3AVenclRQwt0uiB22ia141jLs7Zdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAABIFx1d/5tdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBQ1ADgT8gBAsoCoQSg0cDhFKJdIJbiU2NeYE?= =?us-ascii?q?ugSQDVAkBAQEMAQEtAgEBhEACF4ILIzQJDgEDAQEEAQECAQVtijcMhUoBAQE?= =?us-ascii?q?DARIREQwBATcBBAsCAQgYAgImAgICHxEVEAIEDgUigwCBawMODwECAZowAoE?= =?us-ascii?q?4iGBxgTKCeQEBBYUQDQuCEgmBDCgBi14XgUA/gTgfgkw+ghqFNDKCJow3ggI?= =?us-ascii?q?vjVmNPkAJAoIWjz5Og3MbglqVF5ZfjgQCBAIEBQIOAQEFgVA4gVhwFWUBgkG?= =?us-ascii?q?CQYNxilNyAYEoi0MBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,448,1557187200"; d="scan'208";a="591251873" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 21:03:19 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x63L3IVF008353 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 21:03:18 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 16:03:18 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 17:03:16 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 16:03:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=WoUvtHpUnJRSJvUliw01ZiCPWhCucMhdgta/uWoiFYgdaY/ruwHt+vLkfLGTd47islU1lEzzpZD1KICO1HWPuGRnUtIpA8Hpshx+Zq20CxV4UWhy74PWpPUmqrOmpAvowBvB41mIO3Z9iCnhy/MdrP8l0dAsi8HeyBZlF4+Vt9A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhJzmC+WD/YjOJYZ685frNJZJSMy6M/yummXVqacYJo=; b=u+SyWdCdLhtVAmAGceb0VxlbM1PitvPLYHD5jVoHatK8UseQO14FbUIgEdqiz67uKMpKBoY75WZ8Yo29Tjri8BskKu0SIR49oEWgLTAUH8tzzqfpDthp/Y/sIcimNl267AcNhTS13dFsx26UFg0UuXHw3HgRuO+XkLHmiLBMtsc= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhJzmC+WD/YjOJYZ685frNJZJSMy6M/yummXVqacYJo=; b=xyMRzc12uVSxWuCFsmhWmX+AOEAdgMh++trYZ5GkOoD5UzaFwBbXJxgjXcixG++UfbyGpCjAr1mGpxNxF88kskZpiKilImMBiCwcQiw4LL7KFFY72jXgjQz072Hs2L7aiFHropGfdYPYPEpchs7+6Ck6Ea70WyYxxYGVVfr2I1A= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3982.namprd11.prod.outlook.com (10.255.181.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 3 Jul 2019 21:03:15 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 21:03:15 +0000 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter CC: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, Jen Linkova , "6tisch@ietf.org" <6tisch@ietf.org>, "V6 Ops List" , 6man <6man@ietf.org> Thread-Topic: [6lo] ND cache entries creation on first-hop routers Thread-Index: AQHVMOxYqZ+Ae5ReXkiJP5a4XqZLuaa4gaXggADbFICAAAbk2w== Date: Wed, 3 Jul 2019 21:03:15 +0000 Message-ID: References: <5377.1562081856@localhost> , <0e80ea5d-d659-2d3e-43ac-674531f171eb@gmail.com> In-Reply-To: <0e80ea5d-d659-2d3e-43ac-674531f171eb@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [91.69.164.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a593cb5-4233-40d9-64a0-08d6fff9de07 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3982; x-ms-traffictypediagnostic: MN2PR11MB3982: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(43544003)(189003)(199004)(53546011)(66476007)(256004)(26005)(81166006)(81156014)(66946007)(66446008)(64756008)(66556008)(6486002)(76116006)(14444005)(86362001)(486006)(68736007)(6916009)(186003)(4326008)(66066001)(7736002)(102836004)(73956011)(305945005)(3846002)(6116002)(8936002)(478600001)(8676002)(53936002)(66574012)(6246003)(2906002)(33656002)(476003)(446003)(99286004)(14454004)(229853002)(5660300002)(6506007)(6436002)(25786009)(71200400001)(36756003)(71190400001)(91956017)(11346002)(2616005)(54906003)(76176011)(316002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3982; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7GoXhBDCvCtv+0S63zCJReE1H4VE059pAQ6IVSaO3TrYx12OgFe8kJwMTYr95COobsT3YtIxlG/S7FP0irhEk6s3SeTI6MHUGBot/nbCuP85eB4UQfUVLYe6AotP9Z3c2Gv50K36vqNTc7/C72FglQrICeNgEhehEdpmFwZ8hzLAbqVNQnWBSPB/z5VzqShQMNG6Y7zRI4PcDFTicKgvriuLP9j/+TIjwCiVfJiAMO9C2gzuySmyv2pjwvcOsXiOtS/68HSQS6WkCzleiOnGoV15kZcUf6X0kZnHa8MqkPvCCxjptn9RuJ8ZjRRqm3byGkZ/miu28AmnNjJXESm54N0FBSsaz5n51uimK9mMQYr33M7HRTqIXSmRMIDVOIARUnaHUIvR2Swn4wFMgb+nf+R33Bx5chjPO3waH9mYnKQ= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0a593cb5-4233-40d9-64a0-08d6fff9de07 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 21:03:15.4031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3982 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 21:03:30 -0000 U29ycnkgQnJpYW4gSSBtaXNzIHlvdXIgcG9pbnQuDQoNClRoZSBkaXNjdXNzaW9uIGhlcmUgaXMg dG8gZmluZCBhIHdheSBmb3IgdGhlIG5vZGUgdG8gYXV0b2NvbmYgYW4gYWRkcmVzcyBhbmQgdGhl biBub3RpY2UgdGhlIHJvdXRlcihzKSBwcm9hY3RpdmVseSBzbyB0aGUgTkQgTkNFIGlzIHJlYWR5 IHdoZW4gdGhlIGZpcnN0IHBhY2tldCBjb21lcyBmcm9tIHRoZSBvdXRzaWRlIGZvciB0aGlzIG5v ZGUuDQoNCkkgYWdyZWUgd2hvbGVoZWFydGVkbHkgd2l0aCBKZW7igJlzIHJlcXVpcmVtZW50Lg0K DQpJIGFncmVlIGxlc3Mgd2l0aCB0aGUgaWRlYSBvZiBvdmVyc3RyZXRjaGluZyBORCBhcyBpdCBz dGFuZHMgdG8gYWNoaWV2ZSB0aGlzLCBmb3IgcmVhc29ucyBJIGdhdmUgYWxyZWFkeS4gU28gcHJl cG9wdWxhdGUgdGhlIE5DRSwgeWVzLCBidXQgZG8gaXQgcmlnaHQgd2l0aCBwcm90b2NvbCBlbGVt ZW50cyB0aGF0IGd1YXJhbnRlZSBhIHN0YXRlIHRoYXQgaXMgYWNjdXJhdGUsIHNlY3VyZSwgYW5k IHBlcnNpc3RlbnQgZm9yIGEgY29tbWl0dGVkIGxpZmV0aW1lLCBub3Qgd2l0aCB5ZXQgYW5vdGhl ciBwYXRjaCB0byB0aGUgb2xkIHN0cnVjdHVyZS4NCg0KSeKAmW0gaW50ZXJlc3RlZCB0byBoYXZl IGEgcGFyYWxsZWwgZGlzY3Vzc2lvbiBvbiB3aGVyZSBSRkMgODUwNSBjYW4gbm90IGFwcGx5LiBJ biB0aGUgcHJvZHVjdHMgYW5kIHVzZSBjYXNlcyBJ4oCZbSBhd2FyZSBvZiwgaXQgY291bGQsIHNp bmNlIHdlIGFyZSBhY3R1YWxseSBmYWtpbmcgaXQgYnkgc25vb3BpbmcgTkQgYW5kIERIQ1AgdG8g YWNoaWV2ZSBzaW1pbGFyIGJ1dCBsZXNzIGFjY3VyYXRlIHJlc3VsdHMuDQoNClRha2UgY2FyZSwN Cg0KUGFzY2FsDQoNCj4gTGUgMyBqdWlsLiAyMDE5IMOgIDIyOjM5LCBCcmlhbiBFIENhcnBlbnRl ciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiBhIMOpY3JpdCA6DQo+IA0KPiBPbiAwMy1K dWwtMTkgMjA6MTMsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6DQo+IA0KPiAuLi4N Cj4+IEknbSBiYWZmbGVkIHRoYXQgdGhlIHJlYWN0aXZlIE5EIGlzIHN0aWxsIHRoZSBvZmZpY2lh bCB0ZWNobmlxdWUgZm9yIElQdjYgbG9va3VwIGF0IDZNQU4uDQo+IA0KPiBIb3cgY2FuIGl0IGJl IG90aGVyd2lzZSB3aGVuIGEgbm9kZSBjYW4gZ2l2ZSBpdHNlbGYgYSBuZXcgYWRkcmVzcyBhdCBh bnkgdGltZSB3aXRob3V0IG5vdGljZT8NCj4gDQo+IEknbSBub3QgYXJndWluZyB3aXRoIHlvdSBh Ym91dCBSRkMgNjc3NS84NTA1IG5ldHdvcmtzLCBidXQgdGhhdCBkb2Vzbid0IGFwcGx5IGV2ZXJ5 d2hlcmUuDQo+IA0KPiAgICBCcmlhbg0K From nobody Wed Jul 3 15:27:28 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FDF120672; Wed, 3 Jul 2019 15:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GxP7tBhUrGuu; Wed, 3 Jul 2019 15:27:12 -0700 (PDT) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 E3E1D12068B; Wed, 3 Jul 2019 15:27:11 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id x4so4471170wrt.6; Wed, 03 Jul 2019 15:27:11 -0700 (PDT) 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=ZNGfxlq57hSeXH7bEnVXmY9IhvEfi5RLy/g83mrvRO4=; b=tkE5cVH6E2w5PQzibk0auyNGy5gPMUOmMDTwCRT+6mdhnu2246nhwrHPecLW+yOvlG rMKrGS2mPf50TW1mRR9YrjpDmmpRUhD4LlKV93BDMh0einCuuDnShcih9pCrUvbMa0bY rw514Qle3dFKP0B1p5D52wARgwb9s/RAQC/NTe8WZFzyg8WGh0BlNkrkc7V/AqGerfD5 0odiMdpQCa3rvmyPhA4oUIMyPEivCnss0NhUv3xhNTt+VK9Lea4qPCl2dZqJbs8JebsT eRK/bQpthEw9jInrx85CD2iatPTdzx5Je5ngR2wLd/DfI262qIJxpBBFtCXeNTBxhrdU pYWA== X-Gm-Message-State: APjAAAVbVcaaUf+l5mtGpOQJozUJqOJ08d+cUmEd3W2M17OecOjmfhBV Nn3rJ60iwOh6h0R60VYKaKYkODX5Et2IaTs3mOQ= X-Google-Smtp-Source: APXvYqwc7NfqenZuduBM1Y1VwR6/tUVNWTFh6cv3tzOBCNJuHPKvbH+bNWL4jp+VP2ptOb6FYe0gKSjZFAAFWgEYBdM= X-Received: by 2002:a5d:4908:: with SMTP id x8mr29645789wrq.290.1562192829982; Wed, 03 Jul 2019 15:27:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 3 Jul 2019 15:26:58 -0700 Message-ID: To: Jen Linkova Cc: V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000b3ab97058cce5c24" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 22:27:20 -0000 --000000000000b3ab97058cce5c24 Content-Type: text/plain; charset="UTF-8" At Wed, 3 Jul 2019 17:09:58 +1000, Jen Linkova wrote: > > - Section 2.2.1: I'm not sure if sending an unsolicited NA for an > > optimistic address really respects the sense of RFC4429 Section 2.2. [...] > Very good point. Two things are probably worth considering here: > 1) Actions prohibited in the Section 2.2 of RFC4429 (sending NS from > the optimistic address and sending RS with SLLAO) would both *update* > the ND cache entry if such entry > exists. So I guess the risk of potential disruption is higher. What > the draft suggests is only creating an entry if one does not exist > already (it would also update INCOMPLETE entry). > If the entry exists (for the "rightful owner" ) the only thing which > might happen is REACHABLE -> STALE change which should not disrupt the > traffic flow. Right. > 2) the case when a rightful owner of the address exist but there is no > ND cache entry would probably mean there is no (or minimal) disruption > anyway - as there is no traffic to that address. The only corner case > seems to me 'there is an incomplete entry so the router has started ND > process and now the new owner came". Or some external (off-link) nodes voluntarily sends packets to that address through the router after the creation of the neighbor cache entry due to the unsolicited NA (but not before that). Without the NA the packets should go to the "rightful owner" of the address, but they are now forwarded to the node using the optimistic address. -- JINMEI, Tatuya --000000000000b3ab97058cce5c24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Wed, 3 Jul 2019 17:09:58 +1000,
Jen Linkova <furry13@gmail.com> wrote:

&g= t; > - Section 2.2.1: I'm not sure if sending an unsolicited NA for = an
> > =C2=A0 optimistic address really respects the sense of RFC4= 429 Section 2.2.
[...]
> Very good point. Two things are probably = worth considering here:
> 1) Actions prohibited in the Section 2.2 of= RFC4429 (sending NS from
> the optimistic address and sending RS wit= h SLLAO) would both *update*
> the ND cache entry if such entry
&g= t; exists. So I guess the risk of potential disruption is higher. What
&= gt; the draft suggests is only creating an entry if one does not exist
&= gt; already (it would also update INCOMPLETE entry).
> If the entry e= xists (for the "rightful owner" ) the only thing which
> mi= ght happen is REACHABLE -> STALE change which should not disrupt the
= > traffic flow.

Right.

> 2) the case when a rightful ow= ner of the address exist but there is no
> ND cache entry would proba= bly mean there is no (or minimal) disruption
> anyway - as there is n= o traffic to that address. The only corner case
> seems to me 'th= ere is an incomplete entry so the router has started ND
> process and= now the new owner came".

Or some external (off-link) nodes vol= untarily sends packets to that
address through the router after the crea= tion of the neighbor cache
entry due to the unsolicited NA (but not befo= re that).=C2=A0 Without the NA
the packets should go to the "rightf= ul owner" of the address, but they
are now forwarded to the node us= ing the optimistic address.

--
JINMEI, Tatuya
--000000000000b3ab97058cce5c24-- From nobody Wed Jul 3 15:40:55 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD551200D6 for ; Wed, 3 Jul 2019 15:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnZ0yTjdWMLb for ; Wed, 3 Jul 2019 15:40:35 -0700 (PDT) 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 208811200E0 for ; Wed, 3 Jul 2019 15:40:32 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id 207so3792990wma.1 for ; Wed, 03 Jul 2019 15:40:32 -0700 (PDT) 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=Vq9cBy4ScXv7fCHc1BEj2Hpeym59r4iUY0kc39RwdgU=; b=ENpYQcdAa8Rj2+VRXhctEm5ZjKRY2ZqKdp8bcpN6MbOFYIPiIS6XcqBy/fwBJLxdyQ BLcbG6c56ZzVURoDXwdUUkguqMurgE4nl663FMx69z0hqYB7fuNrmb8o9sSvOKRbK1TD xcF6LxGritAAKIXq5UKm0DDMKbjF6NKuK5AHjW/5ZaWaCkvchY34mFTX/oFMwGLCIMXk GlroX2EQnsRY2hB4dzTKtu6i0DHTyDQFyIisHJC92tt8RQSvRMH42Z+M2NFyVCzCguZd 2kcEovhlplJNelimXJlKoSY7+PlphlrYDGxacIkrgjv2UIbib0pLqrp2WC+qFCIWJFJr ukhg== 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=Vq9cBy4ScXv7fCHc1BEj2Hpeym59r4iUY0kc39RwdgU=; b=aAFrX4IgQuPnr2IHge/rdo2y0I4FK4j3KM6vJ9OuKv66akUZcI1Kg8cuiHaNH1zp4u yBUZs+LC4F5MLULWcwG6Cg1Tmbc+4Z17umenwr6tBLRpYCSz8uAD/XA+OF9go0UwXFRL qPGO+0rApVpIbyCiiSV+EZJP9dEzA4qr8f+iMaFMeRB+tURWNyiDuf2jJ4fQYT2vhruY 3pBmepUd6XXdFmTkrY12laq9fCHEgZuqQpBiA04Qy5jcOa64pXRq7YcvpqQe5n0HBSNQ LogKGTTHwzBGXt9RxYLbfDbfvL8E6r5dwXDHcjHMwIaZghQhcHUgRZQ7B7sRYznB91xw KK9g== X-Gm-Message-State: APjAAAXB0e8TwlL2royY70ESiWeAcRfIavd5n7Zo05OLqnAV9WUKG2I8 CTmEK0qatQRwhWpGKdelxuytR4/KaA4biN/rjw8mtg== X-Google-Smtp-Source: APXvYqyJBGSxcn61lPRMBTdKxG5gA1nqQhU3A8QiNr6AcNgvaPToh8+Nh/YI19rxGz3U5vDX1iiQQ+1PDrWaOkbLCB0= X-Received: by 2002:a05:600c:23d2:: with SMTP id p18mr9081431wmb.108.1562193630103; Wed, 03 Jul 2019 15:40:30 -0700 (PDT) MIME-Version: 1.0 References: <5377.1562081856@localhost> <13349.1562180358@localhost> In-Reply-To: <13349.1562180358@localhost> From: Lorenzo Colitti Date: Thu, 4 Jul 2019 07:40:16 +0900 Message-ID: To: Michael Richardson Cc: Jen Linkova , 6lo@ietf.org, 6tisch@ietf.org, V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000065291b058cce8c02" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 22:40:36 -0000 --00000000000065291b058cce8c02 Content-Type: text/plain; charset="UTF-8" On Thu, 4 Jul 2019, 04:00 Michael Richardson, wrote: > Let me suggest a different hack: use stateful DHCPv6. > DHCPv6 doesn't fix this because a) DHCP goes to a server, not the router, b) DHCPv6 uses link-local addresses and not the global addresses, c) there is nothing in the DHCPv6 specs about explicitly populating ND caches. For off-link servers, the router can perform layering violations such as "snoop DHCPv6 replies and add them to the neighbour cache". But such layering violations don't require DHCPv6. For example, the router can also snoop DAD packets, or glean ND cache entries from forwarded packets. > --00000000000065291b058cce8c02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 4 Jul 2019, 04:00 Michael Richardson, <mcr+ietf@sandelman.ca> wrote:
Let me suggest a different hack: use stateful DHCPv6.

DHCPv6 doesn't fix= this because a) DHCP goes to a server, not the router, b) DHCPv6 uses link= -local addresses and not the global addresses, c) there is nothing in the D= HCPv6 specs about explicitly populating ND caches.
<= br>
For off-link servers, the router can perform lay= ering violations such as "snoop DHCPv6 replies and add them to the nei= ghbour cache". But such layering violations don't require DHCPv6. = For example, the router can also snoop DAD packets, or glean ND cache entri= es from forwarded packets.
--00000000000065291b058cce8c02-- From nobody Wed Jul 3 16:20:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44A31200E0; Wed, 3 Jul 2019 16:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 qNG8PFixmyga; Wed, 3 Jul 2019 16:20:06 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 D5F15120096; Wed, 3 Jul 2019 16:20:06 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id p184so1985357pfp.7; Wed, 03 Jul 2019 16:20:06 -0700 (PDT) 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=Y7lhN7XUTg96KVkoqRgi0UuIDrU0k0fofMnNYDIVOmA=; b=Oxn+uwDpLvO2SlgG0MR8y7cVdYY+KMnTAmoGaGjLrrHwXSP3yhmjOjD60KbVy3cF24 uxzF3kwvHBZ8LM60MhddefQk/xRVvdHLR62OHcS1mfsINAMQx+6VxsqygGly2c7X7ZTw lNiYosPWbw/AdysL+xTF/Jb0M9L2ihjINBbtac+kw5J3Tn9gOVIFYmPcW8pPKDqkK2Dl 156B7OAh/MqZlkcD+GmG+W94m6AKIw+mpaF4DL/8oqG6+Qo55GCPyLQ7HxWBwkynYq2O UKrRZlo5+MhDAzvnWGzy7cRov8jSkKTWVJ/nl4OVCPIqYfZRZJqzDmmDACKmZJoXoXNp T/KQ== 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=Y7lhN7XUTg96KVkoqRgi0UuIDrU0k0fofMnNYDIVOmA=; b=gGmDNXTDTpR+YNXD7x9C+sERfcuMfHR3bmsA8GQ1GG9iFQu3A1uxkZNu/0Vo5T/c15 Eyq80vYxmswgxxXqdBouHPnzpOyh6krIwEvwnyNzGlvMjzgLmMO4ugmAks0wn2sW7JCo 09fyk+NZ3w9s0K09EMYgiMMI/q/Uy72wua6M1QGlJlEwQrMg4EwvFkQ8hhg0dx6Fp4Dk 76KcgfuEE1kPTAdHfraqvWBqkwf5OaFCk/IQ8eUlnu8Jaj6XyixU4JSawJ8thLxKjiBj CTRJ9hB6vtIbnDTtMBVWuOwBlylpszj5AVYrPHm1v+dexHTbn2S2mqk8hvP1Z+pExcrd Mb3w== X-Gm-Message-State: APjAAAXC1u8Odh1w6qgiyfENhPUtqK6wrrkMuy1u0/RVCSg6aSg8Cwna DD+tqVJ4diZGLNCEjFhgwYzfVOVP X-Google-Smtp-Source: APXvYqxH3kssX9n1hjUPFFlXZX2IRXl0wWnekzNySgGVudffLGXNyYPdGNaw5QrM2WxQXG+7akfh3Q== X-Received: by 2002:a63:1a5c:: with SMTP id a28mr39663441pgm.418.1562196005832; Wed, 03 Jul 2019 16:20:05 -0700 (PDT) Received: from [130.216.36.147] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.147]) by smtp.gmail.com with ESMTPSA id f17sm2883280pgv.16.2019.07.03.16.20.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 16:20:05 -0700 (PDT) To: "Pascal Thubert (pthubert)" Cc: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, Jen Linkova , "6tisch@ietf.org" <6tisch@ietf.org>, V6 Ops List , 6man <6man@ietf.org> References: <5377.1562081856@localhost> <0e80ea5d-d659-2d3e-43ac-674531f171eb@gmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 4 Jul 2019 11:20:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 23:20:09 -0000 On 04-Jul-19 09:03, Pascal Thubert (pthubert) wrote: > Sorry Brian I miss your point. >=20 > The discussion here is to find a way for the node to autoconf an addres= s and then notice the router(s) proactively so the ND NCE is ready when t= he first packet comes from the outside for this node. >=20 > I agree wholeheartedly with Jen=E2=80=99s requirement. Yes, I am not against satisfying this requirement, but we have a consider= able legacy of stacks that don't do this - so until that legacy has vanis= hed, the routers need to deal with it somehow. > I agree less with the idea of overstretching ND as it stands to achieve= this, for reasons I gave already. So prepopulate the NCE, yes, but do it= right with protocol elements that guarantee a state that is accurate, se= cure, and persistent for a committed lifetime, not with yet another patch= to the old structure. >=20 > I=E2=80=99m interested to have a parallel discussion on where RFC 8505 = can not apply. In the products and use cases I=E2=80=99m aware of, it cou= ld, since we are actually faking it by snooping ND and DHCP to achieve si= milar but less accurate results. So if you are advocating a generalisation of RFC8505 to non-6lo LANs, tha= t's certainly a discussion we could have, IMHO. Regards Brian >=20 > Take care, >=20 > Pascal >=20 >> Le 3 juil. 2019 =C3=A0 22:39, Brian E Carpenter a =C3=A9crit : >> >> On 03-Jul-19 20:13, Pascal Thubert (pthubert) wrote: >> >> ... >>> I'm baffled that the reactive ND is still the official technique for = IPv6 lookup at 6MAN. >> >> How can it be otherwise when a node can give itself a new address at a= ny time without notice? >> >> I'm not arguing with you about RFC 6775/8505 networks, but that doesn'= t apply everywhere. >> >> Brian From nobody Wed Jul 3 17:58:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65CF1201A0; Wed, 3 Jul 2019 17:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 eJaaQqwuaLGe; Wed, 3 Jul 2019 17:57:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3C4120179; Wed, 3 Jul 2019 17:57:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A1B2538192; Wed, 3 Jul 2019 20:55:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B2AA5BB7; Wed, 3 Jul 2019 20:57:44 -0400 (EDT) From: Michael Richardson To: "6lo\@ietf.org" <6lo@ietf.org>, V6 Ops List , 6man <6man@ietf.org> In-Reply-To: References: <5377.1562081856@localhost> <0e80ea5d-d659-2d3e-43ac-674531f171eb@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 00:57:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> I=E2=80=99m interested to have a parallel discussion on where RFC 85= 05 can not >> apply. In the products and use cases I=E2=80=99m aware of, it could,= since we >> are actually faking it by snooping ND and DHCP to achieve similar but >> less accurate results. > So if you are advocating a generalisation of RFC8505 to non-6lo LANs, > that's certainly a discussion we could have, IMHO. I think that it could be applied in situations of servers, such as data centers where there are multiple tenants. (Many VM infrastructures have shared front-end networks) I think that temporary addressess are not a feature in some of those deployments that everyone wants, and thus having a registration system is a feature. This does not solve the smartphone on new WIFI issue, which is a different situation completely. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0dTwgACgkQgItw+93Q 3WVR0wf/c2dm0fyaBy+fvyZEsSb+S2QB79u6zN8cCiH0qBWfuwI8oxrihxlAIY8c MOTKlAAmusfKizM2WQsC+25U183UU9q554gVqg6CTFN0ZyybWhgJlEtwNQtvBZR4 MfgdGmQZwwGZjynYzTIThCiNfjD8XYpIPMhmS0ZNJiYh9NuCyeKv4jgmbQxrgd11 kOOEJ4izPjfMOw9+SuYjluiNehaVqSjFBj3XKR1AycOC+Qr8O3l54yx8EQ7q5Ftx ON81M6Hw8JC9NEldMBv4qc2f+dQtD1tNcigqjDYiUzHAm/9YjjmfOayQ4qomIvVV feee7bnVSzpweyOePsH8gI4FsNd4kw== =cMRa -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 4 03:28:30 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC70B12001B; Thu, 4 Jul 2019 03:28:13 -0700 (PDT) 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, 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 header.b=GzQSa5wj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AiTPx1vF 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 47Wc6yGD5mFe; Thu, 4 Jul 2019 03:28:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E021200C7; Thu, 4 Jul 2019 03:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4242; q=dns/txt; s=iport; t=1562236091; x=1563445691; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BK+t+hAksRl/s8ku1m4YfRE7aiVNiXIruktwIvUWiGw=; b=GzQSa5wjEoQ/mHdXpZdgXiiyzZlk6Rrd40Oov4IW/j72g8JO0R57OfFw OFuRoZu5pNq/a2Obw94vKbfAPaG4+8I99IDKsyrJ3AaQW4E4cirhfrf26 uYqRojmlzc3KTJ5VyU9ldXvai2UtsptQaUWx3vvCaVHh/qNGme9ry3VJY o=; IronPort-PHdr: =?us-ascii?q?9a23=3A6qacvhcORR4t7Tt4VDECvgwPlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClAACp0x1d/4QNJK1mHQEBBQEHBQG?= =?us-ascii?q?BVAcBCwGBQ1ADalUgBAsohByDRwOOSoJbiU2NeYEugSQDVAkBAQEMAQEjCgI?= =?us-ascii?q?BAYFLgnUCF4ITIzUIDgEDAQEEAQECAQVtijcMhUoBARcREQwBATgLBgEZBAE?= =?us-ascii?q?BAQICJgIEHxEVCAkBBAESCBqDAYFqAx0BAgybVQKBOIhgcYEygnkBAQWBRkG?= =?us-ascii?q?DDg0LghIJgQwoAYRxhm0XgUA/gRFGgh6BcIEWRwEBAgEBgUcYgwgygiaLdES?= =?us-ascii?q?CMZsbQAkCghcDhlOJN4QOl3ONMIc+gXOOBQIEAgQFAg4BAQWBUgI0gVhwFTu?= =?us-ascii?q?CbAmCOIMdVIUUhT9yAQGBJ4sOKoIoAQE?= X-IronPort-AV: E=Sophos;i="5.63,450,1557187200"; d="scan'208";a="368507240" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jul 2019 10:28:10 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x64ASA0L012336 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jul 2019 10:28:10 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 05:28:09 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 05:28:09 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 4 Jul 2019 06:28:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BK+t+hAksRl/s8ku1m4YfRE7aiVNiXIruktwIvUWiGw=; b=AiTPx1vFs8yCyWIfAfzRCmPfmLzGQ5oxv09Mu8zaPsqxuq8fkYyYddjhX5BGTOBjslilWiMCi8y/wYBbxqpZ4sESA8r5pUlfO7Tz82dcS9Af3uE1wBaXOOUHQ/JaW+5hNse4vGXoeHr6dDgmrtkNE5IfrH9oxhWf4qbQ35/7+04= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4493.namprd11.prod.outlook.com (52.135.38.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Thu, 4 Jul 2019 10:28:08 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Thu, 4 Jul 2019 10:28:08 +0000 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, V6 Ops List , 6man <6man@ietf.org> Thread-Topic: Advocating a generalisation of RFC8505 to non-6lo LANs Thread-Index: AdUyUv8Sti4DS832TlSes7S8iQL/Vw== Date: Thu, 4 Jul 2019 10:28:08 +0000 Deferred-Delivery: Thu, 4 Jul 2019 10:27:53 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1008::1d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8244ffc-f98a-488b-7a53-08d7006a4ed8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4493; x-ms-traffictypediagnostic: MN2PR11MB4493: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(396003)(376002)(346002)(39860400002)(13464003)(51444003)(199004)(189003)(66946007)(55016002)(76116006)(6306002)(73956011)(66446008)(86362001)(6436002)(52536014)(53936002)(9686003)(2501003)(66556008)(2906002)(25786009)(110136005)(186003)(8936002)(66476007)(33656002)(102836004)(5660300002)(64756008)(486006)(476003)(53546011)(8676002)(66574012)(81166006)(68736007)(6116002)(256004)(966005)(478600001)(99286004)(6506007)(7696005)(316002)(46003)(14444005)(14454004)(7736002)(81156014)(71190400001)(71200400001)(74316002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4493; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GeCNecQHRbHkc61NDALh32CKIkJRANyXgnxKGYoRfwdrom/xrJvBVp5mNKCP9tPD0+YxYF7+pFpj6NLrbuKY68CSt0chhYzoadeCfsTGb2fMj5n2IAJDm7l4Y0GE/afoKRWWIC4Qzt+FmFrfYrchdNU9vaE/sFEWeNQ4CdeWHxoJrqxTKd3tiOlGaz/krHKcGt8FMbZgnolInuvSqDjp4wzCLPwk/YmWwKyHPzlRIX1V3s6B/L0TGK4LrWpky85oj74NtaaUw55MFMRuP1dmnmBKVVuVTABbj1XNbjUUykd0qTt0XgMZmciFHcAsCJjBe2ndT0kKCydC4jB3apfmcDfmBHDjH+lQGiEBC8m1xjWDWJ9Cgxehr8m5exfQEeijFOpsqB+Ny6hbqhFGJ7eJ3iGcHqq4Xunj/NqzVmy7LaU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b8244ffc-f98a-488b-7a53-08d7006a4ed8 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2019 10:28:08.3629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4493 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: [v6ops] Advocating a generalisation of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 10:28:14 -0000 SGVsbG8gQnJpYW46DQoNClllcywgSSdtIHdpbGxpbmcgdG8gbWFrZSB0aGUgY2FzZS4gDQoNClRo ZXJlIGFyZSBhIG51bWJlciBvZiByZWFzb25zIHRvIGVuYWJsZSBhIHJlZ2lzdHJhdGlvbiBtZXRo b2Qgb24gYmV5b25kIDZsbyBuZXR3b3JrczoNCi0gSXQgaXMgdXNlZnVsIGluIHdpcmVsZXNzIGlu IGdlbmVyYWwgYmVjYXVzZSBpdCBhZGRyZXNzZXMgbm9uLXRyYW5zaXQgbXVsdGlwb2ludCBsaW5r cyAoc2VlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtNm1h bi1pcHY2LW92ZXItd2lyZWxlc3MvKSBhbmQgTkJNQSBNTC1zdWJuZXRzDQotIGl0IGlzIHVzZWZ1 bCBpbiBwYXJ0aWN1bGFyIGluIFdpLUZpIGJlY2F1c2UgaXQgcmVkdWNlcyB0aGUgbmVlZCBmb3Ig YnJvYWRjYXN0IHF1aXRlIGRyYW1hdGljYWxseS4NCi0gSXQgaXMgdXNlZnVsIGluIGEgc3dpdGNo ZWQgZmFicmljIHRvIG1haW50YWluIGFuIGFjY3VyYXRlIHN0YXRlIGluIHRoZSBvdmVybGF5IG1h cHBpbmcgc2VydmVyIChzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dGh1YmVydC02bG8tdW5pY2FzdC1sb29rdXAvKQ0KLSBJdCBpcyB1c2VmdWwgaW4gYSBzaXR1YXRp b24gb2YgaG9zdCBtb2JpbGl0eSBpbiBnZW5lcmFsLCAoc2VlIHRoZSBkaXNjdXNzaW9uIGluIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJpZnQtcmlmdC0wNiNzZWN0aW9u LTUuMy4zICkgDQotIEl0IGlzIHVzZWZ1bCBmb3Igcm91dGVycyB3aXRoIGhhcmR3YXJlIGFzc2lz dCBmb3J3YXJkaW5nIHRvIGF2b2lkIHRoZSBwdW50aW5nIGRhbmNlIGFuZCBkcm9wcGluZyBvZiBw YWNrZXRzDQotIEl0IHByb3ZpZGVzIFNBVkkgcHJvcGVydGllcyB3aXRoIGEgd29ya2FibGUgU2Vj dXJlIE5EIChzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02 bG8tYXAtbmQvKQ0KLSBJdCBwcm92aWRlcyBhbiBhYnN0cmFjdCBpbnRlcmZhY2UgdG8gdGhlIHJv dXRlciB0byBnZXQgcm91dGluZyBzZXJ2aWNlcyAoYWxyZWFkeSB1c2VkIHdpdGggUklGVCwgUlBM LCBzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLXVu YXdhcmUtbGVhdmVzLywgYW5kIE5EIHByb3h5LCBzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi02bG8tYmFja2JvbmUtcm91dGVyLykNCi0gSXQgc29sdmVzIGEg bnVtYmVyIG9mIHByb2JsZW1zIGluY2x1ZGluZyBKZW4ncywgYnV0IGFsc28gc2xlZXBpbmcgZGV2 aWNlcyBvbiBub24tNmxvIG5ldHdvcmtzLCByZW1vdGUgRE9TIGFnYWluc3Qgcm91dGVyIGFuZCBO RCBjYWNoZSwgYW5kIG1vcmUuDQoNCkFsbCBpbiBhbGwgSSBzZWUgaXQgYXMgYSBtdWNoIG5lZWRl ZCBtb2Rlcm5pemF0aW9uIG9mIE5EIHRvIGNvcGUgd2l0aCB0aGUgZXZvbHV0aW9ucyBvZiB0aGUg bmV0d29yayAoSU9ULCBXaS1GaSBhbmQgb3ZlcmxheXMpIGFuZCB3aXRoIHRoZSBuZXcgbmVlZHMg YW5kIGJlaGF2aW9ycyAoaW5zdGFudCBjb25uZWN0aXZpdHksIGZhc3Qgcm9hbWluZykuDQoNCkFs bCB0aGUgYmVzdCwNCg0KUGFzY2FsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogNmxvIDw2bG8tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmlj aGFyZHNvbg0KPiBTZW50OiBqZXVkaSA0IGp1aWxsZXQgMjAxOSAwMjo1OA0KPiBUbzogNmxvQGll dGYub3JnOyBWNiBPcHMgTGlzdCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuIDw2bWFuQGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSZTogWzZsb10gTkQgY2FjaGUgZW50cmllcyBjcmVhdGlvbiBvbiBmaXJz dC1ob3Agcm91dGVycw0KPiANCj4gDQo+IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiAgICAgPj4gSeKAmW0gaW50ZXJlc3RlZCB0byBoYXZl IGEgcGFyYWxsZWwgZGlzY3Vzc2lvbiBvbiB3aGVyZSBSRkMgODUwNSBjYW4gbm90DQo+ICAgICA+ PiBhcHBseS4gSW4gdGhlIHByb2R1Y3RzIGFuZCB1c2UgY2FzZXMgSeKAmW0gYXdhcmUgb2YsIGl0 IGNvdWxkLCBzaW5jZSB3ZQ0KPiAgICAgPj4gYXJlIGFjdHVhbGx5IGZha2luZyBpdCBieSBzbm9v cGluZyBORCBhbmQgREhDUCB0byBhY2hpZXZlIHNpbWlsYXIgYnV0DQo+ICAgICA+PiBsZXNzIGFj Y3VyYXRlIHJlc3VsdHMuDQo+IA0KPiAgICAgPiBTbyBpZiB5b3UgYXJlIGFkdm9jYXRpbmcgYSBn ZW5lcmFsaXNhdGlvbiBvZiBSRkM4NTA1IHRvIG5vbi02bG8gTEFOcywNCj4gICAgID4gdGhhdCdz IGNlcnRhaW5seSBhIGRpc2N1c3Npb24gd2UgY291bGQgaGF2ZSwgSU1ITy4NCj4gDQo+IEkgdGhp bmsgdGhhdCBpdCBjb3VsZCBiZSBhcHBsaWVkIGluIHNpdHVhdGlvbnMgb2Ygc2VydmVycywgc3Vj aCBhcyBkYXRhIGNlbnRlcnMNCj4gd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIHRlbmFudHMuIChN YW55IFZNIGluZnJhc3RydWN0dXJlcyBoYXZlIHNoYXJlZA0KPiBmcm9udC1lbmQgbmV0d29ya3Mp DQo+IA0KPiBJIHRoaW5rIHRoYXQgdGVtcG9yYXJ5IGFkZHJlc3Nlc3MgYXJlIG5vdCBhIGZlYXR1 cmUgaW4gc29tZSBvZiB0aG9zZQ0KPiBkZXBsb3ltZW50cyB0aGF0IGV2ZXJ5b25lIHdhbnRzLCBh bmQgdGh1cyBoYXZpbmcgYSByZWdpc3RyYXRpb24gc3lzdGVtIGlzIGENCj4gZmVhdHVyZS4NCj4g DQo+IFRoaXMgZG9lcyBub3Qgc29sdmUgdGhlIHNtYXJ0cGhvbmUgb24gbmV3IFdJRkkgaXNzdWUs IHdoaWNoIGlzIGEgZGlmZmVyZW50DQo+IHNpdHVhdGlvbiBjb21wbGV0ZWx5Lg0KPiANCj4gLS0N Cj4gXSAgICAgICAgICAgICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMhICAgICAgICAgICAgICAg ICB8IGlwdjYgbWVzaCBuZXR3b3JrcyBbDQo+IF0gICBNaWNoYWVsIFJpY2hhcmRzb24sIFNhbmRl bG1hbiBTb2Z0d2FyZSBXb3JrcyAgICAgICAgfCAgICBJb1QgYXJjaGl0ZWN0ICAgWw0KPiBdICAg ICBtY3JAc2FuZGVsbWFuLmNhICBodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8gICAgICAgIHwgICBy dWJ5IG9uIHJhaWxzICAgIFsNCg0K From nobody Thu Jul 4 04:22:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69400120058; Thu, 4 Jul 2019 04:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 SarDTIETltEB; Thu, 4 Jul 2019 04:22:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915EA12004E; Thu, 4 Jul 2019 04:22:10 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45fbD060CFz10D8; Thu, 4 Jul 2019 13:22:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 4 Jul 2019 13:22:22 +0200 Cc: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, V6 Ops List , 6man <6man@ietf.org> X-Mao-Original-Outgoing-Id: 583932140.852785-cbb23dc7fc22da945977223bbf5eb36e Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Pascal Thubert X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalisation of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 11:22:14 -0000 RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty = much a no-brainer, if that foo has points where the 6LBR functionality = is naturally centralized. Not so easy for brownfield, i.e., in networks where classic ND is = already used in some hosts and some routers. =E2=80=9CEfficient ND=E2=80=9D= (which was essentially RFC 6775 for Ethernet and thus also traditional = WiFi) mostly didn=E2=80=99t take off at the time because we didn=E2=80=99t= articulate a cohabitation (=E2=80=9Ctransition=E2=80=9D) strategy. = I=E2=80=99m sure we can do that if we put a little more focus on it, = leading to another specification that describes how to run in mixed = classic/efficient ND networks. Gr=C3=BC=C3=9Fe, Carsten > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) = wrote: >=20 > Hello Brian: >=20 > Yes, I'm willing to make the case.=20 >=20 > There are a number of reasons to enable a registration method on = beyond 6lo networks: > - It is useful in wireless in general because it addresses non-transit = multipoint links (see = https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/) = and NBMA ML-subnets > - it is useful in particular in Wi-Fi because it reduces the need for = broadcast quite dramatically. > - It is useful in a switched fabric to maintain an accurate state in = the overlay mapping server (see = https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/) > - It is useful in a situation of host mobility in general, (see the = discussion in = https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 )=20 > - It is useful for routers with hardware assist forwarding to avoid = the punting dance and dropping of packets > - It provides SAVI properties with a workable Secure ND (see = https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/) > - It provides an abstract interface to the router to get routing = services (already used with RIFT, RPL, see = https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and ND = proxy, see = https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/) > - It solves a number of problems including Jen's, but also sleeping = devices on non-6lo networks, remote DOS against router and ND cache, and = more. >=20 > All in all I see it as a much needed modernization of ND to cope with = the evolutions of the network (IOT, Wi-Fi and overlays) and with the new = needs and behaviors (instant connectivity, fast roaming). >=20 > All the best, >=20 > Pascal >=20 >> -----Original Message----- >> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Michael Richardson >> Sent: jeudi 4 juillet 2019 02:58 >> To: 6lo@ietf.org; V6 Ops List ; 6man <6man@ietf.org> >> Subject: Re: [6lo] ND cache entries creation on first-hop routers >>=20 >>=20 >> Brian E Carpenter wrote: >>>> I=E2=80=99m interested to have a parallel discussion on where RFC = 8505 can not >>>> apply. In the products and use cases I=E2=80=99m aware of, it = could, since we >>>> are actually faking it by snooping ND and DHCP to achieve similar = but >>>> less accurate results. >>=20 >>> So if you are advocating a generalisation of RFC8505 to non-6lo = LANs, >>> that's certainly a discussion we could have, IMHO. >>=20 >> I think that it could be applied in situations of servers, such as = data centers >> where there are multiple tenants. (Many VM infrastructures have = shared >> front-end networks) >>=20 >> I think that temporary addressess are not a feature in some of those >> deployments that everyone wants, and thus having a registration = system is a >> feature. >>=20 >> This does not solve the smartphone on new WIFI issue, which is a = different >> situation completely. >>=20 >> -- >> ] Never tell me the odds! | ipv6 mesh = networks [ >> ] Michael Richardson, Sandelman Software Works | IoT = architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo >=20 >=20 From nobody Thu Jul 4 04:38:33 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CE7120094; Thu, 4 Jul 2019 04:38:18 -0700 (PDT) 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, 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 header.b=PSL3qG3X; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xCv+bzl+ 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 FfkqJwjX7iQl; Thu, 4 Jul 2019 04:38:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD42120183; Thu, 4 Jul 2019 04:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8346; q=dns/txt; s=iport; t=1562240294; x=1563449894; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=6HOwrpsukxvbx/kAP/3VCHmrjdO3pvYEdiQDa8fMGFY=; b=PSL3qG3XzDON8fS04GvIJu+bH5/8xBTCWpBg/TlpzNSpGNOtGoWtYby0 MgUHV2ZQg0TV6BHFjVoim1AxiJy50HsB5YjMISChEFKCMItwPXYeSWNzm 1n4TH3a6ZN0GMQ0MlipAnUti6b/GIoDsMoBK8lfHv2xY8XnCAvOUiTU6v w=; IronPort-PHdr: =?us-ascii?q?9a23=3AgqOvIhYttLKVZ6R4fF1Cs7D/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAABN5B1d/5NdJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVAYBAQsBgUNQA2pVIAQLKIQcg0cDjkqCW4lNjXmBLoEkA1QJAQEBDAE?= =?us-ascii?q?BGAsKAgEBgUuCdQIXghMjNQgOAQMBAQQBAQIBBW2KNwyFSgEBAQECAQEBEBE?= =?us-ascii?q?RDAEBLAsBBAcGAQYCDgMEAQEBAgImAgQfBgsVCAkBBA4FCBqDAYFqAw4PAQI?= =?us-ascii?q?Min+QYAKBOIhgcYEygnkBAQWBMgETQYMPDQuCEgmBDCgBhHGGbReBQD+BEUa?= =?us-ascii?q?CHi4+gQSBFkcBAQIBAYE3EBiDCDKCJot1RIIxmx9ACQKCF4ZWiTqEDpd4lG+?= =?us-ascii?q?Bc44JAgQCBAUCDgEBBYFRATaBWHAVO4JsCYI4gx1UhRSFP3IBAYEnixkBJQS?= =?us-ascii?q?CKAEB?= X-IronPort-AV: E=Sophos;i="5.63,450,1557187200"; d="scan'208";a="583652989" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jul 2019 11:38:12 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x64BcCS4004050 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jul 2019 11:38:12 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 06:38:12 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 06:38:11 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 4 Jul 2019 06:38:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6HOwrpsukxvbx/kAP/3VCHmrjdO3pvYEdiQDa8fMGFY=; b=xCv+bzl+iRvt7Y3tMmgAqxHqG34WXyAHTwLWWf6enC1bw+sl82itlkNfQqC1PeaqbRQZXaWBFB/YG37s0P8W1a7ppuFH0O/kowKBwzBjl7Zhn0WrPpT0se6Ucc82wbTED+GVYf6P3v8YBs9h9eNuK5lsssWJXUUAYHxB1Vb6boM= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3790.namprd11.prod.outlook.com (20.178.253.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Thu, 4 Jul 2019 11:38:09 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Thu, 4 Jul 2019 11:38:09 +0000 From: "Pascal Thubert (pthubert)" To: Carsten Bormann CC: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, V6 Ops List , 6man <6man@ietf.org> Thread-Topic: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs Thread-Index: AdUyXLsjbUS9G1zfTQuzwoWpAiUtYQ== Date: Thu, 4 Jul 2019 11:37:38 +0000 Deferred-Delivery: Thu, 4 Jul 2019 11:37:35 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1008::1d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9da4fbd7-7d9d-46b4-9ad7-08d7007416b6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3790; x-ms-traffictypediagnostic: MN2PR11MB3790: x-ms-exchange-purlcount: 10 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(39860400002)(346002)(396003)(13464003)(199004)(189003)(51444003)(7696005)(7736002)(2906002)(305945005)(68736007)(74316002)(6506007)(53546011)(81156014)(81166006)(8676002)(476003)(99286004)(6116002)(46003)(316002)(102836004)(486006)(86362001)(54906003)(186003)(14444005)(256004)(478600001)(8936002)(9686003)(25786009)(6306002)(66574012)(55016002)(4326008)(6916009)(76116006)(53936002)(52536014)(5660300002)(6246003)(71200400001)(14454004)(71190400001)(33656002)(6666004)(229853002)(66946007)(966005)(73956011)(66556008)(64756008)(66446008)(66476007)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3790; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jaSYomRLMZ0kvpYOJn7DXkDn3N6ioXhc4yQHC9vT1s2FqhrjOn5jKHEACWGzhWCexOEZAni6dqE2bjg3yPArQqFbSIZf+J7J8EjfzC4R6ny/CV7EBBn3ZvWt66NkqM4FWz9Tp74DCDRqzBEULIpjecqZk8zxLr5TbiGVhjqk55fBeJdttAnJGWpNVjBEEunZ3BpMj1WKg7QRU1ISUwLynP1cfoIHq1U0RZRYnuv7YLBlA5gq2DzERnXJUctFuVA/yEwGWWwWE8tcUezXPzaQ17Phvf2lT8yzERgbryg2N/LUf9/U2bTwHIlwjOr6FL971AxobC9MpPBKhtPacTD4NxhFZ0jjtkXfL1+sr21YSF++Bs3lzx31uG6yyA+Ozk9KfmbB4+FGEINU0oi6WvD2APEJ65zfcT4M3ER8tdup28o= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9da4fbd7-7d9d-46b4-9ad7-08d7007416b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2019 11:38:09.1787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3790 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 11:38:19 -0000 VGhpcyBpcyBhbGwgdmVyeSByaWdodCwgQ2Fyc3Rlbi4NCg0KDQo+IFJGQyA2Nzc1Lzg1MDUgb24g YSBuZXcgKGdyZWVuZmllbGQpIGZvbyAoYXMgaW4gSVAgb3ZlciBmb28pIGlzIHByZXR0eSBtdWNo IGENCj4gbm8tYnJhaW5lciwgaWYgdGhhdCBmb28gaGFzIHBvaW50cyB3aGVyZSB0aGUgNkxCUiBm dW5jdGlvbmFsaXR5IGlzIG5hdHVyYWxseQ0KPiBjZW50cmFsaXplZC4NCg0KTm8gYnJhaW5lciBp dCBpcywgYnV0IGZvciBMb3JlbnpvJ3MgaXNzdWVzIG9uIHN0YXRlIHByZXNlcnZhdGlvbiBvciBy ZWNvbnN0cnVjdGlvbiB1cG9uIHJvdXRlciByZWJvb3QuDQoNCj4gTm90IHNvIGVhc3kgZm9yIGJy b3duZmllbGQsIGkuZS4sIGluIG5ldHdvcmtzIHdoZXJlIGNsYXNzaWMgTkQgaXMgYWxyZWFkeSB1 c2VkIGluDQo+IHNvbWUgaG9zdHMgYW5kIHNvbWUgcm91dGVycy4gIOKAnEVmZmljaWVudCBOROKA nSAod2hpY2ggd2FzIGVzc2VudGlhbGx5IFJGQyA2Nzc1DQo+IGZvciBFdGhlcm5ldCBhbmQgdGh1 cyBhbHNvIHRyYWRpdGlvbmFsIFdpLUZpKSBtb3N0bHkgZGlkbuKAmXQgdGFrZSBvZmYgYXQgdGhl IHRpbWUNCj4gYmVjYXVzZSB3ZSBkaWRu4oCZdCBhcnRpY3VsYXRlIGEgY29oYWJpdGF0aW9uICji gJx0cmFuc2l0aW9u4oCdKSBzdHJhdGVneS4gIEnigJltIHN1cmUNCj4gd2UgY2FuIGRvIHRoYXQg aWYgd2UgcHV0IGEgbGl0dGxlIG1vcmUgZm9jdXMgb24gaXQsIGxlYWRpbmcgdG8gYW5vdGhlcg0K PiBzcGVjaWZpY2F0aW9uIHRoYXQgZGVzY3JpYmVzIGhvdyB0byBydW4gaW4gbWl4ZWQgY2xhc3Np Yy9lZmZpY2llbnQgTkQgbmV0d29ya3MuDQoNCkZvciBJIHN0YXJ0ZWQgdGhhdCBhdCA2bG8gYW5k IHRoZXJlIGlzIHRleHQgaW4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1pZXRmLTZsby1iYWNrYm9uZS1yb3V0ZXIgLCBlLmcuLCBpbiBzZWN0aW9uIDMuMi4gVGhl IGNvZXhpc3RlbmNlIGlzIGFsc28gZGlzY3Vzc2VkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC10aHViZXJ0LTZsby11bmljYXN0LWxvb2t1cCBidXQgYXQgc29tZSBwb2ludCBp dCBpcyBub3QgYSA2bG8gcHJvYmxlbSBhbnltb3JlIGFuZCB0aGF0IHdvcmsgc2hvdWxkIHJlYWxs eSBtb3ZlIHNvbWV3aGVyZSBlbHNlLiANCg0KQmVpbmcgbm9uLW1haW50ZW5hbmNlLCBpdCBzZWVt cyB0b28gZWFybHkgZm9yIDZNQU4uIElmIHNvIG1heWJlIHdlIHNob3VsZCBmb3JtIGEgc2hvcnQt bGl2ZWQgV0cgdG8gc29ydCBvdXQgdGhlIGlzc3VlcyByYWlzZWQgYnkgTG9yZW56bywgIHlvdXJz IChjb2V4aXN0ZW5jZSkgYW5kIG1pbmUgKGxpbWl0IHVzZSBvZiBicm9hZGNhc3QgLyBpbnRlcmZh Y2Ugd2l0aCBhIGZhYnJpYyBtYXBwaW5nIHNlcnZlciBhbmQgZG8gdW5pY2FzdCBsb29rdXAgd2hl biBwb3NzaWJsZSkuDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGFzY2FsDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQo+ IFNlbnQ6IGpldWRpIDQganVpbGxldCAyMDE5IDEzOjIyDQo+IFRvOiBQYXNjYWwgVGh1YmVydCAo cHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+DQo+IENjOiBNaWNoYWVsIFJpY2hhcmRzb24g PG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IDZsb0BpZXRmLm9yZzsgVjYgT3BzIExpc3QNCj4gPHY2 b3BzQGlldGYub3JnPjsgNm1hbiA8Nm1hbkBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFs2bG9d IEFkdm9jYXRpbmcgYSBnZW5lcmFsaXNhdGlvbiBvZiBSRkM4NTA1IHRvIG5vbi02bG8gTEFOcw0K PiANCj4gUkZDIDY3NzUvODUwNSBvbiBhIG5ldyAoZ3JlZW5maWVsZCkgZm9vIChhcyBpbiBJUCBv dmVyIGZvbykgaXMgcHJldHR5IG11Y2ggYQ0KPiBuby1icmFpbmVyLCBpZiB0aGF0IGZvbyBoYXMg cG9pbnRzIHdoZXJlIHRoZSA2TEJSIGZ1bmN0aW9uYWxpdHkgaXMgbmF0dXJhbGx5DQo+IGNlbnRy YWxpemVkLg0KPiANCj4gTm90IHNvIGVhc3kgZm9yIGJyb3duZmllbGQsIGkuZS4sIGluIG5ldHdv cmtzIHdoZXJlIGNsYXNzaWMgTkQgaXMgYWxyZWFkeSB1c2VkIGluDQo+IHNvbWUgaG9zdHMgYW5k IHNvbWUgcm91dGVycy4gIOKAnEVmZmljaWVudCBOROKAnSAod2hpY2ggd2FzIGVzc2VudGlhbGx5 IFJGQyA2Nzc1DQo+IGZvciBFdGhlcm5ldCBhbmQgdGh1cyBhbHNvIHRyYWRpdGlvbmFsIFdpRmkp IG1vc3RseSBkaWRu4oCZdCB0YWtlIG9mZiBhdCB0aGUgdGltZQ0KPiBiZWNhdXNlIHdlIGRpZG7i gJl0IGFydGljdWxhdGUgYSBjb2hhYml0YXRpb24gKOKAnHRyYW5zaXRpb27igJ0pIHN0cmF0ZWd5 LiAgSeKAmW0gc3VyZQ0KPiB3ZSBjYW4gZG8gdGhhdCBpZiB3ZSBwdXQgYSBsaXR0bGUgbW9yZSBm b2N1cyBvbiBpdCwgbGVhZGluZyB0byBhbm90aGVyDQo+IHNwZWNpZmljYXRpb24gdGhhdCBkZXNj cmliZXMgaG93IHRvIHJ1biBpbiBtaXhlZCBjbGFzc2ljL2VmZmljaWVudCBORCBuZXR3b3Jrcy4N Cj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IA0KPiA+IE9uIEp1bCA0LCAyMDE5LCBhdCAx MjoyOCwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPg0KPiB3 cm90ZToNCj4gPg0KPiA+IEhlbGxvIEJyaWFuOg0KPiA+DQo+ID4gWWVzLCBJJ20gd2lsbGluZyB0 byBtYWtlIHRoZSBjYXNlLg0KPiA+DQo+ID4gVGhlcmUgYXJlIGEgbnVtYmVyIG9mIHJlYXNvbnMg dG8gZW5hYmxlIGEgcmVnaXN0cmF0aW9uIG1ldGhvZCBvbiBiZXlvbmQNCj4gNmxvIG5ldHdvcmtz Og0KPiA+IC0gSXQgaXMgdXNlZnVsIGluIHdpcmVsZXNzIGluIGdlbmVyYWwgYmVjYXVzZSBpdCBh ZGRyZXNzZXMgbm9uLXRyYW5zaXQNCj4gPiBtdWx0aXBvaW50IGxpbmtzIChzZWUNCj4gPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aHViZXJ0LTZtYW4taXB2Ni1vdmVy LXdpcmVsZXNzDQo+ID4gLykgYW5kIE5CTUEgTUwtc3VibmV0cw0KPiA+IC0gaXQgaXMgdXNlZnVs IGluIHBhcnRpY3VsYXIgaW4gV2ktRmkgYmVjYXVzZSBpdCByZWR1Y2VzIHRoZSBuZWVkIGZvciBi cm9hZGNhc3QNCj4gcXVpdGUgZHJhbWF0aWNhbGx5Lg0KPiA+IC0gSXQgaXMgdXNlZnVsIGluIGEg c3dpdGNoZWQgZmFicmljIHRvIG1haW50YWluIGFuIGFjY3VyYXRlIHN0YXRlIGluDQo+ID4gdGhl IG92ZXJsYXkgbWFwcGluZyBzZXJ2ZXIgKHNlZQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtNmxvLXVuaWNhc3QtbG9va3VwLykNCj4gPiAtIEl0IGlz IHVzZWZ1bCBpbiBhIHNpdHVhdGlvbiBvZiBob3N0IG1vYmlsaXR5IGluIGdlbmVyYWwsIChzZWUg dGhlDQo+ID4gZGlzY3Vzc2lvbiBpbg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXJpZnQtcmlmdC0wNiNzZWN0aW9uLTUuMy4zICkNCj4gPiAtIEl0IGlzIHVzZWZ1 bCBmb3Igcm91dGVycyB3aXRoIGhhcmR3YXJlIGFzc2lzdCBmb3J3YXJkaW5nIHRvIGF2b2lkDQo+ ID4gdGhlIHB1bnRpbmcgZGFuY2UgYW5kIGRyb3BwaW5nIG9mIHBhY2tldHMNCj4gPiAtIEl0IHBy b3ZpZGVzIFNBVkkgcHJvcGVydGllcyB3aXRoIGEgd29ya2FibGUgU2VjdXJlIE5EIChzZWUNCj4g PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZsby1hcC1uZC8p DQo+ID4gLSBJdCBwcm92aWRlcyBhbiBhYnN0cmFjdCBpbnRlcmZhY2UgdG8gdGhlIHJvdXRlciB0 byBnZXQgcm91dGluZw0KPiA+IHNlcnZpY2VzIChhbHJlYWR5IHVzZWQgd2l0aCBSSUZULCBSUEws IHNlZQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9s bC11bmF3YXJlLWxlYXZlcy8sIGFuZA0KPiA+IE5EIHByb3h5LCBzZWUNCj4gPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZsby1iYWNrYm9uZS1yb3V0ZXIvKQ0K PiA+IC0gSXQgc29sdmVzIGEgbnVtYmVyIG9mIHByb2JsZW1zIGluY2x1ZGluZyBKZW4ncywgYnV0 IGFsc28gc2xlZXBpbmcgZGV2aWNlcyBvbg0KPiBub24tNmxvIG5ldHdvcmtzLCByZW1vdGUgRE9T IGFnYWluc3Qgcm91dGVyIGFuZCBORCBjYWNoZSwgYW5kIG1vcmUuDQo+ID4NCj4gPiBBbGwgaW4g YWxsIEkgc2VlIGl0IGFzIGEgbXVjaCBuZWVkZWQgbW9kZXJuaXphdGlvbiBvZiBORCB0byBjb3Bl IHdpdGggdGhlDQo+IGV2b2x1dGlvbnMgb2YgdGhlIG5ldHdvcmsgKElPVCwgV2ktRmkgYW5kIG92 ZXJsYXlzKSBhbmQgd2l0aCB0aGUgbmV3IG5lZWRzDQo+IGFuZCBiZWhhdmlvcnMgKGluc3RhbnQg Y29ubmVjdGl2aXR5LCBmYXN0IHJvYW1pbmcpLg0KPiA+DQo+ID4gQWxsIHRoZSBiZXN0LA0KPiA+ DQo+ID4gUGFzY2FsDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogNmxvIDw2bG8tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmlj aGFyZHNvbg0KPiA+PiBTZW50OiBqZXVkaSA0IGp1aWxsZXQgMjAxOSAwMjo1OA0KPiA+PiBUbzog NmxvQGlldGYub3JnOyBWNiBPcHMgTGlzdCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuIDw2bWFuQGll dGYub3JnPg0KPiA+PiBTdWJqZWN0OiBSZTogWzZsb10gTkQgY2FjaGUgZW50cmllcyBjcmVhdGlv biBvbiBmaXJzdC1ob3Agcm91dGVycw0KPiA+Pg0KPiA+Pg0KPiA+PiBCcmlhbiBFIENhcnBlbnRl ciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gPj4+PiBJ4oCZbSBpbnRl cmVzdGVkIHRvIGhhdmUgYSBwYXJhbGxlbCBkaXNjdXNzaW9uIG9uIHdoZXJlIFJGQyA4NTA1IGNh bg0KPiA+Pj4+IG5vdCBhcHBseS4gSW4gdGhlIHByb2R1Y3RzIGFuZCB1c2UgY2FzZXMgSeKAmW0g YXdhcmUgb2YsIGl0IGNvdWxkLA0KPiA+Pj4+IHNpbmNlIHdlIGFyZSBhY3R1YWxseSBmYWtpbmcg aXQgYnkgc25vb3BpbmcgTkQgYW5kIERIQ1AgdG8gYWNoaWV2ZQ0KPiA+Pj4+IHNpbWlsYXIgYnV0 IGxlc3MgYWNjdXJhdGUgcmVzdWx0cy4NCj4gPj4NCj4gPj4+IFNvIGlmIHlvdSBhcmUgYWR2b2Nh dGluZyBhIGdlbmVyYWxpc2F0aW9uIG9mIFJGQzg1MDUgdG8gbm9uLTZsbw0KPiA+Pj4gTEFOcywg dGhhdCdzIGNlcnRhaW5seSBhIGRpc2N1c3Npb24gd2UgY291bGQgaGF2ZSwgSU1ITy4NCj4gPj4N Cj4gPj4gSSB0aGluayB0aGF0IGl0IGNvdWxkIGJlIGFwcGxpZWQgaW4gc2l0dWF0aW9ucyBvZiBz ZXJ2ZXJzLCBzdWNoIGFzDQo+ID4+IGRhdGEgY2VudGVycyB3aGVyZSB0aGVyZSBhcmUgbXVsdGlw bGUgdGVuYW50cy4gKE1hbnkgVk0NCj4gPj4gaW5mcmFzdHJ1Y3R1cmVzIGhhdmUgc2hhcmVkIGZy b250LWVuZCBuZXR3b3JrcykNCj4gPj4NCj4gPj4gSSB0aGluayB0aGF0IHRlbXBvcmFyeSBhZGRy ZXNzZXNzIGFyZSBub3QgYSBmZWF0dXJlIGluIHNvbWUgb2YgdGhvc2UNCj4gPj4gZGVwbG95bWVu dHMgdGhhdCBldmVyeW9uZSB3YW50cywgYW5kIHRodXMgaGF2aW5nIGEgcmVnaXN0cmF0aW9uDQo+ ID4+IHN5c3RlbSBpcyBhIGZlYXR1cmUuDQo+ID4+DQo+ID4+IFRoaXMgZG9lcyBub3Qgc29sdmUg dGhlIHNtYXJ0cGhvbmUgb24gbmV3IFdJRkkgaXNzdWUsIHdoaWNoIGlzIGENCj4gPj4gZGlmZmVy ZW50IHNpdHVhdGlvbiBjb21wbGV0ZWx5Lg0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBdICAgICAgICAg ICAgICAgTmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEgICAgICAgICAgICAgICAgIHwgaXB2NiBtZXNo IG5ldHdvcmtzIFsNCj4gPj4gXSAgIE1pY2hhZWwgUmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3 YXJlIFdvcmtzICAgICAgICB8ICAgIElvVCBhcmNoaXRlY3QgICBbDQo+ID4+IF0gICAgIG1jckBz YW5kZWxtYW4uY2EgIGh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyAgICAgICAgfCAgIHJ1Ynkgb24g cmFpbHMgICAgWw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA2bG8gbWFpbGluZyBsaXN0DQo+ID4gNmxvQGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG8NCj4gPg0KPiA+DQoNCg== From nobody Thu Jul 4 05:39:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCE0120655; Thu, 4 Jul 2019 05:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 7B4_CBYo4zXC; Thu, 4 Jul 2019 05:39:03 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157801205CF; Thu, 4 Jul 2019 05:39:03 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id 65so4790494oid.13; Thu, 04 Jul 2019 05:39:03 -0700 (PDT) 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=+iDzL6OY+gCS133+hfm0hUgDEHBcnVcar3iHciLwlYA=; b=QDbamxiyHopDDXilwT0Rk3gobW6rqUvsoMXIlAqqYWVzLP8eRUFvfDQATYhfNLJiXZ iQYuk3cSanlNs0qX78VqaBXsiYSDZfyH5E4d526LNHGr3CqDbizqy4m14qvzcmfgQ6j8 Ruofv0aivexI46FMa/zZwffHQGZCcTHjkaqmZqgJVEQ6hdbSL+DslaLFx5/oQXFLKP6I 2uGPzOR4OkhSZ9UjoeQelD/P43D0kSk+Kg/VcGblYknBiWMOwOao/TLxYvq1p2v43bRz d9Uy+LZKBp9gYyX6sNfeHsx+lOTSv54WGqy8bkBh/JwNRkJc5SrPYhSCYBN0kf9VC4TY 96WQ== 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=+iDzL6OY+gCS133+hfm0hUgDEHBcnVcar3iHciLwlYA=; b=oLB15N05aeRkdAKg/T7Zil8uWLXLGCbR/BziU72jL4+9v7vG6reG643WDhOp/LPf/C 2/5utk2WmMyfjEtSC/RPb3hdt/AQeRYmh5DU29WliJ2Tfhg9uHr0mK0k0BhOBQcvMxf3 bqvJwkYz/aRBHlE2+b45kMWHH6iTslRBNponcmN2o6gss/vRRaXWVEhfcXtOB+Ebuzvf 6qz0FL12nWUDsoQNi4+CkZoIja2BRvp/hkUFAHMfy4IcLYSuJ+AvZri9+IFDOa7uckx2 WIAWVYYRHxy8tcCiD5qE7HPfFR/vND6YIGCM2Uo5UNffJI6tJ1plGASeVNMhhQ/bsnsP SUEw== X-Gm-Message-State: APjAAAVb+6SZcMKYt6m2xd2pvTgLE/intUacxk8WWgq487Cptt1bTDpO 34riK4Xpk2K29GQTkAMoVJcJu7fAFyJz09PS0Oc= X-Google-Smtp-Source: APXvYqyKkLqUjj9P7detPoef2jilRc06aGtEtSzh390uwxZuNGBskoQQ5YGRsgAAJpPN8inuLqCrvX4Bmw8cps09peA= X-Received: by 2002:aca:d511:: with SMTP id m17mr1749007oig.54.1562243942264; Thu, 04 Jul 2019 05:39:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Thu, 4 Jul 2019 22:38:50 +1000 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Carsten Bormann , Michael Richardson , V6 Ops List , 6man <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Content-Type: multipart/alternative; boundary="0000000000003b33ac058cda4333" Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 12:39:06 -0000 --0000000000003b33ac058cda4333 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu., 4 Jul. 2019, 21:38 Pascal Thubert (pthubert), wrote: > This is all very right, Carsten. > > > > RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty > much a > > no-brainer, if that foo has points where the 6LBR functionality is > naturally > > centralized. > > No brainer it is, but for Lorenzo's issues on state preservation or > reconstruction upon router reboot. > I think that can be overcome. I've been thinking for a while how to build something like this using existing protocols and host or router behaviour. Fundamentally two stages: - collect nodes' link local addresses - query nodes' for their other GUA or ULA addresses Collecting nodes LLAs can be done via collecting source addresses from node emitted RSess and/or MLDv2 reports. Once they've been collected, then nodes are unicast queried by routers for their other addresses via either ICMPv6 Node Information queries or Inverse ND. (There is currently a limitation with ICMPv6 NI that it doesn't report temporary addresses for security reasons. That could be lifted by e.g. saying that all addressed including temporaries are reported if the NI query source address is an LLA i.e. limited to a query from an on-link source, or both LLA source and that the LLA is that of a known default router.) A new node on the link effectively announces its LLA to existing routers via RS and MLDv2 joins for solicited node groups for its addresses (and other multicast groups it may join). If a node configures a new address, it joins the address's Solicited Node Multicast group. Routers use that as a signal to unicast query the node it for its updated address list to discover the new address. (DAD is another possible way for routers to collect new address information, however I think Ericsson have some IPR over that idea, and it also doesn't work for anycast addresses, because DADs aren't performed for them). Routers detect when an address disappears via standard ND NUD. A new router on a link can collect existing nodes' LLAs via a general MLD query, as it does anyway to collect the set of multicast groups on the link. Once the new router has that set of LLAs, it then unicast queries the nodes for their other addresses. Perhaps a bit of pedantry, however if nodes are "Neighbours", since we now have possibly multiple addresses per node/neighbour, ND isn't really discovering neighbours, it's actually discovering the presence of addresses, not "neighbours". Address Discovery or Address Presence Discovery would perhaps be a more accurate name for this function. Regards, Mark. > > Not so easy for brownfield, i.e., in networks where classic ND is > already used in > > some hosts and some routers. =E2=80=9CEfficient ND=E2=80=9D (which was= essentially RFC > 6775 > > for Ethernet and thus also traditional Wi-Fi) mostly didn=E2=80=99t tak= e off at > the time > > because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransitio= n=E2=80=9D) strategy. > I=E2=80=99m sure > > we can do that if we put a little more focus on it, leading to another > > specification that describes how to run in mixed classic/efficient ND > networks. > > For I started that at 6lo and there is text in > https://datatracker.ietf.org/doc/html/draft-ietf-6lo-backbone-router , > e.g., in section 3.2. The coexistence is also discussed in > https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup but at some > point it is not a 6lo problem anymore and that work should really move > somewhere else. > > Being non-maintenance, it seems too early for 6MAN. If so maybe we should > form a short-lived WG to sort out the issues raised by Lorenzo, yours > (coexistence) and mine (limit use of broadcast / interface with a fabric > mapping server and do unicast lookup when possible). > > All the best, > > Pascal > > > -----Original Message----- > > From: Carsten Bormann > > Sent: jeudi 4 juillet 2019 13:22 > > To: Pascal Thubert (pthubert) > > Cc: Michael Richardson ; 6lo@ietf.org; V6 Ops > List > > ; 6man <6man@ietf.org> > > Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LA= Ns > > > > RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty > much a > > no-brainer, if that foo has points where the 6LBR functionality is > naturally > > centralized. > > > > Not so easy for brownfield, i.e., in networks where classic ND is > already used in > > some hosts and some routers. =E2=80=9CEfficient ND=E2=80=9D (which was= essentially RFC > 6775 > > for Ethernet and thus also traditional WiFi) mostly didn=E2=80=99t take= off at > the time > > because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransitio= n=E2=80=9D) strategy. > I=E2=80=99m sure > > we can do that if we put a little more focus on it, leading to another > > specification that describes how to run in mixed classic/efficient ND > networks. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) < > pthubert@cisco.com> > > wrote: > > > > > > Hello Brian: > > > > > > Yes, I'm willing to make the case. > > > > > > There are a number of reasons to enable a registration method on beyo= nd > > 6lo networks: > > > - It is useful in wireless in general because it addresses non-transi= t > > > multipoint links (see > > > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireles= s > > > /) and NBMA ML-subnets > > > - it is useful in particular in Wi-Fi because it reduces the need for > broadcast > > quite dramatically. > > > - It is useful in a switched fabric to maintain an accurate state in > > > the overlay mapping server (see > > > https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/) > > > - It is useful in a situation of host mobility in general, (see the > > > discussion in > > > https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 ) > > > - It is useful for routers with hardware assist forwarding to avoid > > > the punting dance and dropping of packets > > > - It provides SAVI properties with a workable Secure ND (see > > > https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/) > > > - It provides an abstract interface to the router to get routing > > > services (already used with RIFT, RPL, see > > > https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and > > > ND proxy, see > > > https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/) > > > - It solves a number of problems including Jen's, but also sleeping > devices on > > non-6lo networks, remote DOS against router and ND cache, and more. > > > > > > All in all I see it as a much needed modernization of ND to cope with > the > > evolutions of the network (IOT, Wi-Fi and overlays) and with the new > needs > > and behaviors (instant connectivity, fast roaming). > > > > > > All the best, > > > > > > Pascal > > > > > >> -----Original Message----- > > >> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Michael Richardson > > >> Sent: jeudi 4 juillet 2019 02:58 > > >> To: 6lo@ietf.org; V6 Ops List ; 6man <6man@ietf.org> > > >> Subject: Re: [6lo] ND cache entries creation on first-hop routers > > >> > > >> > > >> Brian E Carpenter wrote: > > >>>> I=E2=80=99m interested to have a parallel discussion on where RFC = 8505 can > > >>>> not apply. In the products and use cases I=E2=80=99m aware of, it = could, > > >>>> since we are actually faking it by snooping ND and DHCP to achieve > > >>>> similar but less accurate results. > > >> > > >>> So if you are advocating a generalisation of RFC8505 to non-6lo > > >>> LANs, that's certainly a discussion we could have, IMHO. > > >> > > >> I think that it could be applied in situations of servers, such as > > >> data centers where there are multiple tenants. (Many VM > > >> infrastructures have shared front-end networks) > > >> > > >> I think that temporary addressess are not a feature in some of those > > >> deployments that everyone wants, and thus having a registration > > >> system is a feature. > > >> > > >> This does not solve the smartphone on new WIFI issue, which is a > > >> different situation completely. > > >> > > >> -- > > >> ] Never tell me the odds! | ipv6 mesh > networks [ > > >> ] Michael Richardson, Sandelman Software Works | IoT > architect [ > > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > > _______________________________________________ > > > 6lo mailing list > > > 6lo@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lo > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000003b33ac058cda4333 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu., 4 Jul. 2019, 21:38 Pascal Thubert (pthubert),= <pthubert@cisco.com> wrote:
This is all very right, Carsten.


> RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty = much a
> no-brainer, if that foo has points where the 6LBR functionality is nat= urally
> centralized.

No brainer it is, but for Lorenzo's issues on state preservation or rec= onstruction upon router reboot.

I think that can be overcome.

I've been thinking for a while ho= w to build something like this using existing protocols and host or router = behaviour.

Fundamentally= two stages:

- collect n= odes' link local addresses

- query nodes' for their other GUA or ULA addresses

Collecting nodes LLAs can be done vi= a collecting source addresses from node emitted RSess and/or MLDv2 reports.=

Once they've been c= ollected, then nodes are unicast queried by routers for their other address= es via either ICMPv6 Node Information queries or Inverse ND.

(There is currently a limitation with= ICMPv6 NI that it doesn't report temporary addresses for security reas= ons. That could be lifted by e.g. saying that all addressed including tempo= raries are reported if the NI query source address is an LLA i.e. limited t= o a query from an on-link source, or both LLA source and that the LLA is th= at of a known default router.)

A new node on the link effectively announces its LLA to existing rou= ters via RS and MLDv2 joins for solicited node groups for its addresses (an= d other multicast groups it may join).

If a node configures a new address, it joins the address'= ;s Solicited Node Multicast group. Routers use that as a signal to unicast = query the node it for its updated address list to discover the new address.=

(DAD is another possibl= e way for routers to collect new address information, however I think Erics= son have some IPR over that idea, and it also doesn't work for anycast = addresses, because DADs aren't performed for them).

Routers detect when an address disappears v= ia standard ND NUD.

A ne= w router on a link can collect existing nodes' LLAs via a general MLD q= uery, as it does anyway to collect the set of multicast groups on the link.= Once the new router has that set of LLAs, it then unicast queries the node= s for their other addresses.


Perhaps a bit of pedantry, however if node= s are "Neighbours", since we now have possibly multiple addresses= per node/neighbour, ND isn't really discovering neighbours, it's a= ctually discovering the presence of addresses, not "neighbours". = Address Discovery or Address Presence Discovery would perhaps be a more acc= urate name for this function.

Regards,
Mark.


=

> Not so easy for brownfield, i.e., in networks where classic ND is alre= ady used in
> some hosts and some routers.=C2=A0 =E2=80=9CEfficient ND=E2=80=9D (whi= ch was essentially RFC 6775
> for Ethernet and thus also traditional Wi-Fi) mostly didn=E2=80=99t ta= ke off at the time
> because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransiti= on=E2=80=9D) strategy.=C2=A0 I=E2=80=99m sure
> we can do that if we put a little more focus on it, leading to another=
> specification that describes how to run in mixed classic/efficient ND = networks.

For I started that at 6lo and there is text in https://datatracker.ietf.org/doc/html/= draft-ietf-6lo-backbone-router , e.g., in section 3.2. The coexistence = is also discussed in https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup but at = some point it is not a 6lo problem anymore and that work should really move= somewhere else.

Being non-maintenance, it seems too early for 6MAN. If so maybe we should f= orm a short-lived WG to sort out the issues raised by Lorenzo,=C2=A0 yours = (coexistence) and mine (limit use of broadcast / interface with a fabric ma= pping server and do unicast lookup when possible).

All the best,

Pascal

> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>
> Sent: jeudi 4 juillet 2019 13:22
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>= ;
> Cc: Michael Richardson <mcr+ietf@sandelman.ca&g= t;; 6lo@ietf.org; V6 Ops List
> <v6ops@ietf.org>; 6man <6man@ietf.org>= ;
> Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo L= ANs
>
> RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty = much a
> no-brainer, if that foo has points where the 6LBR functionality is nat= urally
> centralized.
>
> Not so easy for brownfield, i.e., in networks where classic ND is alre= ady used in
> some hosts and some routers.=C2=A0 =E2=80=9CEfficient ND=E2=80=9D (whi= ch was essentially RFC 6775
> for Ethernet and thus also traditional WiFi) mostly didn=E2=80=99t tak= e off at the time
> because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransiti= on=E2=80=9D) strategy.=C2=A0 I=E2=80=99m sure
> we can do that if we put a little more focus on it, leading to another=
> specification that describes how to run in mixed classic/efficient ND = networks.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
> > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) <pthubert@cisco.com>
> wrote:
> >
> > Hello Brian:
> >
> > Yes, I'm willing to make the case.
> >
> > There are a number of reasons to enable a registration method on = beyond
> 6lo networks:
> > - It is useful in wireless in general because it addresses non-tr= ansit
> > multipoint links (see
> > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless
> > /) and NBMA ML-subnets
> > - it is useful in particular in Wi-Fi because it reduces the need= for broadcast
> quite dramatically.
> > - It is useful in a switched fabric to maintain an accurate state= in
> > the overlay mapping server (see
> > ht= tps://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/)
> > - It is useful in a situation of host mobility in general, (see t= he
> > discussion in
> > htt= ps://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 )
> > - It is useful for routers with hardware assist forwarding to avo= id
> > the punting dance and dropping of packets
> > - It provides SAVI properties with a workable Secure ND (see
> > https://datatr= acker.ietf.org/doc/draft-ietf-6lo-ap-nd/)
> > - It provides an abstract interface to the router to get routing<= br> > > services (already used with RIFT, RPL, see
> > http= s://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and
> > ND proxy, see
> > http= s://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/)
> > - It solves a number of problems including Jen's, but also sl= eeping devices on
> non-6lo networks, remote DOS against router and ND cache, and more. > >
> > All in all I see it as a much needed modernization of ND to cope = with the
> evolutions of the network (IOT, Wi-Fi and overlays) and with the new n= eeds
> and behaviors (instant connectivity, fast roaming).
> >
> > All the best,
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: 6lo <6lo-bounces@ietf.org> On Be= half Of Michael Richardson
> >> Sent: jeudi 4 juillet 2019 02:58
> >> To: 6lo@ietf.org; V6 Ops List <v6ops@ietf.= org>; 6man <6man@ietf.org>
> >> Subject: Re: [6lo] ND cache entries creation on first-hop rou= ters
> >>
> >>
> >> Brian E Carpenter <brian.e.carpenter@g= mail.com> wrote:
> >>>> I=E2=80=99m interested to have a parallel discussion = on where RFC 8505 can
> >>>> not apply. In the products and use cases I=E2=80=99m = aware of, it could,
> >>>> since we are actually faking it by snooping ND and DH= CP to achieve
> >>>> similar but less accurate results.
> >>
> >>> So if you are advocating a generalisation of RFC8505 to n= on-6lo
> >>> LANs, that's certainly a discussion we could have, IM= HO.
> >>
> >> I think that it could be applied in situations of servers, su= ch as
> >> data centers where there are multiple tenants. (Many VM
> >> infrastructures have shared front-end networks)
> >>
> >> I think that temporary addressess are not a feature in some o= f those
> >> deployments that everyone wants, and thus having a registrati= on
> >> system is a feature.
> >>
> >> This does not solve the smartphone on new WIFI issue, which i= s a
> >> different situation completely.
> >>
> >> --
> >> ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never= tell me the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| ipv6 mesh networks [
> >> ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
> >> ]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [
> >
> > _______________________________________________
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailma= n/listinfo/6lo
> >
> >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www= .ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0000000000003b33ac058cda4333-- From nobody Thu Jul 4 06:24:53 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD101201E3; Thu, 4 Jul 2019 06:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=kVlgWPMq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eQBQmO7L 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 yupCnM5s1yH3; Thu, 4 Jul 2019 06:24:39 -0700 (PDT) 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 19C4712001A; Thu, 4 Jul 2019 06:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43246; q=dns/txt; s=iport; t=1562246678; x=1563456278; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vn55AmgHY8CGZytY7Ze0QHr8xlOtjRzL50WD/Q1Jglg=; b=kVlgWPMqswSczD6dGhMAIpJuo8kIWVHh8XvgXtB/HSSyMc6oYatvs5bt kSeTzpKXNzIfufgXOzUvP6684NqR/2zk17YnWW2tMA9sjxsgrzFseZk3j DznLMeeK98CVJ8j3NxvuNQq3AiE9ZsGhppQS1ntzexs5sZz/Xp9UzWQcR 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AHUUkuR0OQhX8NVkKsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAAAh/R1d/5JdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4EVL1ADalUgBAsohByDRwOOSYJbiU2NeYJSA1AECQEBAQw?= =?us-ascii?q?BARgBCgoCAQGBS4J1AheCFSM4EwEDAQEEAQECAQVtijcMhUoBAQEBAgEBARA?= =?us-ascii?q?RChMBASwGBQEEBwQCAQYCEQQBAQEgAQYDAgICHwYLFAkIAQEEDgUIGoMBgR1?= =?us-ascii?q?NAw4PAQIMiwGQYAKBOIhgcYEygnkBAQWBMgETQYMODQuCEgmBNIRyhm0XgUA?= =?us-ascii?q?/gRFGgU5QLj6BBIEWRwEBAgEBgTYBEBgrCQiCTDKCJot1JCCCMYR9I4hAjT9?= =?us-ascii?q?ACQKCF4ZWhGuET4QOl3iUb4FzjgkCBAIEBQIOAQEFgWchgVhwFTuCbAmCOIM?= =?us-ascii?q?dVIUUhT9yAQGBJ4sZASUEgigBAQ?= X-IronPort-AV: E=Sophos;i="5.63,451,1557187200"; d="scan'208,217";a="588632308" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jul 2019 13:24:37 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x64DObpV008571 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jul 2019 13:24:37 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 08:24:36 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 09:24:31 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 4 Jul 2019 08:24:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vn55AmgHY8CGZytY7Ze0QHr8xlOtjRzL50WD/Q1Jglg=; b=eQBQmO7L5+HOkjCQNrbz/d36klm4HcuTpTvzA6r/c+mgq9EDxd/vwwf2ass18kln7Bgd8XGRK8k4nvGhAcDshZl9IU1oZWw7gZrVjn4RcKH5GK3vlMcX0YjuzEF0MLu9ajqn3WArVjpscO/e4PFJRetOpG4gx7mAwVuSbTJvzFQ= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4494.namprd11.prod.outlook.com (52.135.39.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Thu, 4 Jul 2019 13:10:10 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Thu, 4 Jul 2019 13:10:10 +0000 From: "Pascal Thubert (pthubert)" To: Mark Smith CC: Carsten Bormann , Michael Richardson , V6 Ops List , 6man <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs Thread-Index: AdUyXLsjbUS9G1zfTQuzwoWpAiUtYQACLMYAAAC/GgA= Date: Thu, 4 Jul 2019 13:09:42 +0000 Deferred-Delivery: Thu, 4 Jul 2019 13:08:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1008::1d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ab4a92f1-d375-4911-11c9-08d70080f1c8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4494; x-ms-traffictypediagnostic: MN2PR11MB4494: x-ms-exchange-purlcount: 13 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(396003)(136003)(366004)(376002)(13464003)(189003)(199004)(51444003)(5024004)(52536014)(14444005)(66574012)(73956011)(86362001)(66946007)(6246003)(256004)(66556008)(66476007)(790700001)(6116002)(6436002)(64756008)(55016002)(76116006)(446003)(99286004)(53936002)(14454004)(66446008)(236005)(606006)(6916009)(186003)(6306002)(9686003)(54896002)(7736002)(74316002)(966005)(229853002)(486006)(8936002)(5660300002)(316002)(4326008)(478600001)(1411001)(54906003)(81166006)(2906002)(81156014)(53546011)(7696005)(71190400001)(6666004)(46003)(6506007)(68736007)(476003)(102836004)(76176011)(33656002)(8676002)(25786009)(11346002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4494; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yQ13otWxhTzBjwtUAKBr6cDCOH1JdYS0B68ffuNduJx6jq3FdKeWJUEcByUi4qn8WtaDGuHdWdR4bUBoTLTlC7ChY9MaTO+cqDbjyUVpGXGVgefc3ADoHz2qXxi3WvEhbPvEqyDTE4viMi06y15iFfXHfXuEzWU09KwmbKw+6Bx0ZbkQk0gWKSAqgP5VhnBtThZcYXq2A+pltjXsaSLnI+rkDRpWzwPvUgvFCMJhnJIHpN6QE/L8W9UyTCt7bNgVjB7dlUfI86EYIcyEXCKMVcOcXWgSnLbW5yFhXWdhehstpY5VeendqpakAFYK3QL/RnejZQfEWnTnTL+RCahChcH535AIKd2dMfUgd/uYVd8IuQS0k+1tOg0gwzyM8s34OoQw84d8UHWbZnCNJUGUhAbw3PLlGQoT8YdCtLBAMfw= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565F85F6E989972B92045CBD8FA0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ab4a92f1-d375-4911-11c9-08d70080f1c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2019 13:10:10.6400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4494 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 13:24:43 -0000 --_000_MN2PR11MB3565F85F6E989972B92045CBD8FA0MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWFyazoNCg0KVGhlcmUgYXJlIGEgbnVtYmVyIG9mIHRoaW5ncyAgdGhhdCB0aGUgcm91 dGVyIHdvdWxkIGxpa2UgdG8ga25vdyBpbiB0aGUgcHJvY2VzczoNCg0KICAqICAgQSBzZW5zZSBv ZiBsaWZldGltZTsgaG93IGxvbmcgc2hvdWxkIHRoZSByb3V0ZXIvTDNBUCBleHBlY3QgdGhhdCB0 aGUgYWRkcmVzcyB3aWxsIGJlIHVzZWQ7IGF0IHRpbWUgb3V0LCB0aGUgcm91dGVyIGNhbiBjbGVh biB1cCB0aGUgc3RhdGUuDQogICogICBBIHNlbnNlIG9mIG9yZGVyOyBpZiBhIHdpcmVsZXNzIG5v ZGUgbW92ZXMgcmFwaWRseSBmcm9tIGEgTDNBUCB0byB0aGUgbmV4dCwgb3IgYSBWTSBtb3ZlcyBy YXBpZGx5IGZyb20gYSBzZXJ2ZXIgdG8gdGhlIG5leHQsIHdoaWNoIGlzIHRoZSBtb3N0IHJlY2Vu dCBwb2ludCBvZiBhdHRhY2htZW50DQogICogICBBIHNlbnNlIG9mIG93bmVyc2hpcDsgaWYgdGhl IHJvdXRlciBtYWludGFpbnMgYSBzdGF0ZSBhYm91dCB0aGUgYWRkcmVzcyBmb3IgYSByZXF1ZXN0 ZWQgbGlmZXRpbWUsIHRoZW4gYSBwcm9vZiBvZiBvd25lcnNoaXAgY2FuIGJlIGF0dGFjaGVkLCBz byBvbmx5IHRoZSBvd25lciBvZiB0aGUgYWRkcmVzcyBjYW4gbW9kaWZ5IHRoZSBzdGF0ZSAoU0FW SSkNCiAgKiAgIEEgc2Vuc2Ugb2Ygc2VydmljZTsgd2hhdCBzaG91bGQgdGhlIHJvdXRlciBkbyB3 aXRoIHRoYXQgYWRkcmVzcz8gRXhhbXBsZXMgdGhhdCBjb21lIHRvIG1pbmQgYXJlIGluamVjdCBp biBhIHJvdXRpbmcgcHJvdG9jb2wsIHBsYXkgc2xlZXBpbmcgcHJveHkgb3IgTkQgcHJveHkuDQoN Ckl0IGRvZXMgbm90IHRha2UgbmV3IG1lc3NhZ2VzIGJ1dCBhIG5ldyBvcHRpb24gaXMgbmVlZGVk IHRvIHByb3ZpZGUgYWxsIHRoYXQgaW5mb3JtYXRpb24uDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGFz Y2FsDQoNCkZyb206IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+DQpTZW50OiBq ZXVkaSA0IGp1aWxsZXQgMjAxOSAxNDozOQ0KVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkg PHB0aHViZXJ0QGNpc2NvLmNvbT4NCkNjOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz47 IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgVjYgT3BzIExpc3Qg PHY2b3BzQGlldGYub3JnPjsgNm1hbiA8Nm1hbkBpZXRmLm9yZz47IDZsb0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFs2bG9dIEFkdm9jYXRpbmcgYSBnZW5lcmFsaXphdGlvbiBvZiBSRkM4NTA1IHRv IG5vbi02bG8gTEFOcw0KDQoNCk9uIFRodS4sIDQgSnVsLiAyMDE5LCAyMTozOCBQYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpLCA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNj by5jb20+PiB3cm90ZToNClRoaXMgaXMgYWxsIHZlcnkgcmlnaHQsIENhcnN0ZW4uDQoNCg0KPiBS RkMgNjc3NS84NTA1IG9uIGEgbmV3IChncmVlbmZpZWxkKSBmb28gKGFzIGluIElQIG92ZXIgZm9v KSBpcyBwcmV0dHkgbXVjaCBhDQo+IG5vLWJyYWluZXIsIGlmIHRoYXQgZm9vIGhhcyBwb2ludHMg d2hlcmUgdGhlIDZMQlIgZnVuY3Rpb25hbGl0eSBpcyBuYXR1cmFsbHkNCj4gY2VudHJhbGl6ZWQu DQoNCk5vIGJyYWluZXIgaXQgaXMsIGJ1dCBmb3IgTG9yZW56bydzIGlzc3VlcyBvbiBzdGF0ZSBw cmVzZXJ2YXRpb24gb3IgcmVjb25zdHJ1Y3Rpb24gdXBvbiByb3V0ZXIgcmVib290Lg0KDQpJIHRo aW5rIHRoYXQgY2FuIGJlIG92ZXJjb21lLg0KDQpJJ3ZlIGJlZW4gdGhpbmtpbmcgZm9yIGEgd2hp bGUgaG93IHRvIGJ1aWxkIHNvbWV0aGluZyBsaWtlIHRoaXMgdXNpbmcgZXhpc3RpbmcgcHJvdG9j b2xzIGFuZCBob3N0IG9yIHJvdXRlciBiZWhhdmlvdXIuDQoNCkZ1bmRhbWVudGFsbHkgdHdvIHN0 YWdlczoNCg0KLSBjb2xsZWN0IG5vZGVzJyBsaW5rIGxvY2FsIGFkZHJlc3Nlcw0KDQotIHF1ZXJ5 IG5vZGVzJyBmb3IgdGhlaXIgb3RoZXIgR1VBIG9yIFVMQSBhZGRyZXNzZXMNCg0KQ29sbGVjdGlu ZyBub2RlcyBMTEFzIGNhbiBiZSBkb25lIHZpYSBjb2xsZWN0aW5nIHNvdXJjZSBhZGRyZXNzZXMg ZnJvbSBub2RlIGVtaXR0ZWQgUlNlc3MgYW5kL29yIE1MRHYyIHJlcG9ydHMuDQoNCk9uY2UgdGhl eSd2ZSBiZWVuIGNvbGxlY3RlZCwgdGhlbiBub2RlcyBhcmUgdW5pY2FzdCBxdWVyaWVkIGJ5IHJv dXRlcnMgZm9yIHRoZWlyIG90aGVyIGFkZHJlc3NlcyB2aWEgZWl0aGVyIElDTVB2NiBOb2RlIElu Zm9ybWF0aW9uIHF1ZXJpZXMgb3IgSW52ZXJzZSBORC4NCg0KKFRoZXJlIGlzIGN1cnJlbnRseSBh IGxpbWl0YXRpb24gd2l0aCBJQ01QdjYgTkkgdGhhdCBpdCBkb2Vzbid0IHJlcG9ydCB0ZW1wb3Jh cnkgYWRkcmVzc2VzIGZvciBzZWN1cml0eSByZWFzb25zLiBUaGF0IGNvdWxkIGJlIGxpZnRlZCBi eSBlLmcuIHNheWluZyB0aGF0IGFsbCBhZGRyZXNzZWQgaW5jbHVkaW5nIHRlbXBvcmFyaWVzIGFy ZSByZXBvcnRlZCBpZiB0aGUgTkkgcXVlcnkgc291cmNlIGFkZHJlc3MgaXMgYW4gTExBIGkuZS4g bGltaXRlZCB0byBhIHF1ZXJ5IGZyb20gYW4gb24tbGluayBzb3VyY2UsIG9yIGJvdGggTExBIHNv dXJjZSBhbmQgdGhhdCB0aGUgTExBIGlzIHRoYXQgb2YgYSBrbm93biBkZWZhdWx0IHJvdXRlci4p DQoNCkEgbmV3IG5vZGUgb24gdGhlIGxpbmsgZWZmZWN0aXZlbHkgYW5ub3VuY2VzIGl0cyBMTEEg dG8gZXhpc3Rpbmcgcm91dGVycyB2aWEgUlMgYW5kIE1MRHYyIGpvaW5zIGZvciBzb2xpY2l0ZWQg bm9kZSBncm91cHMgZm9yIGl0cyBhZGRyZXNzZXMgKGFuZCBvdGhlciBtdWx0aWNhc3QgZ3JvdXBz IGl0IG1heSBqb2luKS4NCg0KSWYgYSBub2RlIGNvbmZpZ3VyZXMgYSBuZXcgYWRkcmVzcywgaXQg am9pbnMgdGhlIGFkZHJlc3MncyBTb2xpY2l0ZWQgTm9kZSBNdWx0aWNhc3QgZ3JvdXAuIFJvdXRl cnMgdXNlIHRoYXQgYXMgYSBzaWduYWwgdG8gdW5pY2FzdCBxdWVyeSB0aGUgbm9kZSBpdCBmb3Ig aXRzIHVwZGF0ZWQgYWRkcmVzcyBsaXN0IHRvIGRpc2NvdmVyIHRoZSBuZXcgYWRkcmVzcy4NCg0K KERBRCBpcyBhbm90aGVyIHBvc3NpYmxlIHdheSBmb3Igcm91dGVycyB0byBjb2xsZWN0IG5ldyBh ZGRyZXNzIGluZm9ybWF0aW9uLCBob3dldmVyIEkgdGhpbmsgRXJpY3Nzb24gaGF2ZSBzb21lIElQ UiBvdmVyIHRoYXQgaWRlYSwgYW5kIGl0IGFsc28gZG9lc24ndCB3b3JrIGZvciBhbnljYXN0IGFk ZHJlc3NlcywgYmVjYXVzZSBEQURzIGFyZW4ndCBwZXJmb3JtZWQgZm9yIHRoZW0pLg0KDQpSb3V0 ZXJzIGRldGVjdCB3aGVuIGFuIGFkZHJlc3MgZGlzYXBwZWFycyB2aWEgc3RhbmRhcmQgTkQgTlVE Lg0KDQpBIG5ldyByb3V0ZXIgb24gYSBsaW5rIGNhbiBjb2xsZWN0IGV4aXN0aW5nIG5vZGVzJyBM TEFzIHZpYSBhIGdlbmVyYWwgTUxEIHF1ZXJ5LCBhcyBpdCBkb2VzIGFueXdheSB0byBjb2xsZWN0 IHRoZSBzZXQgb2YgbXVsdGljYXN0IGdyb3VwcyBvbiB0aGUgbGluay4gT25jZSB0aGUgbmV3IHJv dXRlciBoYXMgdGhhdCBzZXQgb2YgTExBcywgaXQgdGhlbiB1bmljYXN0IHF1ZXJpZXMgdGhlIG5v ZGVzIGZvciB0aGVpciBvdGhlciBhZGRyZXNzZXMuDQoNCg0KUGVyaGFwcyBhIGJpdCBvZiBwZWRh bnRyeSwgaG93ZXZlciBpZiBub2RlcyBhcmUgIk5laWdoYm91cnMiLCBzaW5jZSB3ZSBub3cgaGF2 ZSBwb3NzaWJseSBtdWx0aXBsZSBhZGRyZXNzZXMgcGVyIG5vZGUvbmVpZ2hib3VyLCBORCBpc24n dCByZWFsbHkgZGlzY292ZXJpbmcgbmVpZ2hib3VycywgaXQncyBhY3R1YWxseSBkaXNjb3Zlcmlu ZyB0aGUgcHJlc2VuY2Ugb2YgYWRkcmVzc2VzLCBub3QgIm5laWdoYm91cnMiLiBBZGRyZXNzIERp c2NvdmVyeSBvciBBZGRyZXNzIFByZXNlbmNlIERpc2NvdmVyeSB3b3VsZCBwZXJoYXBzIGJlIGEg bW9yZSBhY2N1cmF0ZSBuYW1lIGZvciB0aGlzIGZ1bmN0aW9uLg0KDQpSZWdhcmRzLA0KTWFyay4N Cg0KDQoNCj4gTm90IHNvIGVhc3kgZm9yIGJyb3duZmllbGQsIGkuZS4sIGluIG5ldHdvcmtzIHdo ZXJlIGNsYXNzaWMgTkQgaXMgYWxyZWFkeSB1c2VkIGluDQo+IHNvbWUgaG9zdHMgYW5kIHNvbWUg cm91dGVycy4gIOKAnEVmZmljaWVudCBOROKAnSAod2hpY2ggd2FzIGVzc2VudGlhbGx5IFJGQyA2 Nzc1DQo+IGZvciBFdGhlcm5ldCBhbmQgdGh1cyBhbHNvIHRyYWRpdGlvbmFsIFdpLUZpKSBtb3N0 bHkgZGlkbuKAmXQgdGFrZSBvZmYgYXQgdGhlIHRpbWUNCj4gYmVjYXVzZSB3ZSBkaWRu4oCZdCBh cnRpY3VsYXRlIGEgY29oYWJpdGF0aW9uICjigJx0cmFuc2l0aW9u4oCdKSBzdHJhdGVneS4gIEni gJltIHN1cmUNCj4gd2UgY2FuIGRvIHRoYXQgaWYgd2UgcHV0IGEgbGl0dGxlIG1vcmUgZm9jdXMg b24gaXQsIGxlYWRpbmcgdG8gYW5vdGhlcg0KPiBzcGVjaWZpY2F0aW9uIHRoYXQgZGVzY3JpYmVz IGhvdyB0byBydW4gaW4gbWl4ZWQgY2xhc3NpYy9lZmZpY2llbnQgTkQgbmV0d29ya3MuDQoNCkZv ciBJIHN0YXJ0ZWQgdGhhdCBhdCA2bG8gYW5kIHRoZXJlIGlzIHRleHQgaW4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZsby1iYWNrYm9uZS1yb3V0ZXIg LCBlLmcuLCBpbiBzZWN0aW9uIDMuMi4gVGhlIGNvZXhpc3RlbmNlIGlzIGFsc28gZGlzY3Vzc2Vk IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LTZsby11bmljYXN0 LWxvb2t1cCBidXQgYXQgc29tZSBwb2ludCBpdCBpcyBub3QgYSA2bG8gcHJvYmxlbSBhbnltb3Jl IGFuZCB0aGF0IHdvcmsgc2hvdWxkIHJlYWxseSBtb3ZlIHNvbWV3aGVyZSBlbHNlLg0KDQpCZWlu ZyBub24tbWFpbnRlbmFuY2UsIGl0IHNlZW1zIHRvbyBlYXJseSBmb3IgNk1BTi4gSWYgc28gbWF5 YmUgd2Ugc2hvdWxkIGZvcm0gYSBzaG9ydC1saXZlZCBXRyB0byBzb3J0IG91dCB0aGUgaXNzdWVz IHJhaXNlZCBieSBMb3JlbnpvLCAgeW91cnMgKGNvZXhpc3RlbmNlKSBhbmQgbWluZSAobGltaXQg dXNlIG9mIGJyb2FkY2FzdCAvIGludGVyZmFjZSB3aXRoIGEgZmFicmljIG1hcHBpbmcgc2VydmVy IGFuZCBkbyB1bmljYXN0IGxvb2t1cCB3aGVuIHBvc3NpYmxlKS4NCg0KQWxsIHRoZSBiZXN0LA0K DQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDYXJzdGVu IEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4NCj4gU2VudDogamV1 ZGkgNCBqdWlsbGV0IDIwMTkgMTM6MjINCj4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkg PHB0aHViZXJ0QGNpc2NvLmNvbTxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPj4NCj4gQ2M6IE1p Y2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IlMkJpZXRm QHNhbmRlbG1hbi5jYT4+OyA2bG9AaWV0Zi5vcmc8bWFpbHRvOjZsb0BpZXRmLm9yZz47IFY2IE9w cyBMaXN0DQo+IDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+PjsgNm1hbiA8 Nm1hbkBpZXRmLm9yZzxtYWlsdG86Nm1hbkBpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJlOiBbNmxv XSBBZHZvY2F0aW5nIGEgZ2VuZXJhbGlzYXRpb24gb2YgUkZDODUwNSB0byBub24tNmxvIExBTnMN Cj4NCj4gUkZDIDY3NzUvODUwNSBvbiBhIG5ldyAoZ3JlZW5maWVsZCkgZm9vIChhcyBpbiBJUCBv dmVyIGZvbykgaXMgcHJldHR5IG11Y2ggYQ0KPiBuby1icmFpbmVyLCBpZiB0aGF0IGZvbyBoYXMg cG9pbnRzIHdoZXJlIHRoZSA2TEJSIGZ1bmN0aW9uYWxpdHkgaXMgbmF0dXJhbGx5DQo+IGNlbnRy YWxpemVkLg0KPg0KPiBOb3Qgc28gZWFzeSBmb3IgYnJvd25maWVsZCwgaS5lLiwgaW4gbmV0d29y a3Mgd2hlcmUgY2xhc3NpYyBORCBpcyBhbHJlYWR5IHVzZWQgaW4NCj4gc29tZSBob3N0cyBhbmQg c29tZSByb3V0ZXJzLiAg4oCcRWZmaWNpZW50IE5E4oCdICh3aGljaCB3YXMgZXNzZW50aWFsbHkg UkZDIDY3NzUNCj4gZm9yIEV0aGVybmV0IGFuZCB0aHVzIGFsc28gdHJhZGl0aW9uYWwgV2lGaSkg bW9zdGx5IGRpZG7igJl0IHRha2Ugb2ZmIGF0IHRoZSB0aW1lDQo+IGJlY2F1c2Ugd2UgZGlkbuKA mXQgYXJ0aWN1bGF0ZSBhIGNvaGFiaXRhdGlvbiAo4oCcdHJhbnNpdGlvbuKAnSkgc3RyYXRlZ3ku ICBJ4oCZbSBzdXJlDQo+IHdlIGNhbiBkbyB0aGF0IGlmIHdlIHB1dCBhIGxpdHRsZSBtb3JlIGZv Y3VzIG9uIGl0LCBsZWFkaW5nIHRvIGFub3RoZXINCj4gc3BlY2lmaWNhdGlvbiB0aGF0IGRlc2Ny aWJlcyBob3cgdG8gcnVuIGluIG1peGVkIGNsYXNzaWMvZWZmaWNpZW50IE5EIG5ldHdvcmtzLg0K Pg0KPiBHcsO8w59lLCBDYXJzdGVuDQo+DQo+DQo+ID4gT24gSnVsIDQsIDIwMTksIGF0IDEyOjI4 LCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb208bWFpbHRvOnB0 aHViZXJ0QGNpc2NvLmNvbT4+DQo+IHdyb3RlOg0KPiA+DQo+ID4gSGVsbG8gQnJpYW46DQo+ID4N Cj4gPiBZZXMsIEknbSB3aWxsaW5nIHRvIG1ha2UgdGhlIGNhc2UuDQo+ID4NCj4gPiBUaGVyZSBh cmUgYSBudW1iZXIgb2YgcmVhc29ucyB0byBlbmFibGUgYSByZWdpc3RyYXRpb24gbWV0aG9kIG9u IGJleW9uZA0KPiA2bG8gbmV0d29ya3M6DQo+ID4gLSBJdCBpcyB1c2VmdWwgaW4gd2lyZWxlc3Mg aW4gZ2VuZXJhbCBiZWNhdXNlIGl0IGFkZHJlc3NlcyBub24tdHJhbnNpdA0KPiA+IG11bHRpcG9p bnQgbGlua3MgKHNlZQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXRodWJlcnQtNm1hbi1pcHY2LW92ZXItd2lyZWxlc3MNCj4gPiAvKSBhbmQgTkJNQSBNTC1zdWJu ZXRzDQo+ID4gLSBpdCBpcyB1c2VmdWwgaW4gcGFydGljdWxhciBpbiBXaS1GaSBiZWNhdXNlIGl0 IHJlZHVjZXMgdGhlIG5lZWQgZm9yIGJyb2FkY2FzdA0KPiBxdWl0ZSBkcmFtYXRpY2FsbHkuDQo+ ID4gLSBJdCBpcyB1c2VmdWwgaW4gYSBzd2l0Y2hlZCBmYWJyaWMgdG8gbWFpbnRhaW4gYW4gYWNj dXJhdGUgc3RhdGUgaW4NCj4gPiB0aGUgb3ZlcmxheSBtYXBwaW5nIHNlcnZlciAoc2VlDQo+ID4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC02bG8tdW5pY2Fz dC1sb29rdXAvKQ0KPiA+IC0gSXQgaXMgdXNlZnVsIGluIGEgc2l0dWF0aW9uIG9mIGhvc3QgbW9i aWxpdHkgaW4gZ2VuZXJhbCwgKHNlZSB0aGUNCj4gPiBkaXNjdXNzaW9uIGluDQo+ID4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcmlmdC1yaWZ0LTA2I3NlY3Rpb24tNS4z LjMgKQ0KPiA+IC0gSXQgaXMgdXNlZnVsIGZvciByb3V0ZXJzIHdpdGggaGFyZHdhcmUgYXNzaXN0 IGZvcndhcmRpbmcgdG8gYXZvaWQNCj4gPiB0aGUgcHVudGluZyBkYW5jZSBhbmQgZHJvcHBpbmcg b2YgcGFja2V0cw0KPiA+IC0gSXQgcHJvdmlkZXMgU0FWSSBwcm9wZXJ0aWVzIHdpdGggYSB3b3Jr YWJsZSBTZWN1cmUgTkQgKHNlZQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtNmxvLWFwLW5kLykNCj4gPiAtIEl0IHByb3ZpZGVzIGFuIGFic3RyYWN0IGlu dGVyZmFjZSB0byB0aGUgcm91dGVyIHRvIGdldCByb3V0aW5nDQo+ID4gc2VydmljZXMgKGFscmVh ZHkgdXNlZCB3aXRoIFJJRlQsIFJQTCwgc2VlDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLywgYW5kDQo+ID4gTkQgcHJv eHksIHNlZQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt NmxvLWJhY2tib25lLXJvdXRlci8pDQo+ID4gLSBJdCBzb2x2ZXMgYSBudW1iZXIgb2YgcHJvYmxl bXMgaW5jbHVkaW5nIEplbidzLCBidXQgYWxzbyBzbGVlcGluZyBkZXZpY2VzIG9uDQo+IG5vbi02 bG8gbmV0d29ya3MsIHJlbW90ZSBET1MgYWdhaW5zdCByb3V0ZXIgYW5kIE5EIGNhY2hlLCBhbmQg bW9yZS4NCj4gPg0KPiA+IEFsbCBpbiBhbGwgSSBzZWUgaXQgYXMgYSBtdWNoIG5lZWRlZCBtb2Rl cm5pemF0aW9uIG9mIE5EIHRvIGNvcGUgd2l0aCB0aGUNCj4gZXZvbHV0aW9ucyBvZiB0aGUgbmV0 d29yayAoSU9ULCBXaS1GaSBhbmQgb3ZlcmxheXMpIGFuZCB3aXRoIHRoZSBuZXcgbmVlZHMNCj4g YW5kIGJlaGF2aW9ycyAoaW5zdGFudCBjb25uZWN0aXZpdHksIGZhc3Qgcm9hbWluZykuDQo+ID4N Cj4gPiBBbGwgdGhlIGJlc3QsDQo+ID4NCj4gPiBQYXNjYWwNCj4gPg0KPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiA2bG8gPDZsby1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzo2bG8tYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRz b24NCj4gPj4gU2VudDogamV1ZGkgNCBqdWlsbGV0IDIwMTkgMDI6NTgNCj4gPj4gVG86IDZsb0Bp ZXRmLm9yZzxtYWlsdG86NmxvQGlldGYub3JnPjsgVjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3Jn PG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+OyA2bWFuIDw2bWFuQGlldGYub3JnPG1haWx0bzo2bWFu QGlldGYub3JnPj4NCj4gPj4gU3ViamVjdDogUmU6IFs2bG9dIE5EIGNhY2hlIGVudHJpZXMgY3Jl YXRpb24gb24gZmlyc3QtaG9wIHJvdXRlcnMNCj4gPj4NCj4gPj4NCj4gPj4gQnJpYW4gRSBDYXJw ZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTxtYWlsdG86YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tPj4gd3JvdGU6DQo+ID4+Pj4gSeKAmW0gaW50ZXJlc3RlZCB0byBoYXZlIGEg cGFyYWxsZWwgZGlzY3Vzc2lvbiBvbiB3aGVyZSBSRkMgODUwNSBjYW4NCj4gPj4+PiBub3QgYXBw bHkuIEluIHRoZSBwcm9kdWN0cyBhbmQgdXNlIGNhc2VzIEnigJltIGF3YXJlIG9mLCBpdCBjb3Vs ZCwNCj4gPj4+PiBzaW5jZSB3ZSBhcmUgYWN0dWFsbHkgZmFraW5nIGl0IGJ5IHNub29waW5nIE5E IGFuZCBESENQIHRvIGFjaGlldmUNCj4gPj4+PiBzaW1pbGFyIGJ1dCBsZXNzIGFjY3VyYXRlIHJl c3VsdHMuDQo+ID4+DQo+ID4+PiBTbyBpZiB5b3UgYXJlIGFkdm9jYXRpbmcgYSBnZW5lcmFsaXNh dGlvbiBvZiBSRkM4NTA1IHRvIG5vbi02bG8NCj4gPj4+IExBTnMsIHRoYXQncyBjZXJ0YWlubHkg YSBkaXNjdXNzaW9uIHdlIGNvdWxkIGhhdmUsIElNSE8uDQo+ID4+DQo+ID4+IEkgdGhpbmsgdGhh dCBpdCBjb3VsZCBiZSBhcHBsaWVkIGluIHNpdHVhdGlvbnMgb2Ygc2VydmVycywgc3VjaCBhcw0K PiA+PiBkYXRhIGNlbnRlcnMgd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIHRlbmFudHMuIChNYW55 IFZNDQo+ID4+IGluZnJhc3RydWN0dXJlcyBoYXZlIHNoYXJlZCBmcm9udC1lbmQgbmV0d29ya3Mp DQo+ID4+DQo+ID4+IEkgdGhpbmsgdGhhdCB0ZW1wb3JhcnkgYWRkcmVzc2VzcyBhcmUgbm90IGEg ZmVhdHVyZSBpbiBzb21lIG9mIHRob3NlDQo+ID4+IGRlcGxveW1lbnRzIHRoYXQgZXZlcnlvbmUg d2FudHMsIGFuZCB0aHVzIGhhdmluZyBhIHJlZ2lzdHJhdGlvbg0KPiA+PiBzeXN0ZW0gaXMgYSBm ZWF0dXJlLg0KPiA+Pg0KPiA+PiBUaGlzIGRvZXMgbm90IHNvbHZlIHRoZSBzbWFydHBob25lIG9u IG5ldyBXSUZJIGlzc3VlLCB3aGljaCBpcyBhDQo+ID4+IGRpZmZlcmVudCBzaXR1YXRpb24gY29t cGxldGVseS4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gXSAgICAgICAgICAgICAgIE5ldmVyIHRlbGwg bWUgdGhlIG9kZHMhICAgICAgICAgICAgICAgICB8IGlwdjYgbWVzaCBuZXR3b3JrcyBbDQo+ID4+ IF0gICBNaWNoYWVsIFJpY2hhcmRzb24sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyAgICAgICAg fCAgICBJb1QgYXJjaGl0ZWN0ICAgWw0KPiA+PiBdICAgICBtY3JAc2FuZGVsbWFuLmNhPG1haWx0 bzptY3JAc2FuZGVsbWFuLmNhPiAgaHR0cDovL3d3dy5zYW5kZWxtYW4uY2EvICAgICAgICB8ICAg cnVieSBvbiByYWlscyAgICBbDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IDZsbyBtYWlsaW5nIGxpc3QNCj4gPiA2bG9AaWV0Zi5v cmc8bWFpbHRvOjZsb0BpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvLzZsbw0KPiA+DQo+ID4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4N CkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= --_000_MN2PR11MB3565F85F6E989972B92045CBD8FA0MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0 IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTY1MDYxOTY7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDE2MTQyNTMw IC01MTM3NDM3NzYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gTWFyazo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIGEgbnVtYmVyIG9mIHRoaW5ncyAmbmJzcDt0aGF0IHRo ZSByb3V0ZXIgd291bGQgbGlrZSB0byBrbm93IGluIHRoZSBwcm9jZXNzOjxvOnA+PC9vOnA+PC9w Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPkEgc2Vuc2Ugb2YgbGlmZXRpbWU7IGhvdyBsb25nIHNob3VsZCB0aGUgcm91dGVyL0wz QVAgZXhwZWN0IHRoYXQgdGhlIGFkZHJlc3Mgd2lsbCBiZSB1c2VkOyBhdCB0aW1lIG91dCwgdGhl IHJvdXRlciBjYW4gY2xlYW4gdXAgdGhlIHN0YXRlLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+QSBzZW5zZSBvZiBvcmRlcjsgaWYgYSB3aXJlbGVzcyBub2RlIG1vdmVzIHJh cGlkbHkgZnJvbSBhIEwzQVAgdG8gdGhlIG5leHQsIG9yIGEgVk0gbW92ZXMgcmFwaWRseSBmcm9t IGEgc2VydmVyIHRvIHRoZSBuZXh0LCB3aGljaCBpcyB0aGUgbW9zdCByZWNlbnQgcG9pbnQgb2Yg YXR0YWNobWVudDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkEgc2Vuc2Ugb2Yg b3duZXJzaGlwOyBpZiB0aGUgcm91dGVyIG1haW50YWlucyBhIHN0YXRlIGFib3V0IHRoZSBhZGRy ZXNzIGZvciBhIHJlcXVlc3RlZCBsaWZldGltZSwgdGhlbiBhIHByb29mIG9mIG93bmVyc2hpcCBj YW4gYmUgYXR0YWNoZWQsIHNvIG9ubHkgdGhlIG93bmVyIG9mIHRoZSBhZGRyZXNzIGNhbiBtb2Rp ZnkNCiB0aGUgc3RhdGUgKFNBVkkpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ QSBzZW5zZSBvZiBzZXJ2aWNlOyB3aGF0IHNob3VsZCB0aGUgcm91dGVyIGRvIHdpdGggdGhhdCBh ZGRyZXNzPyBFeGFtcGxlcyB0aGF0IGNvbWUgdG8gbWluZCBhcmUgaW5qZWN0IGluIGEgcm91dGlu ZyBwcm90b2NvbCwgcGxheSBzbGVlcGluZyBwcm94eSBvciBORCBwcm94eS48bzpwPjwvbzpwPjwv bGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SXQgZG9lcyBub3QgdGFrZSBuZXcgbWVzc2FnZXMgYnV0IGEgbmV3 IG9wdGlvbiBpcyBuZWVkZWQgdG8gcHJvdmlkZSBhbGwgdGhhdCBpbmZvcm1hdGlvbi4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgdGhlIGJlc3QsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlBhc2NhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNYXJrIFNtaXRo ICZsdDttYXJrenp6c21pdGhAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gamV1ZGkg NCBqdWlsbGV0IDIwMTkgMTQ6Mzk8YnI+DQo8Yj5Ubzo8L2I+IFBhc2NhbCBUaHViZXJ0IChwdGh1 YmVydCkgJmx0O3B0aHViZXJ0QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IENhcnN0ZW4g Qm9ybWFubiAmbHQ7Y2Fib0B0emkub3JnJmd0OzsgTWljaGFlbCBSaWNoYXJkc29uICZsdDttY3Im IzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0OzsgVjYgT3BzIExpc3QgJmx0O3Y2b3BzQGlldGYub3Jn Jmd0OzsgNm1hbiAmbHQ7Nm1hbkBpZXRmLm9yZyZndDs7IDZsb0BpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogWzZsb10gQWR2b2NhdGluZyBhIGdlbmVyYWxpemF0aW9uIG9mIFJGQzg1 MDUgdG8gbm9uLTZsbyBMQU5zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodS4sIDQg SnVsLiAyMDE5LCAyMTozOCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpLCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnB0aHViZXJ0QGNpc2Nv LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhbGwgdmVyeSByaWdodCwgQ2Fyc3Rlbi48YnI+ DQo8YnI+DQo8YnI+DQomZ3Q7IFJGQyA2Nzc1Lzg1MDUgb24gYSBuZXcgKGdyZWVuZmllbGQpIGZv byAoYXMgaW4gSVAgb3ZlciBmb28pIGlzIHByZXR0eSBtdWNoIGE8YnI+DQomZ3Q7IG5vLWJyYWlu ZXIsIGlmIHRoYXQgZm9vIGhhcyBwb2ludHMgd2hlcmUgdGhlIDZMQlIgZnVuY3Rpb25hbGl0eSBp cyBuYXR1cmFsbHk8YnI+DQomZ3Q7IGNlbnRyYWxpemVkLjxicj4NCjxicj4NCk5vIGJyYWluZXIg aXQgaXMsIGJ1dCBmb3IgTG9yZW56bydzIGlzc3VlcyBvbiBzdGF0ZSBwcmVzZXJ2YXRpb24gb3Ig cmVjb25zdHJ1Y3Rpb24gdXBvbiByb3V0ZXIgcmVib290LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg dGhpbmsgdGhhdCBjYW4gYmUgb3ZlcmNvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkndmUgYmVlbiB0aGlua2luZyBmb3IgYSB3aGlsZSBo b3cgdG8gYnVpbGQgc29tZXRoaW5nIGxpa2UgdGhpcyB1c2luZyBleGlzdGluZyBwcm90b2NvbHMg YW5kIGhvc3Qgb3Igcm91dGVyIGJlaGF2aW91ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnVuZGFtZW50YWxseSB0d28gc3RhZ2VzOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGNvbGxl Y3Qgbm9kZXMnIGxpbmsgbG9jYWwgYWRkcmVzc2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gcXVlcnkgbm9kZXMnIGZvciB0aGVpciBvdGhl ciBHVUEgb3IgVUxBIGFkZHJlc3NlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Db2xsZWN0aW5nIG5vZGVzIExMQXMgY2FuIGJlIGRvbmUgdmlh IGNvbGxlY3Rpbmcgc291cmNlIGFkZHJlc3NlcyBmcm9tIG5vZGUgZW1pdHRlZCBSU2VzcyBhbmQv b3IgTUxEdjIgcmVwb3J0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T25jZSB0aGV5J3ZlIGJlZW4gY29sbGVjdGVkLCB0aGVuIG5vZGVzIGFy ZSB1bmljYXN0IHF1ZXJpZWQgYnkgcm91dGVycyBmb3IgdGhlaXIgb3RoZXIgYWRkcmVzc2VzIHZp YSBlaXRoZXIgSUNNUHY2IE5vZGUgSW5mb3JtYXRpb24gcXVlcmllcyBvciBJbnZlcnNlIE5ELjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oVGhl cmUgaXMgY3VycmVudGx5IGEgbGltaXRhdGlvbiB3aXRoIElDTVB2NiBOSSB0aGF0IGl0IGRvZXNu J3QgcmVwb3J0IHRlbXBvcmFyeSBhZGRyZXNzZXMgZm9yIHNlY3VyaXR5IHJlYXNvbnMuIFRoYXQg Y291bGQgYmUgbGlmdGVkIGJ5IGUuZy4gc2F5aW5nIHRoYXQgYWxsIGFkZHJlc3NlZCBpbmNsdWRp bmcgdGVtcG9yYXJpZXMgYXJlIHJlcG9ydGVkIGlmIHRoZSBOSSBxdWVyeSBzb3VyY2UgYWRkcmVz cyBpcw0KIGFuIExMQSBpLmUuIGxpbWl0ZWQgdG8gYSBxdWVyeSBmcm9tIGFuIG9uLWxpbmsgc291 cmNlLCBvciBib3RoIExMQSBzb3VyY2UgYW5kIHRoYXQgdGhlIExMQSBpcyB0aGF0IG9mIGEga25v d24gZGVmYXVsdCByb3V0ZXIuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BIG5ldyBub2RlIG9uIHRoZSBsaW5rIGVmZmVjdGl2ZWx5IGFubm91 bmNlcyBpdHMgTExBIHRvIGV4aXN0aW5nIHJvdXRlcnMgdmlhIFJTIGFuZCBNTER2MiBqb2lucyBm b3Igc29saWNpdGVkIG5vZGUgZ3JvdXBzIGZvciBpdHMgYWRkcmVzc2VzIChhbmQgb3RoZXIgbXVs dGljYXN0IGdyb3VwcyBpdCBtYXkgam9pbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGEgbm9kZSBjb25maWd1cmVzIGEgbmV3IGFkZHJl c3MsIGl0IGpvaW5zIHRoZSBhZGRyZXNzJ3MgU29saWNpdGVkIE5vZGUgTXVsdGljYXN0IGdyb3Vw LiBSb3V0ZXJzIHVzZSB0aGF0IGFzIGEgc2lnbmFsIHRvIHVuaWNhc3QgcXVlcnkgdGhlIG5vZGUg aXQgZm9yIGl0cyB1cGRhdGVkIGFkZHJlc3MgbGlzdCB0byBkaXNjb3ZlciB0aGUgbmV3IGFkZHJl c3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PihEQUQgaXMgYW5vdGhlciBwb3NzaWJsZSB3YXkgZm9yIHJvdXRlcnMgdG8gY29sbGVjdCBuZXcg YWRkcmVzcyBpbmZvcm1hdGlvbiwgaG93ZXZlciBJIHRoaW5rIEVyaWNzc29uIGhhdmUgc29tZSBJ UFIgb3ZlciB0aGF0IGlkZWEsIGFuZCBpdCBhbHNvIGRvZXNuJ3Qgd29yayBmb3IgYW55Y2FzdCBh ZGRyZXNzZXMsIGJlY2F1c2UgREFEcyBhcmVuJ3QgcGVyZm9ybWVkIGZvciB0aGVtKS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um91dGVycyBk ZXRlY3Qgd2hlbiBhbiBhZGRyZXNzIGRpc2FwcGVhcnMgdmlhIHN0YW5kYXJkIE5EIE5VRC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBuZXcg cm91dGVyIG9uIGEgbGluayBjYW4gY29sbGVjdCBleGlzdGluZyBub2RlcycgTExBcyB2aWEgYSBn ZW5lcmFsIE1MRCBxdWVyeSwgYXMgaXQgZG9lcyBhbnl3YXkgdG8gY29sbGVjdCB0aGUgc2V0IG9m IG11bHRpY2FzdCBncm91cHMgb24gdGhlIGxpbmsuIE9uY2UgdGhlIG5ldyByb3V0ZXIgaGFzIHRo YXQgc2V0IG9mIExMQXMsIGl0IHRoZW4gdW5pY2FzdCBxdWVyaWVzIHRoZSBub2RlcyBmb3IgdGhl aXINCiBvdGhlciBhZGRyZXNzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBhIGJpdCBvZiBwZWRhbnRyeSwgaG93ZXZlciBp ZiBub2RlcyBhcmUgJnF1b3Q7TmVpZ2hib3VycyZxdW90Oywgc2luY2Ugd2Ugbm93IGhhdmUgcG9z c2libHkgbXVsdGlwbGUgYWRkcmVzc2VzIHBlciBub2RlL25laWdoYm91ciwgTkQgaXNuJ3QgcmVh bGx5IGRpc2NvdmVyaW5nIG5laWdoYm91cnMsIGl0J3MgYWN0dWFsbHkgZGlzY292ZXJpbmcgdGhl IHByZXNlbmNlIG9mIGFkZHJlc3Nlcywgbm90ICZxdW90O25laWdoYm91cnMmcXVvdDsuDQogQWRk cmVzcyBEaXNjb3Zlcnkgb3IgQWRkcmVzcyBQcmVzZW5jZSBEaXNjb3Zlcnkgd291bGQgcGVyaGFw cyBiZSBhIG1vcmUgYWNjdXJhdGUgbmFtZSBmb3IgdGhpcyBmdW5jdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcmsuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IE5vdCBzbyBlYXN5IGZvciBicm93bmZpZWxkLCBpLmUu LCBpbiBuZXR3b3JrcyB3aGVyZSBjbGFzc2ljIE5EIGlzIGFscmVhZHkgdXNlZCBpbjxicj4NCiZn dDsgc29tZSBob3N0cyBhbmQgc29tZSByb3V0ZXJzLiZuYnNwOyDigJxFZmZpY2llbnQgTkTigJ0g KHdoaWNoIHdhcyBlc3NlbnRpYWxseSBSRkMgNjc3NTxicj4NCiZndDsgZm9yIEV0aGVybmV0IGFu ZCB0aHVzIGFsc28gdHJhZGl0aW9uYWwgV2ktRmkpIG1vc3RseSBkaWRu4oCZdCB0YWtlIG9mZiBh dCB0aGUgdGltZTxicj4NCiZndDsgYmVjYXVzZSB3ZSBkaWRu4oCZdCBhcnRpY3VsYXRlIGEgY29o YWJpdGF0aW9uICjigJx0cmFuc2l0aW9u4oCdKSBzdHJhdGVneS4mbmJzcDsgSeKAmW0gc3VyZTxi cj4NCiZndDsgd2UgY2FuIGRvIHRoYXQgaWYgd2UgcHV0IGEgbGl0dGxlIG1vcmUgZm9jdXMgb24g aXQsIGxlYWRpbmcgdG8gYW5vdGhlcjxicj4NCiZndDsgc3BlY2lmaWNhdGlvbiB0aGF0IGRlc2Ny aWJlcyBob3cgdG8gcnVuIGluIG1peGVkIGNsYXNzaWMvZWZmaWNpZW50IE5EIG5ldHdvcmtzLjxi cj4NCjxicj4NCkZvciBJIHN0YXJ0ZWQgdGhhdCBhdCA2bG8gYW5kIHRoZXJlIGlzIHRleHQgaW4g PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LTZsby1iYWNrYm9uZS1yb3V0ZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi02bG8tYmFja2JvbmUtcm91dGVyPC9hPiAs IGUuZy4sIGluIHNlY3Rpb24gMy4yLiBUaGUgY29leGlzdGVuY2UgaXMgYWxzbyBkaXNjdXNzZWQg aW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LTZs by11bmljYXN0LWxvb2t1cCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXRodWJlcnQtNmxvLXVuaWNhc3QtbG9va3VwPC9hPiBidXQgYXQgc29tZSBw b2ludCBpdCBpcyBub3QgYSA2bG8gcHJvYmxlbSBhbnltb3JlIGFuZCB0aGF0IHdvcmsgc2hvdWxk IHJlYWxseSBtb3ZlIHNvbWV3aGVyZSBlbHNlLg0KPGJyPg0KPGJyPg0KQmVpbmcgbm9uLW1haW50 ZW5hbmNlLCBpdCBzZWVtcyB0b28gZWFybHkgZm9yIDZNQU4uIElmIHNvIG1heWJlIHdlIHNob3Vs ZCBmb3JtIGEgc2hvcnQtbGl2ZWQgV0cgdG8gc29ydCBvdXQgdGhlIGlzc3VlcyByYWlzZWQgYnkg TG9yZW56bywmbmJzcDsgeW91cnMgKGNvZXhpc3RlbmNlKSBhbmQgbWluZSAobGltaXQgdXNlIG9m IGJyb2FkY2FzdCAvIGludGVyZmFjZSB3aXRoIGEgZmFicmljIG1hcHBpbmcgc2VydmVyIGFuZCBk byB1bmljYXN0IGxvb2t1cCB3aGVuDQogcG9zc2libGUpLjxicj4NCjxicj4NCkFsbCB0aGUgYmVz dCw8YnI+DQo8YnI+DQpQYXNjYWw8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBDYXJzdGVuIEJvcm1hbm4gJmx0OzxhIGhyZWY9Im1haWx0 bzpjYWJvQHR6aS5vcmciIHRhcmdldD0iX2JsYW5rIj5jYWJvQHR6aS5vcmc8L2E+Jmd0Ozxicj4N CiZndDsgU2VudDogamV1ZGkgNCBqdWlsbGV0IDIwMTkgMTM6MjI8YnI+DQomZ3Q7IFRvOiBQYXNj YWwgVGh1YmVydCAocHRodWJlcnQpICZsdDs8YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+cHRodWJlcnRAY2lzY28uY29tPC9hPiZndDs8YnI+DQomZ3Q7 IENjOiBNaWNoYWVsIFJpY2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3IlMkJpZXRmQHNh bmRlbG1hbi5jYSIgdGFyZ2V0PSJfYmxhbmsiPm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+ Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzo2bG9AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj42bG9A aWV0Zi5vcmc8L2E+OyBWNiBPcHMgTGlzdDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiZndDs7IDZt YW4gJmx0OzxhIGhyZWY9Im1haWx0bzo2bWFuQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Nm1h bkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogWzZsb10gQWR2b2NhdGlu ZyBhIGdlbmVyYWxpc2F0aW9uIG9mIFJGQzg1MDUgdG8gbm9uLTZsbyBMQU5zPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFJGQyA2Nzc1Lzg1MDUgb24gYSBuZXcgKGdyZWVuZmllbGQpIGZvbyAoYXMgaW4g SVAgb3ZlciBmb28pIGlzIHByZXR0eSBtdWNoIGE8YnI+DQomZ3Q7IG5vLWJyYWluZXIsIGlmIHRo YXQgZm9vIGhhcyBwb2ludHMgd2hlcmUgdGhlIDZMQlIgZnVuY3Rpb25hbGl0eSBpcyBuYXR1cmFs bHk8YnI+DQomZ3Q7IGNlbnRyYWxpemVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBOb3Qgc28gZWFz eSBmb3IgYnJvd25maWVsZCwgaS5lLiwgaW4gbmV0d29ya3Mgd2hlcmUgY2xhc3NpYyBORCBpcyBh bHJlYWR5IHVzZWQgaW48YnI+DQomZ3Q7IHNvbWUgaG9zdHMgYW5kIHNvbWUgcm91dGVycy4mbmJz cDsg4oCcRWZmaWNpZW50IE5E4oCdICh3aGljaCB3YXMgZXNzZW50aWFsbHkgUkZDIDY3NzU8YnI+ DQomZ3Q7IGZvciBFdGhlcm5ldCBhbmQgdGh1cyBhbHNvIHRyYWRpdGlvbmFsIFdpRmkpIG1vc3Rs eSBkaWRu4oCZdCB0YWtlIG9mZiBhdCB0aGUgdGltZTxicj4NCiZndDsgYmVjYXVzZSB3ZSBkaWRu 4oCZdCBhcnRpY3VsYXRlIGEgY29oYWJpdGF0aW9uICjigJx0cmFuc2l0aW9u4oCdKSBzdHJhdGVn eS4mbmJzcDsgSeKAmW0gc3VyZTxicj4NCiZndDsgd2UgY2FuIGRvIHRoYXQgaWYgd2UgcHV0IGEg bGl0dGxlIG1vcmUgZm9jdXMgb24gaXQsIGxlYWRpbmcgdG8gYW5vdGhlcjxicj4NCiZndDsgc3Bl Y2lmaWNhdGlvbiB0aGF0IGRlc2NyaWJlcyBob3cgdG8gcnVuIGluIG1peGVkIGNsYXNzaWMvZWZm aWNpZW50IE5EIG5ldHdvcmtzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBHcsO8w59lLCBDYXJzdGVu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBPbiBKdWwgNCwgMjAxOSwgYXQg MTI6MjgsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1 YmVydEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5wdGh1YmVydEBjaXNjby5jb208L2E+Jmd0 Ozxicj4NCiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhlbGxvIEJy aWFuOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZZXMsIEknbSB3aWxsaW5nIHRvIG1h a2UgdGhlIGNhc2UuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZXJlIGFyZSBhIG51 bWJlciBvZiByZWFzb25zIHRvIGVuYWJsZSBhIHJlZ2lzdHJhdGlvbiBtZXRob2Qgb24gYmV5b25k PGJyPg0KJmd0OyA2bG8gbmV0d29ya3M6PGJyPg0KJmd0OyAmZ3Q7IC0gSXQgaXMgdXNlZnVsIGlu IHdpcmVsZXNzIGluIGdlbmVyYWwgYmVjYXVzZSBpdCBhZGRyZXNzZXMgbm9uLXRyYW5zaXQ8YnI+ DQomZ3Q7ICZndDsgbXVsdGlwb2ludCBsaW5rcyAoc2VlPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtNm1hbi1pcHY2 LW92ZXItd2lyZWxlc3MiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtNm1hbi1pcHY2LW92ZXItd2lyZWxlc3M8L2E+PGJyPg0K Jmd0OyAmZ3Q7IC8pIGFuZCBOQk1BIE1MLXN1Ym5ldHM8YnI+DQomZ3Q7ICZndDsgLSBpdCBpcyB1 c2VmdWwgaW4gcGFydGljdWxhciBpbiBXaS1GaSBiZWNhdXNlIGl0IHJlZHVjZXMgdGhlIG5lZWQg Zm9yIGJyb2FkY2FzdDxicj4NCiZndDsgcXVpdGUgZHJhbWF0aWNhbGx5Ljxicj4NCiZndDsgJmd0 OyAtIEl0IGlzIHVzZWZ1bCBpbiBhIHN3aXRjaGVkIGZhYnJpYyB0byBtYWludGFpbiBhbiBhY2N1 cmF0ZSBzdGF0ZSBpbjxicj4NCiZndDsgJmd0OyB0aGUgb3ZlcmxheSBtYXBwaW5nIHNlcnZlciAo c2VlPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXRodWJlcnQtNmxvLXVuaWNhc3QtbG9va3VwLyIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC02bG8tdW5pY2Fz dC1sb29rdXAvPC9hPik8YnI+DQomZ3Q7ICZndDsgLSBJdCBpcyB1c2VmdWwgaW4gYSBzaXR1YXRp b24gb2YgaG9zdCBtb2JpbGl0eSBpbiBnZW5lcmFsLCAoc2VlIHRoZTxicj4NCiZndDsgJmd0OyBk aXNjdXNzaW9uIGluPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJpZnQtcmlmdC0wNiNzZWN0aW9uLTUuMy4zIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yaWZ0LXJpZnQt MDYjc2VjdGlvbi01LjMuMzwvYT4gKTxicj4NCiZndDsgJmd0OyAtIEl0IGlzIHVzZWZ1bCBmb3Ig cm91dGVycyB3aXRoIGhhcmR3YXJlIGFzc2lzdCBmb3J3YXJkaW5nIHRvIGF2b2lkPGJyPg0KJmd0 OyAmZ3Q7IHRoZSBwdW50aW5nIGRhbmNlIGFuZCBkcm9wcGluZyBvZiBwYWNrZXRzPGJyPg0KJmd0 OyAmZ3Q7IC0gSXQgcHJvdmlkZXMgU0FWSSBwcm9wZXJ0aWVzIHdpdGggYSB3b3JrYWJsZSBTZWN1 cmUgTkQgKHNlZTxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLTZsby1hcC1uZC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNmxvLWFwLW5kLzwvYT4pPGJy Pg0KJmd0OyAmZ3Q7IC0gSXQgcHJvdmlkZXMgYW4gYWJzdHJhY3QgaW50ZXJmYWNlIHRvIHRoZSBy b3V0ZXIgdG8gZ2V0IHJvdXRpbmc8YnI+DQomZ3Q7ICZndDsgc2VydmljZXMgKGFscmVhZHkgdXNl ZCB3aXRoIFJJRlQsIFJQTCwgc2VlPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcy8iIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcm9sbC11bmF3YXJlLWxlYXZlcy88L2E+LCBhbmQ8YnI+DQomZ3Q7ICZndDsgTkQgcHJveHks IHNlZTxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLTZsby1iYWNrYm9uZS1yb3V0ZXIvIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZsby1iYWNrYm9uZS1y b3V0ZXIvPC9hPik8YnI+DQomZ3Q7ICZndDsgLSBJdCBzb2x2ZXMgYSBudW1iZXIgb2YgcHJvYmxl bXMgaW5jbHVkaW5nIEplbidzLCBidXQgYWxzbyBzbGVlcGluZyBkZXZpY2VzIG9uPGJyPg0KJmd0 OyBub24tNmxvIG5ldHdvcmtzLCByZW1vdGUgRE9TIGFnYWluc3Qgcm91dGVyIGFuZCBORCBjYWNo ZSwgYW5kIG1vcmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFsbCBpbiBhbGwgSSBz ZWUgaXQgYXMgYSBtdWNoIG5lZWRlZCBtb2Rlcm5pemF0aW9uIG9mIE5EIHRvIGNvcGUgd2l0aCB0 aGU8YnI+DQomZ3Q7IGV2b2x1dGlvbnMgb2YgdGhlIG5ldHdvcmsgKElPVCwgV2ktRmkgYW5kIG92 ZXJsYXlzKSBhbmQgd2l0aCB0aGUgbmV3IG5lZWRzPGJyPg0KJmd0OyBhbmQgYmVoYXZpb3JzIChp bnN0YW50IGNvbm5lY3Rpdml0eSwgZmFzdCByb2FtaW5nKS48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgQWxsIHRoZSBiZXN0LDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBQYXNj YWw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBGcm9tOiA2bG8gJmx0OzxhIGhyZWY9Im1haWx0bzo2 bG8tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZsby1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsgT24gQmVoYWxmIE9mIE1pY2hhZWwgUmljaGFyZHNvbjxicj4NCiZndDsgJmd0OyZn dDsgU2VudDogamV1ZGkgNCBqdWlsbGV0IDIwMTkgMDI6NTg8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRv OiA8YSBocmVmPSJtYWlsdG86NmxvQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NmxvQGlldGYu b3JnPC9hPjsgVjYgT3BzIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiZndDs7IDZtYW4gJmx0OzxhIGhyZWY9 Im1haWx0bzo2bWFuQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Nm1hbkBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogWzZsb10gTkQgY2FjaGUgZW50cmll cyBjcmVhdGlvbiBvbiBmaXJzdC1ob3Agcm91dGVyczxicj4NCiZndDsgJmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBCcmlhbiBFIENhcnBlbnRlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBJ4oCZbSBpbnRlcmVzdGVkIHRvIGhhdmUgYSBwYXJhbGxlbCBkaXNjdXNz aW9uIG9uIHdoZXJlIFJGQyA4NTA1IGNhbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBub3Qg YXBwbHkuIEluIHRoZSBwcm9kdWN0cyBhbmQgdXNlIGNhc2VzIEnigJltIGF3YXJlIG9mLCBpdCBj b3VsZCw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc2luY2Ugd2UgYXJlIGFjdHVhbGx5IGZh a2luZyBpdCBieSBzbm9vcGluZyBORCBhbmQgREhDUCB0byBhY2hpZXZlPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IHNpbWlsYXIgYnV0IGxlc3MgYWNjdXJhdGUgcmVzdWx0cy48YnI+DQomZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgU28gaWYgeW91IGFyZSBhZHZvY2F0aW5n IGEgZ2VuZXJhbGlzYXRpb24gb2YgUkZDODUwNSB0byBub24tNmxvPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgTEFOcywgdGhhdCdzIGNlcnRhaW5seSBhIGRpc2N1c3Npb24gd2UgY291bGQgaGF2ZSwg SU1ITy48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQg aXQgY291bGQgYmUgYXBwbGllZCBpbiBzaXR1YXRpb25zIG9mIHNlcnZlcnMsIHN1Y2ggYXM8YnI+ DQomZ3Q7ICZndDsmZ3Q7IGRhdGEgY2VudGVycyB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgdGVu YW50cy4gKE1hbnkgVk08YnI+DQomZ3Q7ICZndDsmZ3Q7IGluZnJhc3RydWN0dXJlcyBoYXZlIHNo YXJlZCBmcm9udC1lbmQgbmV0d29ya3MpPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgSSB0aGluayB0aGF0IHRlbXBvcmFyeSBhZGRyZXNzZXNzIGFyZSBub3QgYSBmZWF0dXJl IGluIHNvbWUgb2YgdGhvc2U8YnI+DQomZ3Q7ICZndDsmZ3Q7IGRlcGxveW1lbnRzIHRoYXQgZXZl cnlvbmUgd2FudHMsIGFuZCB0aHVzIGhhdmluZyBhIHJlZ2lzdHJhdGlvbjxicj4NCiZndDsgJmd0 OyZndDsgc3lzdGVtIGlzIGEgZmVhdHVyZS48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyBUaGlzIGRvZXMgbm90IHNvbHZlIHRoZSBzbWFydHBob25lIG9uIG5ldyBXSUZJIGlz c3VlLCB3aGljaCBpcyBhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBkaWZmZXJlbnQgc2l0dWF0aW9uIGNv bXBsZXRlbHkuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS08YnI+DQom Z3Q7ICZndDsmZ3Q7IF0mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7TmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgaXB2NiBtZXNoIG5ldHdv cmtzIFs8YnI+DQomZ3Q7ICZndDsmZ3Q7IF0mbmJzcDsgJm5ic3A7TWljaGFlbCBSaWNoYXJkc29u LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZu YnNwOyAmbmJzcDsgSW9UIGFyY2hpdGVjdCZuYnNwOyAmbmJzcDtbPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBdJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86bWNyQHNhbmRlbG1hbi5jYSIg dGFyZ2V0PSJfYmxhbmsiPm1jckBzYW5kZWxtYW4uY2E8L2E+Jm5ic3A7DQo8YSBocmVmPSJodHRw Oi8vd3d3LnNhbmRlbG1hbi5jYS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnNhbmRlbG1h bi5jYS88L2E+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7cnVieSBv biByYWlscyZuYnNwOyAmbmJzcDsgWzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0 OyA2bG8gbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzo2bG9AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj42bG9AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG88L2E+PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJ RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8L2E+PGJyPg0KQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB3565F85F6E989972B92045CBD8FA0MN2PR11MB3565namp_-- From nobody Thu Jul 4 07:39:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61BD12007A for ; Thu, 4 Jul 2019 07:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 lsJW9OlT5RF5 for ; Thu, 4 Jul 2019 07:39:33 -0700 (PDT) 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 15684120059 for ; Thu, 4 Jul 2019 07:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562251170; x=1562855970; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=EacuYjuV CfdCLKKR3PQkKWpAutrVR5YZqx7kqkOucJo=; b=GX7uw2L5jvpqTkMxeHdC4hUU kOiZsG4Rbj/P4m6OTU7/ejIxSYgvtaZYaMgMcHHGh1fWlUOl6JPQcgVKDTlaXOuU CGxezOxukQcmuPR70yYepgLyehQM/ic0xh7MTOfY9B3LDFnUjFhCh+Q92/heiGQl 9HCqBpGoAjliIK8Fasw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 04 Jul 2019 16:39:30 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 04 Jul 2019 16:39:30 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006315510.msg for ; Thu, 04 Jul 2019 16:39:30 +0200 X-MDRemoteIP: 2001:470:1f09:495:fc55:9c63:59af:b7ec X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 04 Jul 2019 16:39:30 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1088639881=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Thu, 04 Jul 2019 16:39:28 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <43E3BA9C-8BF8-4C59-9030-13BDFF7A1353@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-p2p-links-03.txt References: <156225099241.12042.14088812528856858770.idtracker@ietfa.amsl.com> In-Reply-To: <156225099241.12042.14088812528856858770.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-links-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 14:39:36 -0000 Hi all, I've posted a new version of this document, with expired some time ago. https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-links/ Only minor edits have been done this time. I still believe this document is useful and in scope of the wg chapter. Regards, Jordi @jordipalet =20 =EF=BB=BFEl 4/7/19 16:36, "internet-drafts@ietf.org" escribi=C3=B3: =20 A new version of I-D, draft-palet-v6ops-p2p-links-03.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-p2p-links Revision: 03 Title: IPv6 Point-to-Point Links Document date: 2019-07-04 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= p2p-links-03.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-= links/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-p2p-links= -03 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -p2p-links Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-p= 2p-links-03 =20 Abstract: This document describes different alternatives for configuring IPv6 point-to-point links, considering the prefix size, numbering choices and prefix pool to be used. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =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 Thu Jul 4 13:19:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84680120225; Thu, 4 Jul 2019 13:19:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 NkW83Xu3503m; Thu, 4 Jul 2019 13:19:12 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 28B5712016E; Thu, 4 Jul 2019 13:19:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FRAABKXh5d/yYyC4dlHAEBAQQBAQcEA?= =?us-ascii?q?QGBVQUBAQsBgUNQgV8DBDMKh1kDhTGJGIJbiU2PJxSBEAMYPAkBAQENAS0CAQE?= =?us-ascii?q?ChD4CglA2Bw4BAwEBAQQBAQEBBAECAmmKNwyDRTkyAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBBQI4OAEBAQEDEigGAQE3AQsEAgEIEQQBAQE?= =?us-ascii?q?eECERHQgCBA4FCBqEawMdAQICm2YCgQgwiF8BAYIiGoJfAQEFhRINC4ISCQkBg?= =?us-ascii?q?SoBi3WBQT6BV4JMPoIagW4+gzqCJowZnXBACQKCF5AQhA6CLIceg3kDijKWYo4?= =?us-ascii?q?JAgICAgQFAg4BAQWBVwYsgVhwFYMngkGDcYpTcoEpjDgBgSABAQ?= X-IPAS-Result: =?us-ascii?q?A2FRAABKXh5d/yYyC4dlHAEBAQQBAQcEAQGBVQUBAQsBgUN?= =?us-ascii?q?QgV8DBDMKh1kDhTGJGIJbiU2PJxSBEAMYPAkBAQENAS0CAQEChD4CglA2Bw4BA?= =?us-ascii?q?wEBAQQBAQEBBAECAmmKNwyDRTkyAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBBQI4OAEBAQEDEigGAQE3AQsEAgEIEQQBAQEeECERHQgCBA4FC?= =?us-ascii?q?BqEawMdAQICm2YCgQgwiF8BAYIiGoJfAQEFhRINC4ISCQkBgSoBi3WBQT6BV4J?= =?us-ascii?q?MPoIagW4+gzqCJowZnXBACQKCF5AQhA6CLIceg3kDijKWYo4JAgICAgQFAg4BA?= =?us-ascii?q?QWBVwYsgVhwFYMngkGDcYpTcoEpjDgBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,452,1557201600"; d="scan'208";a="351190346" Received: from mailauth.avaya.com (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Jul 2019 16:19:10 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2019 16:19:09 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by AZ-US1EXHC01.global.avaya.com (135.11.85.12) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Jul 2019 16:19:09 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.52) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Thu, 4 Jul 2019 15:19:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MUtWxA5vRgsQtarN6IKuET2BKeRenuxX8tqanyHJt7M=; b=JEQRsi61RXrLNlQvblNxJIg7R9ZavYOnfQF9d4TI92CEC9W7m3+uLMrQfWQTtFmsrVix3OhhB1eUTODY7XpuBg+F6VsdvSi1GD9A9cyftWB3pLKN0pJPMR1keIHp54tUcoFSlE8FhTXL0G02a/i+93vOYJ/MxLzSqMaEJwuYe8E= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB3660.namprd15.prod.outlook.com (10.141.166.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Thu, 4 Jul 2019 20:19:07 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::697d:5307:1f7a:79bc]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::697d:5307:1f7a:79bc%6]) with mapi id 15.20.2032.019; Thu, 4 Jul 2019 20:19:07 +0000 From: "Mudric, Dusan (Dusan)" To: Fred Baker CC: 6man <6man@ietf.org>, IPv6 Operations Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AQHVMdZ0QTP2spnzX0G8BrvKPAtN5qa65qtA Date: Thu, 4 Jul 2019 20:19:07 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 13a4b11e-8895-4915-39b2-08d700bcde2f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB3660; x-ms-traffictypediagnostic: DM6PR15MB3660: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1443; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(376002)(39860400002)(396003)(13464003)(189003)(199004)(81156014)(81166006)(71190400001)(8936002)(99286004)(8676002)(71200400001)(54906003)(4326008)(316002)(66066001)(2906002)(55236004)(25786009)(478600001)(53546011)(76176011)(7696005)(14454004)(26005)(33656002)(186003)(6506007)(102836004)(7736002)(52536014)(305945005)(9686003)(256004)(11346002)(446003)(74316002)(53936002)(86362001)(486006)(5660300002)(55016002)(6246003)(76116006)(476003)(229853002)(68736007)(6916009)(64756008)(66556008)(3846002)(66476007)(66446008)(6436002)(66946007)(6116002)(73956011); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB3660; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oUk5WQ1hFcgN7zS8KRo96sTk27iHT+0fujTcwyHiEJR+Abs9Ad65kVpB5ko6xuv//deN+CrzCGXBcBSNQxTumHsxY/Rnir9FAIdViegTFi9ksEt4LBUSJ/0rlwVJx8z8mPc71KXHoggn9gRNwTz2gWsk2psJUCP204QWFmv5/W6g+06jx79DlHgrg/yul6OpacKlOp0tydonXeacFnL+FfFPFMx/eUiExOV7dVaXBzFkzmsPtKgZJXoZ2z25AzamV87W8Yaynja46LVQOkLQVOgzeQCoFvLWHDqeriJLSUb2y/Zz5v3q9cJ00+fCqi9G3UiRar7Wna4VXmsUNYLpCQjfXrKcXAfHFruR4G988LNCkjFje+ZPdM2KY6DtcpDFVWOkBkFptpmx8cyDKjLp5nqmCNUBtwnIYbwuWoOPcoE= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 13a4b11e-8895-4915-39b2-08d700bcde2f X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2019 20:19:07.6623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3660 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 20:19:15 -0000 What is the best reference document for a Translator that facilitates: - IPv4only - to - IPv6only, and - IPv6only - to - IPv4Only=20 clients message exchanges?=20 Is this communication bidirectional or works only from IPv6only-to-IPv4only= client (meaning IPv6only client has to initiate the communication)? How can Translator or DNS64 tell IPv6 only client the IP of IPv4 only clien= t, and vice versa? Thanks, Dusan. > -----Original Message----- > From: Fred Baker > Sent: Wednesday, July 3, 2019 3:32 PM > To: Mudric, Dusan (Dusan) > Cc: 6man <6man@ietf.org>; IPv6 Operations > Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64 >=20 >=20 >=20 > > On Jul 3, 2019, at 12:01 PM, Mudric, Dusan (Dusan) > wrote: > > > > [Dusan] Please clarify how IPv4-only host can reach IPv6 only host, and= vice > versa. Also, how IPv6 only host can know IPv4 address of IPv4 only host, > assuming IPv4 only host is in a public domain? >=20 > Simple. Using a Translator, either at layer 3 or above it. Any other way > doesn't work. > -------------------------------------------------------------------------= ------- > The fact that there is a highway to hell and a stairway to heaven is an > interesting comment on projected traffic volume... From nobody Thu Jul 4 19:21:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A682120179; Thu, 4 Jul 2019 19:21:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 adL2_0vAM1bF; Thu, 4 Jul 2019 19:21:38 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 B648912010F; Thu, 4 Jul 2019 19:21:38 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id a15so9730129qtn.7; Thu, 04 Jul 2019 19:21:38 -0700 (PDT) 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=M/RFvdlV8rwPFY+uY1mVOPKUNPAWi9Cx1t2FCJgNPi8=; b=AbOz+2bpfMpujMR3vUGvx+jqo6UPinBKY537ZlG3vAPxtlDNgIoe9RugSxC7NaKaR6 2FmGifz+bOkLmfAL/gh2nw4j92e6kl9ImI+GN81f4pogp8wUxIYmp2SBUEhdrQnTYaws h+rRx5fBw+doNH4jcNaxsgpYbOEY0nQ/aKEnfqpbjUAMXhV0xs3gi5aiQbZ6R6h8ZawX hZ0Ui/2WVzRQgw0BuxUf1iHClUkbGauQ9XolAxEoYUYC88yVzbCjthwO+nda6T4nbjkC rXRczx2fRtm+4iym/Pr9eXp+HMfdE0riltZfGHtg5OPFCoJYeJcVmDwmILzFr7pqtPwe hE7A== 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=M/RFvdlV8rwPFY+uY1mVOPKUNPAWi9Cx1t2FCJgNPi8=; b=OJM2j5Xe5eBNEwwFtP11FlWRq19cMArsPiaGI4nfhQN/GkMlMa/jifQRBSOWU5oQ0C rSbrehqAhbUKwxu/2i+RDlojUCcMgBJyMyfHGepWD32WmVtujK+OJ1cvH38t0Ic9zHGu 4YShtyncFpfAV5IN1fkqJ6v64Pq3Hjf8OW0Pwy8XDFW7NN9Yf1HmBf9UW8xgFXDEhF0w 2fk4xxJrNfHhzaH3Os9Jn7rET2Fi1yurUJQ/+4FEHfnLIu3S1nkwZd/mC1oCbDykS2RE fcfULj2RgG0pNUynKRiUID6ax0ViC9EbimvHh8/R9LNO8eXgJlxtlNxK847o/rONUX5D EzZA== X-Gm-Message-State: APjAAAWv+9CstOAxakOwNzezoW0LuiBBWHg3bpB6ouIAA6R9+P0XveFi QQD6suMxjzp8DFn5h+VjQIkN8lK8qZBLTMcJpBE= X-Google-Smtp-Source: APXvYqyOF2sU2QmURyLULvpTRc/rPdaF616fyl4XrIhJeFvsSep8vggvyXeyY0wxaN3pdY6OHCp/w3/tluf/6npZ+Fs= X-Received: by 2002:ac8:2e59:: with SMTP id s25mr731474qta.94.1562293297445; Thu, 04 Jul 2019 19:21:37 -0700 (PDT) MIME-Version: 1.0 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: From: Jen Linkova Date: Fri, 5 Jul 2019 12:21:25 +1000 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: Fred Baker , IPv6 Operations , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 02:21:40 -0000 Hi Dusan, On Fri, Jul 5, 2019 at 6:19 AM Mudric, Dusan (Dusan) wrote: > What is the best reference document for a Translator that facilitates: > > - IPv4only - to - IPv6only, and https://tools.ietf.org/html/rfc7755 > - IPv6only - to - IPv4Only https://tools.ietf.org/html/rfc6146 > clients message exchanges? > > Is this communication bidirectional or works only from IPv6only-to-IPv4only client (meaning IPv6only client has to initiate the communication)? > > How can Translator or DNS64 tell IPv6 only client the IP of IPv4 only client, and vice versa? In a nutshell: IPv6-only client asks DNS64 server for AAAA for, let's say, ipv4only.example.net As that server is IPv4-onl, does not have AAAA RR, the DNS64 server synthesise a new AAAA using an IPv6 prefix (usually /96 - the Well-Known Prefix is 64:ff9b::/96) and IPv4 address from the A RR. The algorithm described in rfc6147 So if ipv4only.example.net has an IPv4 address 192.0.2.2, then DNS64 will return 64:ff9b::192.0.2.2 as AAAA RR. The ipv6-only client would initiate a connection to that address . As NAT64 prefix is supposed to be routed to the NAT64 device, that device would translate IPv6 packet to IPv4 packet using the algorithm described in https://tools.ietf.org/html/rfc6052. > > -----Original Message----- > > From: Fred Baker > > Sent: Wednesday, July 3, 2019 3:32 PM > > To: Mudric, Dusan (Dusan) > > Cc: 6man <6man@ietf.org>; IPv6 Operations > > Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64 > > > > > > > > > On Jul 3, 2019, at 12:01 PM, Mudric, Dusan (Dusan) > > wrote: > > > > > > [Dusan] Please clarify how IPv4-only host can reach IPv6 only host, and vice > > versa. Also, how IPv6 only host can know IPv4 address of IPv4 only host, > > assuming IPv4 only host is in a public domain? > > > > Simple. Using a Translator, either at layer 3 or above it. Any other way > > doesn't work. > > -------------------------------------------------------------------------------- > > The fact that there is a highway to hell and a stairway to heaven is an > > interesting comment on projected traffic volume... > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- SY, Jen Linkova aka Furry From nobody Thu Jul 4 20:33:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9370E1200E9; Thu, 4 Jul 2019 20:32:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 myMUU1q4bcOq; Thu, 4 Jul 2019 20:32:42 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 6F7FC1200D7; Thu, 4 Jul 2019 20:32:42 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id z4so6401075qtc.3; Thu, 04 Jul 2019 20:32:42 -0700 (PDT) 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=82gjOTfisl07ESip9DABpzteyxL/Mgl1WCU67frieGc=; b=RDvTNPN+r96lUbuxUUic0zTXL7vvCi4zpaAUfdWjLD+nECWvNwZQvRojwERiT4qYhQ /pUlQ0k2FUYgQDpKT3t3/FS2MY/qpRK5KV9GBoNU5PvsU9xdsNAQ4N5Om/DxYcIzGwNl EuUfRA1ShAvbaVC9MjCaalApuVoVTdwEX5wZf+E/WaXiXFCDc8lEe+7pBDLoKEPQDysr MgIsyt842iGWdkKfTm70GZ3UaTVsiBXL5mx5rDU3pXD09US46+wi3rmC1RDFt23rxOR9 TzjEsk1sA7eUvpgtSL5vKj2ZZzAbkcWLh1eBXrtnd/NCnk1aoRJh6eqUUMMAfkFkhwmj X6WQ== 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=82gjOTfisl07ESip9DABpzteyxL/Mgl1WCU67frieGc=; b=V8dKrtov1zWb5DtfNvRp8aOAdyDVGmlxVPEOw84Brum/MdSO7xB9hcn0qFrEU7b0Bk Iq+L6Ab+vMyUGJypkb1mJRurufGrhaWKiMOEMBiXcYL/79by+eaTWSi1CT4WLPwi4WzN q/hdRl1PpxY+ULeFkFhsGsZ/I0rv/fe9xY7fj0QHCs1h/aqZCiqYY+8PNwyWscstvhP2 7dOIa6xzCGZyqR6XGm1apZIfpGd3fiaTJaGaFefSR6AgLGq/WCsSfEJ2y1YLZayOt3HR q+qzNa5dfwbiENJiV3sr11Sntd2NV8m/PKmCmX9CJbcBetbRazPq0P+9J0wehNZ/rDQB mHog== X-Gm-Message-State: APjAAAVNwaOuaicmuyhx0MYMRRZb4qgeJPs+0T8etiwRCfqWdCJ8Xzb9 naVBASb4COlcHXamPatHolIbFz0JyjDfshjuj4I= X-Google-Smtp-Source: APXvYqyhm8a5rlAFrI/0lTUdsRzvSnKETrx08/bKUvehkd62prENv0nRUR8SUxV3m/WuGb7uGud5luKQkWG9zzcYOZ8= X-Received: by 2002:ac8:2e59:: with SMTP id s25mr876628qta.94.1562297561169; Thu, 04 Jul 2019 20:32:41 -0700 (PDT) MIME-Version: 1.0 References: <5377.1562081856@localhost> In-Reply-To: From: Jen Linkova Date: Fri, 5 Jul 2019 13:32:29 +1000 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org>, 6man <6man@ietf.org>, V6 Ops List , "6lo@ietf.org" <6lo@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [6lo] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 03:32:45 -0000 Hi Pascal, On Wed, Jul 3, 2019 at 6:18 PM Pascal Thubert (pthubert) wrote: > The routers that Michael is talking about are real routers, deployed in large volumes in the field, e.g., in Smartgrid networks. > They are not running ND as RFC 4861/4862 but as RFC 6775/8505, and then operate RPL routing within the ML subnet. > It would be great to have a section that describes that new ND operation and shows how it changes the deal. I'd be happy to help you on that if you need. > There are some hints in https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/. Oh, that's an interesting plot twist ;) Migrating from 4861/4862 to 6775/8505? Sounds like smth we might want to explore as a strategy (while the tactical fixes my draft mostly talks about might be still needed too). I'll re-read RFCs 6775/8505 and will be back to you with some questions later..Thanks for the suggestion! > > -----Original Message----- > > From: 6lo <6lo-bounces@ietf.org> On Behalf Of Jen Linkova > > Sent: mercredi 3 juillet 2019 08:52 > > To: Michael Richardson > > Cc: 6tisch@ietf.org; 6man <6man@ietf.org>; V6 Ops List ; > > 6lo@ietf.org > > Subject: Re: [6lo] ND cache entries creation on first-hop routers > > > > On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson > > wrote: > > > I think that the discussion here is particularly relevant to > > > constrained devices/routers on route-over MESH(RPL,etc.) networks. > > > > > > I also think that for L=0 networks, which RPL creates with RPL DIO > > > messages rather than (just) RAs, and 6LRs that need to support join > > > operations (like draft-ietf-6tisch-minimal-security) this may matter. > > > > Disclaimer: I have very limited knowledge in that area. > > > > > In particular, in the minimal-security case, we need to partition the > > > ND cache such that untrusted (unverified) malicious pledge nodes can > > > not attack the ND cache. > > > > The next version of the draft will have much more details on discussing the > > security considerations indeed. > > > > > The behaviour 2.2.1. Host Sending Unsolicited NA, should probably > > > never flush an old entry out of the ND. > > > > I'd say that the router behaviour for creating a STALE entry upon receiving an > > unsolicited NA should be the same as for creating an entry for any other > > reason (e.g. for receiving an RS with SLLAO). > > The same safety rules shall apply. > > > > > I think that under attack > > > (whether from untrusted pledges, or from p0woned devices already on > > > the network), it is better to prefer communication from existing nodes > > > rather than new ones. 2.2.1.2 mentions this. > > > > I guess your routers do purge old stale entries? > > > > > {typo: > > > -It's recommended that thsi functionality is configurable and > > > +It's recommended that this functionality is configurable and } > > > > Thanks, will fix in -01. > > > > > I didn't really understand 2.2.2: is it exploiting some corner case in > > > the spec, or maybe just some part I am not well clued in about. So > > > maybe an extra paragraph to explain things. > > > > It's just using the standard ND process: when the node B receives an NS from > > node A and that NS contains the node B address as a target address and > > SLLAO contains node A LLA, the node B would respond with NA and would > > create a STALE entry for the node A - > > https://tools.ietf.org/html/rfc4861#section-7.2.3 > > > > > I kinda like the ping all routers trick. > > > > I think it's a hack ;( we do have a mechanism for communicating neighbours > > addresses/reachability called ND. It would be nice to utilise its machinery. > > Pinging creates additional overhead on routers and could get filtered. > > But I'd not be surprised if it's the only way we have realistically to mitigate the > > issue.. > > > > > > > > Jen Linkova wrote: > > > > I wrote a short draft to discuss and document an operational issue > > > > related to the ND state machine and packet loss caused by how routers > > > > create ND cache entries for new host addressed: > > > > > > > > > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > > > > > > (taking into account some vendors have implemented one of the > > proposed > > > > solution already, I guess it's a well-known problem but it might still > > > > worth documenting) > > > > > > > Comments are appreciated! > > > > > > > -- > > > > SY, Jen Linkova aka Furry > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > -------------------------------------------------------------------- > > > > > > > > > -- > > > Michael Richardson , Sandelman Software Works > > > -= IPv6 IoT consulting =- > > > > > > > > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo -- SY, Jen Linkova aka Furry From nobody Thu Jul 4 20:50:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DFE1200E9 for ; Thu, 4 Jul 2019 20:50:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 RZCPC3ajfFau for ; Thu, 4 Jul 2019 20:50:42 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 547E21200D7 for ; Thu, 4 Jul 2019 20:50:42 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id s145so3368201qke.7 for ; Thu, 04 Jul 2019 20:50:42 -0700 (PDT) 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=KdhAnAu4FIkxIsbaddc9iCCDRALaFZwjnTWDqAGDXHc=; b=O+wd1+HNRwohIIygWP3Dl2187cYE9/xr0eSl6KyMdiqRjhcJlmhSNAiZH+FKr4QcbA B1GvvSvBSeqPO4IOw0qGHC8MoDt72StX3Zvx+pTSM/YCpr3qYM8/oeLccZ+ALyB02t5N oCf+yu52JyA3XNUauIw2pooutljINQ3R1UpLdBLrLMuOYT4hiDFilN5CekiCOSxv4wzW BBbViDEa9fUojM+SXyUUOVy79KHdfNtcxvJgWxZ4kerD9eX53tghHW0W/TvG9eJnJDmK IzOmJfIPBIngbfiwnpG22ek/Xv3XhX/xaHY8bt0Oas2q5ScIlqBPHWdBQQ0MHfOdLxQ3 ZAPg== 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=KdhAnAu4FIkxIsbaddc9iCCDRALaFZwjnTWDqAGDXHc=; b=T7MdPpN3EEj11Zuv3IhVhnN1r3yNqk+7tCZOHgy0MpOtJw6f9E/j8mh5TKcOGZj6gZ tvxmLexh1g1j25lr2+Z3G3+0uckhBPcWqjpztll45iH7tJL9UrOM71AAiDjJ3CJD0P1j FYhNMYRT9VpEh73BWYm92fNiBAZQST6q+E4h4kBWcEecF6pdbAfEbcvZCmXn2lM/P4Vi 0TXmnkMXfYmkiWNHUFn9FaUaG2xitRBDap52eNNK4v7O32NUoX293I5533ggnBaq/u6c O2unxWe6X4NUV/4KGmYupMJWnWV6O7TjGVhFkYoQT95WGbFophnxjg9mHG8RnlO/ZwpF I8aA== X-Gm-Message-State: APjAAAVagvpHIwOF2YMgUhpundzSqzTmG3SYrzm/lVZVoCID7Z2/w3lW Q58NU08G+hyvY7gqveRvu628p75fOe29g3nhYjQ= X-Google-Smtp-Source: APXvYqzLGrARDtSD8JYPCXX17UfXZFiihpriC1BToFsGokUXSc0Z7bljFY90M4SYgO5ffl06ClPz7tsfU6lGACYSNVY= X-Received: by 2002:a37:a04b:: with SMTP id j72mr1339425qke.277.1562298641265; Thu, 04 Jul 2019 20:50:41 -0700 (PDT) MIME-Version: 1.0 References: <162e470d-a1da-c100-3806-e4ab7640f5e2@gmail.com> In-Reply-To: <162e470d-a1da-c100-3806-e4ab7640f5e2@gmail.com> From: Jen Linkova Date: Fri, 5 Jul 2019 13:50:29 +1000 Message-ID: To: Alexandre Petrescu Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 03:50:44 -0000 Hi Alexandre, On Wed, Jul 3, 2019 at 10:49 PM Alexandre Petrescu wrote: > I am reading through this draft trying to identify whether the indicated > ND problem (router lacking ND entry for host's GUA makes drop first > incoming packet to GUA) happens on a ptp link like 4G, or on a shared > link like WiFi. > > On what was it tried? Well, I observed it on WiFi (I guess you should be able to see the issue in Montreal). > > The router ND cache, however, might contain an entry for the device > > link-local address (if the device has been performing the ND process > > for the roiter LLA) but there are no entries for the device GUA. > > But has the host DADed (sent NAs) when it formed its GUA? I guess that > would be heard by router, to create that ND cache entry. 1) Those NSes are sent from unspecified address 2) they are sent to the solicited node mcast address so routers might not even receive them.. -- SY, Jen Linkova aka Furry From nobody Thu Jul 4 22:29:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CB6120234; Thu, 4 Jul 2019 22:29:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 UlrChTO7U1CP; Thu, 4 Jul 2019 22:29:02 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 F41C312021F; Thu, 4 Jul 2019 22:29:01 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id n11so10036032qtl.5; Thu, 04 Jul 2019 22:29:01 -0700 (PDT) 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:content-transfer-encoding; bh=udmP2Ysao4p8o70rUtZlnq1lTMxkHH/Vg3b21GyeZ2I=; b=m48mhX57qU0+hDvbafPIQb0x7hYir7luZiOy4OaqOO+2HatgtEC8vNu/vHVRzOiu9d n6V56fHxamyfIA8e21PcC2krTncq+Xu7cvYxzEbRUQNgocjJG9888FVm16VvA8p4+LkR bOYIk+aGAp9zQvAbjIYh5vswMMmeoYOspd7X13zBU+KsHRn2fjoV/tURVBidc84BwrBy j3k1Cv3tOaTDF75FAVfR4uwYx4iFaMs6uTya5oShM5eKK1NnrCyPu0atOKpifuJsTTju SzwsVwOJiAlcg+DGY/kPtxYwC9b1aERcubJfTsPX3UYmMwtvKzBrI5s2/1zPNkDMchdK cJzA== 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=udmP2Ysao4p8o70rUtZlnq1lTMxkHH/Vg3b21GyeZ2I=; b=VdpKUFYTuw02hwH33CySTEElGk9bXA/+hekaORVF3JbI0nahEOCshMNJcS8LuHqPzP c/5pLO9HfIi37KFURe00ROQqD5xS9/5tMvHWyBK0Bnlfq7U2HNe8GOhtbuQDcuLaWDcf m1IQGS+X+iJCONpBCYWtoqvpQABnJ4QibU68WNRb5PtvuXGGT0FONsMyo3Aq+nsjrZJ2 fxitzBlKIRerAHsFtS3RsXUSjchExPoUNrIrclXQxS5D5dDmT4q3uY7kajbldCGIqbx9 FaQTzp4SCgrDpyNItNTOS1QPNY3IzCyBcsDn1mO9p2dX+zWZ6cpzRxMT/lu1gm01m5sb V7Rw== X-Gm-Message-State: APjAAAVEWbw13he2EYBfXPcRKeXyGyODonjv+HbORPoECJ5ZjFyTTVOW 3jehVHaBxFgLPyKIcK0O+Ro9b2kSP5Qm9J+0sZk= X-Google-Smtp-Source: APXvYqx7ZySNvRFRtQz4Xw9o6uLsRnswj3GArZ5uvYCeUP+40R3pb24BV1oGCOZTfm9hA1Xgu0PLavgLLpVdytjJTZc= X-Received: by 2002:a0c:91bc:: with SMTP id n57mr1650469qvn.141.1562304540721; Thu, 04 Jul 2019 22:29:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Fri, 5 Jul 2019 15:28:48 +1000 Message-ID: To: "Pascal Thubert (pthubert)" Cc: V6 Ops List , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 05:29:04 -0000 Hi Pascal, On Wed, Jul 3, 2019 at 10:55 PM Pascal Thubert (pthubert) wrote: > In Introduction: > "(previously unseen by the router)" > Another case is that the cache may have been flushed. The same issue will= happen again. I'll update the sentence to include that case as well. > In 2.2.3.2: > " > o Would not work for the host optimistic addresses ((see section 2.2 > of [RFC4429] which prohibits using an Optimistic Address as the > source address of a Router Solicitation with a SLLAO. > " > The "would not work" is exaggerated What I meant is that it's devices are prohibited to do so by RFC4429. I'll rephrase it. >since the behavior of the router c/should be to lookup the source of the R= S to answer with a unicast RA. If the RS does not contain SLLAO, yes. However in that case I'm not sure if the delay in sending the RA would impact the cache entry creation (the issue we discussed with Jinmei-san in this thread). Thanks for pointing this out, I'll update the text to discuss both options - with and w/o SLAAO included in RS. > Some old implementations would always answer with a broadcast RA but hope= fully things have evolved with the realization that broadcast may have its = own issues, in particular with wireless and overlays. Most enterprise-scale router vendors support rfc7772 now, so I hope that unicast solicited RA is less of a problem nowadays.. >So this technique may work if the router responds unicast and the optimist= ic node also introduces a small delay before firing its probes to cover for= the RA delay. Yes, that's the concern. I'll update the text accordingly, thanks! > In 3. Recommendations > I do not agree with the recommendation, because: > - the host has no control or guarantee about whether the router will mai= ntain the cache and for how long > - multicast NA may be lost, more chances of that if the router is wirele= ss. You may want something a bit more robust with an acknowledgement and a = lifetime, see RFC 8505. > - the all-routers is still a L2 broadcast on Ethernet and Wi-Fi. We are a= ctually trying to deprecate the NA(O) at the end of the autoconf sequence. > - the proposed knob would have the routers learn all addresses of all hos= ts including those that do not get traffic from that router. This augments = the chances of cache saturation, which recreates the problem you want to av= oid. Hmm...In the scenario I'm thinking about (a WiFi segment in an enterprise network, for example) all hosts are getting traffic from all routers. You are right it might get tricky in multihomed/mPVD case. What should be noted here is that at least one major router vendor has this knob implemented and it's actively used AFAIK. So having a knob has been proved useful - it does not have to be a sole solution through.. > Also note that the fiddling smart wireless well as smart fabrics may lear= n the location of the address from snooping the ND activity (see https://to= ols.ietf.org/html/draft-bi-savi-wlan). A sense if order of events like a se= quence counter / time stamp is important for devices that move quickly. See= for instance the discussion in https://tools.ietf.org/html/draft-ietf-rift= -rift-06#section-5.3.3.1 . Thanks for the references, I'll check them out! > All in all there' s a limit to stretching old designs and a time where a = new one is needed. Ask plane makers... It seems like we might do two things here: - explore the option of using RFC8505 (strategic solution); - have some tactical workarounds to deal with legacy hosts. > > -----Original Message----- > > From: v6ops On Behalf Of Jen Linkova > > Sent: mardi 2 juillet 2019 17:03 > > To: V6 Ops List > > Cc: 6man <6man@ietf.org> > > Subject: [v6ops] ND cache entries creation on first-hop routers > > > > Hello, > > > > I wrote a short draft to discuss and document an operational issue rela= ted to > > the ND state machine and packet loss caused by how routers create ND ca= che > > entries for new host addressed: > > > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ > > > > (taking into account some vendors have implemented one of the proposed > > solution already, I guess it's a well-known problem but it might still = worth > > documenting) > > > > Comments are appreciated! > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Thu Jul 4 23:06:46 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659E81200F6; Thu, 4 Jul 2019 23:06:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Y5wv3UPxaFnp; Thu, 4 Jul 2019 23:06:36 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 891621200CE; Thu, 4 Jul 2019 23:06:36 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id n11so10100975qtl.5; Thu, 04 Jul 2019 23:06:36 -0700 (PDT) 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=/Y1MxRWvEoRlaA9T2bl/9oPu206CWrIFsXclTvpXwCI=; b=S7XfzzG2h8/4oW4KlACPcmISdzOUiKEc4fIwe7/hUwQwl9ejD294qvJr9Mg8sdQaxb 5iX7xxIsj7IIxeFzTKK68kd5+z4WX59j4fCmSL7GPL+/x9yxLdELFExXlLdZqpEGASdF hJtd6pY020XwVIRKj2sLx0Z2+rKNNsJb90YfmgTClsn2B+V+dmW1E5rYKLBgVZvOo5UU fOYB7kNfLxfW7oMeCh+D1VV547FNnBmEll17A+I4FHkwt7+rZMdSeAhk4eZ7ojWmQSNM QF2URB+aNK+iBPZWsMVPdWvf2ogSVW0aB7Nhv5bknq+uItn7ROuw7CvdaP4OX1p1O1DC nZkg== 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=/Y1MxRWvEoRlaA9T2bl/9oPu206CWrIFsXclTvpXwCI=; b=j6bu6++BAkP4+zqqyUcxkL4BA0wr1JJZbQEkhbpziEB4n8s8YJ/LymKvLzW+ON5YQA Xk8ztdnNft8RQR3WcgcGa83L2Ze6Me32uxYoVSx9h+M93g5pch5PUwJzZLJMFaMLM0MK KR2FdjQy0gaO8QPoAhtPN92IPwYfZ0tWYwI5Zpvq6lN2p7fAm0YZn/rNgEFRsz5KWuan N5mtNlFo22nLCfIF+IwYp1g84S1J7j3zz1ZXZ9hWrAlUANIOFpqMpsnr/FP5Rhx7B6SA AjRuz/t4O/NDIvJG21wPF5FihvvS3x6o8xaZhr12MNt/VsycFHVddeOpW/xkxAVA5mEG JSig== X-Gm-Message-State: APjAAAVXl3rGxIoJn5OR/cZdnsH+mcziagcepyC6QNKl+aCmcbH5l8s8 5ho7dDPQderGIOuGr4I3QGXh922rRccqr9+n5/G+buxD+jE= X-Google-Smtp-Source: APXvYqwtIFel5gWp09/4wJVGHuX848c/3kTZ//Oi8f1uzNOVcmeVNig8jZiXw84TvPcalowaQc0A0C7okd96LNYBum8= X-Received: by 2002:ac8:7104:: with SMTP id z4mr1281161qto.52.1562306795342; Thu, 04 Jul 2019 23:06:35 -0700 (PDT) MIME-Version: 1.0 References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> <4250.1562178592@localhost> In-Reply-To: <4250.1562178592@localhost> From: Jen Linkova Date: Fri, 5 Jul 2019 16:06:23 +1000 Message-ID: To: Michael Richardson Cc: V6 Ops List , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 06:06:39 -0000 On Thu, Jul 4, 2019 at 4:29 AM Michael Richardson wrote: > Are we seeing neigh-cache exhaustion attacks on IPv6 capable WIFI today? Good question. I guess some people might. I'd suspect that IPv6 attacks are not very common still but it will change eventually. Enterprise networks could see less of ND-exhaustion attacks because many of those networks have stateful firewalls in front of the first-hop routers. > 5-10 seconds seems really high... it is really explained by just the > pathology you described? Yes, because as soon as the NC entry appears in the router cache the issue goes away. So users normally complain if they have not connected the particular device to the network for a while. > Is it because the probes are not retried soon enough after the first set failed? Some probers have an exponential backoff. https://tools.ietf.org/html/draft-linkova-v6ops-nd-cache-init-00#section-2.4 >Or is it because there are NC exhaustion? No, there is no exhaustion. At least in the cases I've observed so far. -- SY, Jen Linkova aka Furry From nobody Thu Jul 4 23:34:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9431F120234 for ; Thu, 4 Jul 2019 23:34:33 -0700 (PDT) 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, 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 header.b=MwlvoBbd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NtqBvorN 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 9yyJEPZFF6Zw for ; Thu, 4 Jul 2019 23:34:31 -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 7EAA5120223 for ; Thu, 4 Jul 2019 23:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8507; q=dns/txt; s=iport; t=1562308471; x=1563518071; h=from:to:subject:date:message-id:mime-version; bh=6SBmoBPZjyRoG60Vd+HV+s5eEn26/Pkv0YQ9k/MKFiI=; b=MwlvoBbdkOQKJdvrmmU9koqjnR9ArT6FwTDzzZiQfAyas8diKgs2dVCn X00MSImuGsRuNhnbenVVtUylhTq2OcRkOdZJYL3nOjwiQYmA0jpDWY7LA FPG/r1FoTWp6LYbVpqMx+vjOOrufA77dsUwJdFF/N95Jwpdk8hHSqwz8c U=; IronPort-PHdr: =?us-ascii?q?9a23=3Acw9rFx1ZfQwRDwZRsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBFPqKvXpYgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHBgAs7h5d/5tdJa1lHgEfBgeBTgK?= =?us-ascii?q?BEy9QA2pVIAQLKIQcg0cDjklMlQGEVIEugSQDVAkBAQEMAQEtAgEBhFmCFSM?= =?us-ascii?q?0CQ4BAwEBBAEBAgEFbYo3DIVjEQoTAQE4EQFKAgQwJwQ1gwABgR1NAx0BApp?= =?us-ascii?q?jAoE4iGBxgTKCeQEBBYJHgkcYghIJgTSEcoQkgkkXgUA/gTgfilgygiaOaoR?= =?us-ascii?q?9lmIJAoIXA5QAG5d4pGsCBAIEBQIOAQEFgVA4gVhwFWUBgkGGMopTcoEpjVs?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.63,454,1557187200"; d="scan'208,217";a="576952197" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jul 2019 06:34:29 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x656YUK3014301 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 Jul 2019 06:34:30 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 01:34:29 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 01:34:28 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 5 Jul 2019 01:34:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6SBmoBPZjyRoG60Vd+HV+s5eEn26/Pkv0YQ9k/MKFiI=; b=NtqBvorN57b9/bdx9zhkWH+NfAb99QY+rrkUiXwaShGot0HTgcM9vXZrxEAxOEDt0UZ7K01KtGB/o+Ibrlo3ZiZ3Wd/X8Gcp03Y1/AOCS+ijguhQP0jGzxViaEQe+WxD/Ljs0KfNnrHK8ksHSsydUr2yeIq/DqgSWlCJCyMtkh0= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3757.namprd11.prod.outlook.com (20.178.253.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 06:01:19 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474%6]) with mapi id 15.20.2032.019; Fri, 5 Jul 2019 06:01:19 +0000 From: "Eric Vyncke (evyncke)" To: V6 Ops List Thread-Topic: Some comments on draft-palet-v6ops-p2p-links Thread-Index: AQHVMvcQfaLintPgykKGMA8XahhdfQ== Date: Fri, 5 Jul 2019 06:01:19 +0000 Message-ID: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:a9bd:5b55:be3a:6a76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19eb4b9d-0549-4ae9-0bc0-08d7010e335a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3757; x-ms-traffictypediagnostic: MN2PR11MB3757: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(39860400002)(366004)(346002)(136003)(189003)(199004)(129404003)(790700001)(66476007)(71200400001)(6306002)(25786009)(478600001)(316002)(54896002)(36756003)(58126008)(6486002)(53936002)(86362001)(33656002)(6436002)(71190400001)(6512007)(73956011)(91956017)(66946007)(68736007)(66446008)(5660300002)(76116006)(66556008)(64756008)(8936002)(81166006)(102836004)(46003)(486006)(256004)(186003)(6116002)(476003)(6916009)(6506007)(81156014)(8676002)(99286004)(7736002)(2906002)(2616005)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3757; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DTNhb/U8N6BRHxxuM41V2FYHS31LefX1s5LOdOaHsDFkYeLaNTVjBTjDWxLrXg5jBnuyLtcsenXcpHQXHD+9H5TK2Etv2q5LIVlcLOI5GN5IwLzCTzCPxVtJn9BxvBEi2DYtGbplZrkLoB70+WetFtzJQzXossg0hjAhn/Na0inQVQ6UgHSjxSPbMKQJV9K2NjATY9ljozg6+KZacM+FGlRq0i1vVjimzEAKS3T1RxWsrClIcCACl//WP+PhcT+yBXTiG1gPrn9cdYNYyU1jTCQdWR47BcRXB2/vX66xDrd5NEZtBwR7ht2Kcrr8IIFnOwf0+bwjRX40vGEKpGW+ivy+GzFy2VQe+YH1I/qfW3zKa53XFZWOOYgXsgLnLsIsyl0T7pxegL0EWndETLRZ4s+wUN/gHhHfnWPWOfc/R/E= Content-Type: multipart/alternative; boundary="_000_A9F6957C6E53424CA0C0C583A8915A9Cciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 19eb4b9d-0549-4ae9-0bc0-08d7010e335a X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 06:01:19.7674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3757 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: [v6ops] Some comments on draft-palet-v6ops-p2p-links X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 06:34:34 -0000 --_000_A9F6957C6E53424CA0C0C583A8915A9Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSm9yZGkNCg0KSnVzdCByZXZpZXdlZCB5b3VyIEktRCBhbmQgSSBoYXZlIHNvbWUgY29t bWVudHMuDQoNCkluIHNlY3Rpb24gMy4yLCB5b3UgdGFsayBhYm91dCB0aGUg4oCYbWl0aWdhdGlv bnPigJkgYnV0IGl0IHdvdWxkIGJlIG5pY2UgdG8gYnJpZWZseSBtZW50aW9uIHRoZSBwaW5nLXBv bmcgYXR0YWNrIGJlZm9yZS4NCg0KSW4gc2VjdGlvbiAzLjMsIGRvIHlvdSBoYXZlIGRhdGEgYmFj a2luZyB0aGUgYXNzdW1wdGlvbiB0aGF0IC8xMTIgYW5kIC8xMjAgYXJlIHVzZWQgb24gUDJQIGxp bmtzPw0KDQpCVFcsIDMuNCBpcyBteSByZWNvbW1lbmRhdGlvbiBpbiBtb3N0IG9mIHRoZSBjYXNl cyA7LSkNCg0KSW4gc2VjdGlvbiA0LCBzLyBkaWZmZXJlbnQgdW5pY2FzdCBhZGRyZXNzaW5nIHR5 cGVzLyBkaWZmZXJlbnQgdW5pY2FzdCBhZGRyZXNzaW5nIHNjb3Blcy8gID8NCg0KSSBhbSBhZnJh aWQgdGhhdCBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoYXQgaXMgbWVhbnQgaW4gdGhlIDJuZCBhbmQg M3JkIHBhcmFncmFwaCBvZiBzZWN0aW9uIDQuMy4gTW9yZSBkZXNjcmlwdGlvbiBmb3IgcGFyYWdy YXBoIDMgb2Ygc2VjdGlvbiA2IHdvdWxkIGFsc28gYmUgd2VsY29tZS4NCg0KU2VjdGlvbiA2LjEs IEkgaGF2ZSBhbHNvIHNlZW4gOjphIGFuZCA6OmIgYXMgdGhpcyBhbHNvIHdvcmsgb24gLzEyNy4g QmVmb3JlIHRoYXQgdGhlIDo6MiBoYXMgNjIgYml0cyBvZiBsZWFkaW5nIHplcm9lcyBhbmQgbm90 IDYzIDstKQ0KDQpTZWN0aW9uIDYuMiwgeW91IHNob3VsZCBwcm9iYWJseSB1c2UgLzY0IHJhdGhl ciB0aGFuIDIwMDE6ZGI4OmFhYWE6OjEvNDgNCg0KSXMgdGhlcmUgYW55IHJlYXNvbiB3aHkgdGhl IGxhc3Qgc2VjdGlvbiBpcyBvbmx5IGFib3V0IC82NCBhbmQgbm8gbW9yZSBhYm91dCAvMTI3ID8N Cg0KWW91IG1heSB3YW50IHRvIHRoaW5rIHRvIHJlbW92ZSBSRkMgNjE2NCwgNzYwOCBhbmQgNzcw NyBmcm9tIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlcyBhcyB0aGV5IGFyZSBtb3JlIGluZm9ybWF0 aXZlIGltaG8uDQoNCkhvcGUgdGhpcyBoZWxwcw0KDQotw6lyaWMNCg0KDQo= --_000_A9F6957C6E53424CA0C0C583A8915A9Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <980CA7A0EC8419458F0708EBC67437E0@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlbGxvIEpvcmRpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SnVzdCByZXZpZXdlZCB5b3VyIEktRCBhbmQg SSBoYXZlIHNvbWUgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5JbiBzZWN0aW9uIDMuMiwgeW91IHRhbGsgYWJvdXQgdGhlIOKAmG1pdGlnYXRpb25z 4oCZIGJ1dCBpdCB3b3VsZCBiZSBuaWNlIHRvIGJyaWVmbHkgbWVudGlvbiB0aGUgcGluZy1wb25n IGF0dGFjayBiZWZvcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5JbiBzZWN0aW9uIDMuMywgZG8geW91IGhhdmUgZGF0YSBiYWNraW5nIHRoZSBhc3N1bXB0aW9u IHRoYXQgLzExMiBhbmQgLzEyMCBhcmUgdXNlZCBvbiBQMlAgbGlua3M/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CVFcsIDMuNCBpcyBteSByZWNvbW1lbmRhdGlv biBpbiBtb3N0IG9mIHRoZSBjYXNlcyA7LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkluIHNlY3Rpb24gNCwgcy88L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4NCmRpZmZlcmVudCB1bmljYXN0IGFkZHJlc3NpbmcgdHlwZXMvPC9zcGFuPiA8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ZGlmZmVyZW50IHVuaWNhc3QgYWRkcmVzc2lu ZyBzY29wZXMvJm5ic3A7ID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkkgYW0gYWZyYWlkIHRoYXQgSSBkbyBub3QgdW5kZXJzdGFuZCB3aGF0IGlzIG1lYW50IGlu IHRoZSAyPHN1cD5uZDwvc3VwPiBhbmQgMzxzdXA+cmQ8L3N1cD4gcGFyYWdyYXBoIG9mIHNlY3Rp b24gNC4zLiBNb3JlIGRlc2NyaXB0aW9uIGZvciBwYXJhZ3JhcGggMyBvZiBzZWN0aW9uIDYgd291 bGQgYWxzbyBiZSB3ZWxjb21lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+U2VjdGlvbiA2LjEsIEkgaGF2ZSBhbHNvIHNlZW4gOjphIGFuZCA6OmIgYXMgdGhpcyBh bHNvIHdvcmsgb24gLzEyNy4gQmVmb3JlIHRoYXQgdGhlIDo6MiBoYXMgNjIgYml0cyBvZiBsZWFk aW5nIHplcm9lcyBhbmQgbm90IDYzIDstKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+U2VjdGlvbiA2LjIsIHlvdSBzaG91bGQgcHJvYmFibHkgdXNlIC82NCByYXRo ZXIgdGhhbiAyMDAxOmRiODphYWFhOjoxLzQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5JcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB0aGUgbGFzdCBzZWN0aW9uIGlz IG9ubHkgYWJvdXQgLzY0IGFuZCBubyBtb3JlIGFib3V0IC8xMjcgPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WW91IG1heSB3YW50IHRvIHRoaW5rIHRvIHJlbW92 ZSBSRkMgNjE2NCwgNzYwOCBhbmQgNzcwNyBmcm9tIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlcyBh cyB0aGV5IGFyZSBtb3JlIGluZm9ybWF0aXZlIGltaG8uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5Ib3BlIHRoaXMgaGVscHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi3DqXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_A9F6957C6E53424CA0C0C583A8915A9Cciscocom_-- From nobody Thu Jul 4 23:52:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170CB12023F for ; Thu, 4 Jul 2019 23:52:16 -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, 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 header.b=EJ0iJgBe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eFH+gj8s 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 YQAq-eSWQaVs for ; Thu, 4 Jul 2019 23:52:14 -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 CCD0A120234 for ; Thu, 4 Jul 2019 23:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4140; q=dns/txt; s=iport; t=1562309533; x=1563519133; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iRgvmqeJJgwAhnzQI6a6TjY/16GEPDRxi8ladTLmLVM=; b=EJ0iJgBed2n/0TTVQ9mU/UODl3fQjuQki8/ez1qh5LtF/95l34UJp/DJ Nw60AnoQFVx5TYykMs7T9SIw/bGNs2a6AsOOVPmZEYyoJ/ZOEwCW6htYn z6+VNqlWgYhBYJrV8gVeorL3VACv310uqpnpqjlFu/VmYSSjWuA6wC5lo E=; IronPort-PHdr: =?us-ascii?q?9a23=3Auq3vOxxLWDp7x6TXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIF1z9J/3nRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClAABW8h5d/5FdJa1cCh0BAQUBBwU?= =?us-ascii?q?BgVQHAQsBgUNQA2pVIAQLKIQcg0cDjkmCW4lNjXmBLhSBEANUCQEBAQwBARg?= =?us-ascii?q?LCgIBAYRAAheCFSM1CA4BAwEBBAEBAgEFbYo3DIVKAQEBAQIBAQEQEQQNDAE?= =?us-ascii?q?BKwELAQ8CAQgOCgICJgICAh8GCxUQAgQOBRsHgwABgWoDDg8BDpp9AoE4iGB?= =?us-ascii?q?xfzOCeQEBBYEyAYEUgkcNC4ISAwaBDCgBhHGGbReBQD+BOB+CTD6CGkcBAYE?= =?us-ascii?q?uAQcFBgE2gnMygiaMIoJImx9ACQKCF4V4ihiDcxQHgiyHHop/gy+WYo4JAgQ?= =?us-ascii?q?CBAUCDgEBBYFSATVncXAVOyoBgkGCQYNxhRSFP3KBKYsJAQQKF4IsAQE?= X-IronPort-AV: E=Sophos;i="5.63,454,1557187200"; d="scan'208";a="291574327" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jul 2019 06:52:12 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x656qCLC019988 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Jul 2019 06:52:12 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 01:52:11 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 02:52:10 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 5 Jul 2019 02:52:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iRgvmqeJJgwAhnzQI6a6TjY/16GEPDRxi8ladTLmLVM=; b=eFH+gj8sUAoRpsq3xIFvwTJ8Qf1mQ4KsdxhCxKB1ub+Vm1t5l2pDcwJgftaZli3B3Aw5i7nww5f1Tw83l0Fxs7k9CEHYpKQyXEt+AKvIpTssbUCp4gIqchZKd4mxVKgyxom1cCr6h4fgQ5LPm/KD3B6N0YYFBdgYUI/fZGGtNTA= Received: from BY5PR11MB4136.namprd11.prod.outlook.com (10.255.163.158) by BY5PR11MB4086.namprd11.prod.outlook.com (10.255.160.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Fri, 5 Jul 2019 06:36:29 +0000 Received: from BY5PR11MB4136.namprd11.prod.outlook.com ([fe80::6559:d6f6:f9f1:ed5]) by BY5PR11MB4136.namprd11.prod.outlook.com ([fe80::6559:d6f6:f9f1:ed5%5]) with mapi id 15.20.2052.010; Fri, 5 Jul 2019 06:36:29 +0000 From: "Eric Vyncke (evyncke)" To: Jen Linkova CC: V6 Ops List Thread-Topic: [v6ops] ND cache entries creation on first-hop routers Thread-Index: AQHVMOfiGUon9XU27EmyGEMXjU6GfKa7aBe3gABPkwA= Date: Fri, 5 Jul 2019 06:36:28 +0000 Message-ID: References: <162e470d-a1da-c100-3806-e4ab7640f5e2@gmail.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:b140:b5db:3aad:865b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e20eff75-f1e3-45a3-a2c5-08d701131c9a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BY5PR11MB4086; x-ms-traffictypediagnostic: BY5PR11MB4086: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(346002)(366004)(39860400002)(189003)(199004)(5660300002)(71190400001)(71200400001)(7736002)(2906002)(102836004)(4326008)(1411001)(33656002)(46003)(186003)(58126008)(316002)(66446008)(64756008)(66556008)(66476007)(8936002)(6916009)(86362001)(73956011)(81166006)(14454004)(66946007)(81156014)(256004)(486006)(8676002)(66574012)(305945005)(11346002)(446003)(476003)(2616005)(91956017)(76116006)(14444005)(6116002)(478600001)(76176011)(99286004)(68736007)(6306002)(6436002)(53936002)(6512007)(6486002)(966005)(25786009)(6506007)(229853002)(53546011)(6246003)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB4086; H:BY5PR11MB4136.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JDMAWzpvHDcN6X2+Twj+O4qgMa7RUp4y4kYjOHXInpd5cjsupw3VlCbCW/rKQdWZ8rfiwZR5joYVI25x2A3Uom9Kh+qgdnVOimS+R7V7LxOa0+eYMjQgHa4cSSx+BlhFkJLU/+AWMER5iH17mJtmdNqWEqcO/1VgbEAnRC0lETMnEM2AQ6nfp0cocqcdk3rJ3avsb/6eNDTddX2wc2lOcXklrDVl05x6yJBpmQLOWUwumQ5TK4qituPvHt7HnJmxy54Iaotw+dsSlBI8F5TZpyWcN5mXDhdHYZMnfNeSy7BDX1kAd4POFYH00Nkkdx4ePm2weDZbMnTgqeAr7uo5EFxUxYPBJ0N/WrsRYbTa+zU+7rKDUms8fWmhLyzAojEi/PbxR2aM3Srml80ANSTbosVDz0dlwePKXd4ZtUsRsI4= Content-Type: text/plain; charset="utf-8" Content-ID: <6B5EE471FFF08541A4283DC7CAD363C3@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e20eff75-f1e3-45a3-a2c5-08d701131c9a X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 06:36:29.0218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4086 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 06:52:16 -0000 SGVsbG8sDQoNClRoYW5rIHlvdSBmb3IgeW91ciBkcmFmdCwgdGhpcyBpcyBpbmRlZWQgYSBwcm9i bGVtIGluIHNvbWUgZGVwbG95bWVudHMuIChzdWNoIGFzIGluc3RhbnRpYXRpbmcgcmFwaWRseSBh IGh1Z2UgYW1vdW50IG9mIHNob3J0LWxpdmUgY29udGFpbmVycyBoYXZlIGVhY2ggdGhlaXIgb3du IEdVQSkuDQoNCkluIDIgZGF5cywgeW91ciBJLUQgaGFzIGNyZWF0ZWQgbWFueSBlbWFpbCBtZXNz YWdlcyB3aXRoIHByZXR0eSBnb29kIHF1ZXN0aW9ucywgc28sIHRoZSBiZWxvdyBjb21tZW50cyBt YXkgYWxyZWFkeSBiZWVuIHdyaXR0ZW4gYW5kIHJlcGxpZWQgdG8uLi4NCg0KQlRXLCBwbGVhc2Ug cmVmZXIgdG8gODE3NCBpbiBhZGRpdGlvbiB0byBSRkMgMjExOS4NCg0KSW4gc2VjdGlvbiAyLjIu MSAobGVhcm5pbmcgZnJvbSB1bnNvbGljaXRlZCBOQSksIHMvIHNvbWUgcm91dGluZyBwbGFmb3Jt cyBoYXZlIGltcGxlbWVudGVkLyBzb21lIHJvdXRpbmcgIGFuZCBzd2l0Y2hpbmcgcGxhdGZvcm1z IGhhdmUgaW1wbGVtZW50ZWQvDQoNCkluIHNlY3Rpb24gMi4yLjMuMiwgSSBhbSB1bnN1cmUgd2h5 IHRoZSByYW5kb20gZGVsYXkgb2YgdGhlIFJBIGhhcyBhbiBpbXBhY3QgaGVyZS4gQW5kIEFGQUlL IGl0IHRoZSByYW5kb20gZGVsYXkgaXMgZm9yIHRoZSBwZXJpb2RpYyB1bnNvbGljaXRlZCBSQS4g U2FtZSBjb21tZW50IGFzIEppbm1laS1zYW4uDQoNCkluIHNlY3Rpb24gMi41LCB5b3UgbWF5IHdh bnQgdG8gYWRkIGFub3RoZXIgJ3NvbHV0aW9uJyByYXRoZXIgdGhhbiBrZWVwaW5nIHRoZSBmaXJz dCBwYWNrZXQsIHJvdXRlcnMgY291bGQgYWx3YXlzIGtlZXAgdGhlIGxhc3Qgb25lIChhIHNtYWxs IGltcHJvdmVtZW50KS4gWW91IHByb2JhYmx5IGFsc28ga25vdyB0aGF0IHJvdXRlcnMgaGF2ZSB1 c3VhbGx5IGEgbGltaXQgb24gdGhpcyBidWZmZXIgcGVyIGludGVyZmFjZSBhbmQgcGVyIHJvdXRl ciwgc28sIHRoaXMgYXBwcm9hY2ggd2lsbCBub3Qgd29yayBpbiBzb21lIGNhc2VzLg0KDQpBYm91 dCB5b3VyIHJlcGx5IGJlbG93IHRvIEFsZXgsIHRoZSBXaUZpIGluIGxhcmdlIHdlbGwtZGVzaWdu ZWQgZGVwbG95bWVudHMgYXJlIG5vdCB0aGUgdHlwaWNhbCBvbmUgYXMgeW91IGtub3c6IHRoZXJl IGlzIGEgbG90IG9mIElQdjYgbWNhc3RlZCBOUyB3aGljaCBhcmUgJ2ZpZGRsZWQnIGludG8gbGF5 ZXItMiB1bmljYXN0IDstKSBTbywgeW91IG1heSB3YW50IHRvIGhhdmUgdHdvIG9yIGV2ZW4gdGhy ZWUgZGVwbG95bWVudHMgaW4geW91ciBkcmFmdDoNCi0gbm9ybWFsIEV0aGVybmV0LWxpa2UgbmV0 d29yayANCi0gbm9ybWFsIHNpbXBsZSBXaUZpIHdoZXJlIG1jYXN0IGFyZSBsb3N0IGFuZCBubyBt Y2FzdC0+dWNhc3QgdHJhbnNmb3JtYXRpb25zIGFyZSBkb25lDQotIGFkdmFuY2VkIFdpRmkgc3Vj aCBhcyBJRVRGIG5ldHdvcmsgd2hlcmUgdGhlcmUgYXJlICdORCBwcm94aWVzJyBvZiBzb21lIHNv cnQgYW5kIG5lYXJseSBubyBtY2FzdA0KDQpBZ2FpbiwgdGhhbmsgeW91IGZvciBkb2N1bWVudGlu ZyB0aGUgcHJvYmxlbSBhbmQgSSBob3BlIHRoYXQgaXQgd2lsbCBiZSBkaXNjdXNzZWQgaW4gTW9u dHJlYWwNCg0KUmVnYXJkcw0KDQotw6lyaWMNCg0KDQrvu79PbiAwNS8wNy8yMDE5LCAwNTo1MSwg InY2b3BzIG9uIGJlaGFsZiBvZiBKZW4gTGlua292YSIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGZ1cnJ5MTNAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIEhpIEFsZXhhbmRy ZSwNCiAgICANCiAgICBPbiBXZWQsIEp1bCAzLCAyMDE5IGF0IDEwOjQ5IFBNIEFsZXhhbmRyZSBQ ZXRyZXNjdQ0KICAgIDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPiB3cm90ZToNCiAgICA+ IEkgYW0gcmVhZGluZyB0aHJvdWdoIHRoaXMgZHJhZnQgdHJ5aW5nIHRvIGlkZW50aWZ5IHdoZXRo ZXIgdGhlIGluZGljYXRlZA0KICAgID4gTkQgcHJvYmxlbSAocm91dGVyIGxhY2tpbmcgTkQgZW50 cnkgZm9yIGhvc3QncyBHVUEgbWFrZXMgZHJvcCBmaXJzdA0KICAgID4gaW5jb21pbmcgcGFja2V0 IHRvIEdVQSkgaGFwcGVucyBvbiBhIHB0cCBsaW5rIGxpa2UgNEcsIG9yIG9uIGEgc2hhcmVkDQog ICAgPiBsaW5rIGxpa2UgV2lGaS4NCiAgICA+DQogICAgPiBPbiB3aGF0IHdhcyBpdCB0cmllZD8N CiAgICANCiAgICBXZWxsLCBJIG9ic2VydmVkIGl0IG9uIFdpRmkgKEkgZ3Vlc3MgeW91IHNob3Vs ZCBiZSBhYmxlIHRvIHNlZSB0aGUNCiAgICBpc3N1ZSBpbiBNb250cmVhbCkuDQogICAgDQogICAg PiA+IFRoZSByb3V0ZXIgTkQgY2FjaGUsIGhvd2V2ZXIsIG1pZ2h0IGNvbnRhaW4gYW4gZW50cnkg Zm9yIHRoZSBkZXZpY2UNCiAgICA+ID4gbGluay1sb2NhbCBhZGRyZXNzIChpZiB0aGUgZGV2aWNl IGhhcyBiZWVuIHBlcmZvcm1pbmcgdGhlIE5EIHByb2Nlc3MNCiAgICA+ID4gZm9yIHRoZSByb2l0 ZXIgTExBKSBidXQgdGhlcmUgYXJlIG5vIGVudHJpZXMgZm9yIHRoZSBkZXZpY2UgR1VBLg0KICAg ID4NCiAgICA+IEJ1dCBoYXMgdGhlIGhvc3QgREFEZWQgKHNlbnQgTkFzKSB3aGVuIGl0IGZvcm1l ZCBpdHMgR1VBPyAgSSBndWVzcyB0aGF0DQogICAgPiB3b3VsZCBiZSBoZWFyZCBieSByb3V0ZXIs IHRvIGNyZWF0ZSB0aGF0IE5EIGNhY2hlIGVudHJ5Lg0KICAgIA0KICAgIDEpIFRob3NlIE5TZXMg YXJlIHNlbnQgZnJvbSB1bnNwZWNpZmllZCBhZGRyZXNzDQogICAgMikgdGhleSBhcmUgc2VudCB0 byB0aGUgc29saWNpdGVkIG5vZGUgbWNhc3QgYWRkcmVzcyBzbyByb3V0ZXJzIG1pZ2h0DQogICAg bm90IGV2ZW4gcmVjZWl2ZSB0aGVtLi4NCiAgICANCiAgICAtLSANCiAgICBTWSwgSmVuIExpbmtv dmEgYWthIEZ1cnJ5DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCiAgICB2Nm9wc0BpZXRmLm9y Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCiAgICAN Cg0K From nobody Fri Jul 5 00:17:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C26120261; Fri, 5 Jul 2019 00:17:01 -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, 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 header.b=PIYDN4Nu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0KyWDC9R 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 dQv2I8X63znR; Fri, 5 Jul 2019 00:16:58 -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 3074E12024E; Fri, 5 Jul 2019 00:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9898; q=dns/txt; s=iport; t=1562311018; x=1563520618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MV7+ODq0dKY9JU4rhpwERNlzmpvrlK02CQYDteb4EUg=; b=PIYDN4NuT0J0T+hWpWJkjQdVqJxZw6REX+1HDAX6B6Uu7CH1DuVpfcn3 dJ2OUjwk9zKe9ft/nzoXryeHpLVzp6EgycHPSFAc54yyaMyFF+Kz/hLsB 215uRL4/77CsirpO6asTQPMG9YCZSnFm/2RJMOW4y8e4Y30pCV8R0i+sE 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AxSL0Rh2bN516qtFfsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAADr+B5d/5pdJa1QFhwBAQEEAQE?= =?us-ascii?q?HBAEBgVMHAQELAYFDJAUnA2pVIAQLKAqEEoNHA4RSiXeCW5dGgS4UgRADVAk?= =?us-ascii?q?BAQEMAQElCAIBAYRAAheCFyM0CQ4BAwEBBAEBAgEFbYo3DIVKAQEBAQIBEhE?= =?us-ascii?q?RDAEBNwEPAgEIDgwCDwIVAgICMBUQAgQODQwHB4MBgWoDDg8BAgyaXQKBOIh?= =?us-ascii?q?gcYEygnkBAQWBRkGDBxiCEgMGgQwoAYRxhU+BHheBQD+BEUaBfFA+gmEBAQI?= =?us-ascii?q?BAYEYAh0KBhg9gksygiaLdVMDgh+FIJVTbAkCgheGVoRriF2CLIceji6OYIY?= =?us-ascii?q?Pj3wCBAIEBQIOAQEFgVA4gVhwFYMngkEMF4EDAQmCQYUUhT4BcgGBKIsKgTA?= =?us-ascii?q?BgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,454,1557187200"; d="scan'208";a="576969250" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jul 2019 07:16:56 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x657Guai031065 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Jul 2019 07:16:56 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 02:16:55 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 03:16:54 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 5 Jul 2019 03:16:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MV7+ODq0dKY9JU4rhpwERNlzmpvrlK02CQYDteb4EUg=; b=0KyWDC9RWUwj7fBD0Rd3vxQVQ754IrBL7UpbrLLOCqVyF6F7D5i/WK6/2G7Db2avXmYNChKGbigoxQnCs54xDsbpxAoRszMKVCuq7OSp/xqOM9UlBO2+IkQzx5o4b3clJbbG//NhQEFQJTE8P8A1hY39Jp3xfK2QcXT2x7fK8i0= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3696.namprd11.prod.outlook.com (20.178.253.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Fri, 5 Jul 2019 07:16:52 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Fri, 5 Jul 2019 07:16:52 +0000 From: "Pascal Thubert (pthubert)" To: Jen Linkova CC: V6 Ops List , 6man <6man@ietf.org> Thread-Topic: [v6ops] ND cache entries creation on first-hop routers Thread-Index: AQHVMOfifvE1a4IuGkGPPJevTnDOSKa4zvPAgAK0SACAAAxH4A== Date: Fri, 5 Jul 2019 07:16:44 +0000 Deferred-Delivery: Fri, 5 Jul 2019 07:16:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f009b1d-3812-4d9e-1d47-08d70118c137 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3696; x-ms-traffictypediagnostic: MN2PR11MB3696: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(366004)(346002)(376002)(51914003)(189003)(199004)(6306002)(86362001)(8936002)(9686003)(55016002)(6666004)(26005)(186003)(53936002)(14444005)(256004)(966005)(76176011)(7736002)(6246003)(1411001)(66574012)(305945005)(74316002)(81156014)(81166006)(446003)(6436002)(71200400001)(71190400001)(229853002)(8676002)(11346002)(476003)(102836004)(6506007)(7696005)(99286004)(3846002)(6116002)(478600001)(66066001)(68736007)(486006)(4326008)(25786009)(33656002)(5660300002)(2906002)(14454004)(54906003)(66446008)(52536014)(66946007)(316002)(76116006)(66556008)(73956011)(64756008)(66476007)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3696; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aWJnUsNHuIfbzMmH/yEXOwhghyDnoRDGXyKXwUC3i0E9xhe/wwntNBVXhQ5V1ikhpn4vhOQti1qxu+wT7Ip0LCm4jcYKbtGQKqJ67h46nbk45OKR7V04yXuhmdtSnA0vr4d5HRbByrfujhHIqrmloPPG6eRfqU4WVzyiqo5bzEOpFmDUyYpr1FhJRF+x00pxTZe7cC1jhtK/zEc2yQkhihLvOLS4b/97uMEADeIdGHPSEkt5B92U0vsluWJXUtsTh0hiAi5XJXOxVx0cmbhu+I/RWUAJmpUPsa7PGwS8UaVCoWybieucclSSTzNMWbAupMlr69zD6T7TM3EzjOhjqJm8rgrWGRtnrRJHgjyNZgsHmipdYVAvzo+cd8LU8Iivo4wBYOzsSsVns/PzVShnEUjCRjAsLA09t5EKCUc80zM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8f009b1d-3812-4d9e-1d47-08d70118c137 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 07:16:52.7352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3696 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 07:17:01 -0000 SGVsbG8gSmVuDQoNCj4gPiAiKHByZXZpb3VzbHkgdW5zZWVuIGJ5IHRoZSByb3V0ZXIpIg0KPiA+ IEFub3RoZXIgY2FzZSBpcyB0aGF0IHRoZSBjYWNoZSBtYXkgaGF2ZSBiZWVuIGZsdXNoZWQuIFRo ZSBzYW1lIGlzc3VlIHdpbGwNCj4gaGFwcGVuIGFnYWluLg0KPiANCj4gSSdsbCB1cGRhdGUgdGhl IHNlbnRlbmNlIHRvIGluY2x1ZGUgdGhhdCBjYXNlIGFzIHdlbGwuDQoNClBsZWFzZSBub3RlIHRo YXQgdGhlIHByb2JsZW0gYmVoaW5kIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGhvc3QgZG9lcyBu b3Qga25vdyB3aGVuIHRoZSByb3V0ZXIgZmx1c2hlcyB0aGUgY2FjaGUuDQo9PiB3aGF0ZXZlciB0 cmljayB0aGUgaG9zdCBwbGF5cyB0byBwcmVsb2FkIHRoZSBjYWNoZSBhdCB0aGUgdGltZSBpdCBj cmVhdGVzIHRoZSBhZGRyZXNzIGNhbm5vdCBmaXggdGhlIGlzc3VlIHRoYXQgcmVhcHBlYXJzIGFz eW5jaHJvbm91c2x5IHVwb24gY2FjaGUgZmx1c2guDQoNCkJvdHRvbSBsaW5lIGlzIHdlIHdhbnQg YSBjb250cmFjdCBiZXR3ZWVuIHRoZSBob3N0IGFuZCB0aGUgcm91dGVyOyB0aGUgcm91dGVyIGFj Y2VwdHMgdG8gc3RvcmUgdGhlIE5DRSBmb3IgYSBndWFyYW50ZWVkIGxpZmV0aW1lLCByZW5ld2Fi bGUuIA0KT25jZSB5b3UgZW1icmFjZSB0aGF0IG1vZGVsLCB0aGUgaG9zdCBjYW4gZ28gdG8gc2xl ZXAsIG9yIGNvbm5lY3QgdG8gdGhlIHdpcmVsZXNzIGluIGEgZG90dGVkIGxpbmUgdG8gc2F2ZSBw b3dlciwgdGhlIHJvdXRlciB3aWxsIGJlIGFibGUgdG8gcHJvdGVjdCB0aGUgYWRkcmVzcyBhbmQg ZG8gdG9ucyBvZiBzZXJ2aWNlcyBsaWtlIHNsZWVwaW5nIHByb3h5LCBORCBQcm94eSwgcm91dGUg aW5qZWN0aW9uLCBmZWVkIGEgbWFwcGluZyBzZXJ2ZXIsIHlvdSBuYW1lIGl0LCBmb3IgdGhlIGR1 cmF0aW9uIG9mIHRoZSBjb250cmFjdC4NCg0KTm90ZSB0aGF0IGl0IGlzIHN0aWxsIFNMQUFDLCBu b3QgREhDUDogdGhlIGhvc3QgaXMgaW4gY29udHJvbCwgdGhlIHJvdXRlciBvbmx5IHByb3RlY3Rz IGl0c2VsZiBhZ2FpbnN0IG92ZXJ1c2UuIEFzIGFsd2F5cyB0aGVyZSBpcyBhIHRlbnNpb24gYmV0 d2VlbiBleHRyZW1lIHByaXZhY3kgYW5kIHRoZSBxdWFsaXR5IG9mIHRoZSBzZXJ2aWNlcyB0aGF0 IGNhbiBiZSBvZmZlcmVkIHdoZW4gdGhlIHNlcnZlciBoYXMgaW5mb3JtYXRpb24gYWJvdXQgdGhl IGNsaWVudC4gSGVyZSB3ZSdyZSB0YWxraW5nIGFib3V0IHRoZSBmaXJzdCBob3Agcm91dGVyIC8g TDMtQVAgLyBMMy1zd2l0Y2gsIGFuZCB3ZSBhcmUgdGFsa2luZyBhYm91dCBnZW5lcmljIGRldmlj ZSBjYXBhYmlsaXRpZXMgbGlrZSB3aXJlbGVzcywgcG93ZXItY29uY2VybmVkLCBub3QgcmVhbGx5 IGxlYWtpbmcgYSBiYW5rIGFjY291bnQgb24gdGhlIGludGVybmV0Lg0KDQo+IA0KPiA+IEluIDIu Mi4zLjI6DQo+ID4gIg0KPiA+IG8gV291bGQgbm90IHdvcmsgZm9yIHRoZSBob3N0IG9wdGltaXN0 aWMgYWRkcmVzc2VzICgoc2VlIHNlY3Rpb24gMi4yDQo+ID4gb2YgW1JGQzQ0MjldIHdoaWNoIHBy b2hpYml0cyB1c2luZyBhbiBPcHRpbWlzdGljIEFkZHJlc3MgYXMgdGhlIHNvdXJjZQ0KPiA+IGFk ZHJlc3Mgb2YgYSBSb3V0ZXIgU29saWNpdGF0aW9uIHdpdGggYSBTTExBTy4NCj4gPiAiDQo+ID4g VGhlICJ3b3VsZCBub3Qgd29yayIgaXMgZXhhZ2dlcmF0ZWQNCj4gDQo+IFdoYXQgSSBtZWFudCBp cyB0aGF0IGl0J3MgZGV2aWNlcyBhcmUgcHJvaGliaXRlZCB0byBkbyBzbyBieSBSRkM0NDI5Lg0K PiBJJ2xsIHJlcGhyYXNlIGl0Lg0KPiANCj4gPnNpbmNlIHRoZSBiZWhhdmlvciBvZiB0aGUgcm91 dGVyIGMvc2hvdWxkIGJlIHRvIGxvb2t1cCB0aGUgc291cmNlIG9mIHRoZSBSUyB0bw0KPiBhbnN3 ZXIgd2l0aCBhIHVuaWNhc3QgUkEuDQo+IA0KPiBJZiB0aGUgUlMgZG9lcyBub3QgY29udGFpbiBT TExBTywgeWVzLg0KPiBIb3dldmVyIGluIHRoYXQgY2FzZSBJJ20gbm90IHN1cmUgaWYgdGhlIGRl bGF5IGluIHNlbmRpbmcgdGhlIFJBIHdvdWxkIGltcGFjdA0KPiB0aGUgY2FjaGUgZW50cnkgY3Jl YXRpb24gKHRoZSBpc3N1ZSB3ZSBkaXNjdXNzZWQgd2l0aCBKaW5tZWktc2FuIGluIHRoaXMNCj4g dGhyZWFkKS4NCj4gVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dCwgSSdsbCB1cGRhdGUgdGhl IHRleHQgdG8gZGlzY3VzcyBib3RoIG9wdGlvbnMgLSB3aXRoDQo+IGFuZCB3L28gU0xBQU8gaW5j bHVkZWQgaW4gUlMuDQo+IA0KPiA+IFNvbWUgb2xkIGltcGxlbWVudGF0aW9ucyB3b3VsZCBhbHdh eXMgYW5zd2VyIHdpdGggYSBicm9hZGNhc3QgUkEgYnV0DQo+IGhvcGVmdWxseSB0aGluZ3MgaGF2 ZSBldm9sdmVkIHdpdGggdGhlIHJlYWxpemF0aW9uIHRoYXQgYnJvYWRjYXN0IG1heSBoYXZlIGl0 cw0KPiBvd24gaXNzdWVzLCBpbiBwYXJ0aWN1bGFyIHdpdGggd2lyZWxlc3MgYW5kIG92ZXJsYXlz Lg0KPiANCj4gTW9zdCBlbnRlcnByaXNlLXNjYWxlIHJvdXRlciB2ZW5kb3JzIHN1cHBvcnQgcmZj Nzc3MiBub3csIHNvIEkgaG9wZSB0aGF0DQo+IHVuaWNhc3Qgc29saWNpdGVkIFJBIGlzIGxlc3Mg b2YgYSBwcm9ibGVtIG5vd2FkYXlzLi4NCj4gDQo+ID5TbyB0aGlzIHRlY2huaXF1ZSBtYXkgd29y ayBpZiB0aGUgcm91dGVyIHJlc3BvbmRzIHVuaWNhc3QgYW5kIHRoZSBvcHRpbWlzdGljDQo+IG5v ZGUgYWxzbyBpbnRyb2R1Y2VzIGEgc21hbGwgZGVsYXkgYmVmb3JlIGZpcmluZyBpdHMgcHJvYmVz IHRvIGNvdmVyIGZvciB0aGUgUkENCj4gZGVsYXkuDQo+IA0KPiBZZXMsIHRoYXQncyB0aGUgY29u Y2Vybi4gSSdsbCB1cGRhdGUgdGhlIHRleHQgYWNjb3JkaW5nbHksIHRoYW5rcyENCj4gDQoNClRo ZXJlJ3MgYSBkZXBpY3Rpb24gb2YgdGhpcyBpbiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtNmxvLWJhY2tib25lLXJvdXRlciNzZWN0aW9uLTMuMiBmaWd1 cmUgMiBpbiB0aGUgY29udGV4dCBvZiBSRkMgODUwNS4gDQoNClRoZSBSRkMgODUwNSBwaWVjZSBj YW4gYmUgcGFydGlhbGx5IGVtdWxhdGVkIGJ5IHNub29waW5nIE5ELCB0aGF0J3Mgd2hhdCB3ZSBk byB0b2RheS4gSXQgbW9zdGx5IHdvcmtzLiBSRkMgODUwNSByZW1vdmVzIHRoZSAibW9zdGx5Iiwg YXQgbGVhc3QgZm9yIHRoZSBpc3N1ZXMgdGhhdCB3ZSBmb3VuZCBvdmVyIHRoZSA1KyB5ZWFycyB3 ZSd2ZSBiZWVuIHNoaXBwaW5nIHRoaXMgdHJpY2suIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1iaS1zYXZpLXdsYW4gaXMgaW5mb3JtYXRpdmUgYmVjYXVzZSBpdCBoaW50cyBvbiB3 aGF0IHZlbmRvcnMgYWN0dWFsbHkgZG8gdGhhdCBtYXkgYmVjb21lIGludGVyb3AgdHJvdWJsZSBp biB0aGUgZnV0dXJlLiBCdXQgZXhwZXJpZW5jZSBzYXlzIHdlJ2QgcmF0aGVyIGxlYXZlIGl0IGFz IGEgZHJhZnQuDQoNCkluIHRoYXQgZmlndXJlIDIsIHRoZSA2QkJSIGlzIHRoZSBMMy1BUC4gVGhl IDZMQlIgaXMgYW4gb3B0aW9uYWwgbWFwcGluZyBzZXJ2ZXIgdGhhdCBlbmFibGVzIHNlcnZpY2Vz IGxpa2UgdW5pY2FzdCBsb29rdXBzIGFuZCBvdmVybGF5cy4gVGhlIHNjZW5hcmlvIGlzIGJhc2Vk IG9uIHRoZSAiVG9reW8gU3RhdGlvbiIgdXNlIGNhc2UgKHNlZSBJRUVFIHN0ZCA4MDIuMTFhaSBh a2EgRklMUykgd2hlcmUgdGhlIHRyYWZmaWMgbXVzdCBzdGFydCB2aXJ0dWFsbHkgaW5zdGFudGx5 LiBUaGUgSUVFRSBkaWQgaXRzIHBpZWNlLCBidXQgZm9yIHRoZSByZWFzb25zIHRoYXQgeW91IGRp c2N1c3MgaW4gdGhlIGRyYWZ0LCBhbmQgZm9yIHRoZSBsYWNrIG9mIE9EQUQsIElQdjYgbWF5IGRl bGF5IHRoZSBhY2Nlc3MgYnkgbW9yZSB0aGFuIG9uZSBzZWNvbmQuIFNvLCBhcyB5b3UgZGVzY3Jp YmUsIHdlIHdhbnQgT0RBRCwgYW5kIHdlIHdhbnQgdG8gcHJlcG9wdWxhdGUgdGhlIE5EIGNhY2hl IGluIHRoZSByb3V0ZXIuDQoNCg0KDQo+ID4gSW4gMy4gUmVjb21tZW5kYXRpb25zDQo+ID4gSSBk byBub3QgYWdyZWUgd2l0aCB0aGUgcmVjb21tZW5kYXRpb24sIGJlY2F1c2U6DQo+ID4gLSAgdGhl IGhvc3QgaGFzIG5vIGNvbnRyb2wgb3IgZ3VhcmFudGVlIGFib3V0IHdoZXRoZXIgdGhlIHJvdXRl ciB3aWxsDQo+ID4gbWFpbnRhaW4gdGhlIGNhY2hlIGFuZCBmb3IgaG93IGxvbmcNCj4gPiAtICBt dWx0aWNhc3QgTkEgbWF5IGJlIGxvc3QsIG1vcmUgY2hhbmNlcyBvZiB0aGF0IGlmIHRoZSByb3V0 ZXIgaXMgd2lyZWxlc3MuDQo+IFlvdSBtYXkgd2FudCBzb21ldGhpbmcgYSBiaXQgbW9yZSByb2J1 c3Qgd2l0aCBhbiBhY2tub3dsZWRnZW1lbnQgYW5kIGENCj4gbGlmZXRpbWUsIHNlZSBSRkMgODUw NS4NCj4gPiAtIHRoZSBhbGwtcm91dGVycyBpcyBzdGlsbCBhIEwyIGJyb2FkY2FzdCBvbiBFdGhl cm5ldCBhbmQgV2ktRmkuIFdlIGFyZSBhY3R1YWxseQ0KPiB0cnlpbmcgdG8gZGVwcmVjYXRlIHRo ZSBOQShPKSBhdCB0aGUgZW5kIG9mIHRoZSBhdXRvY29uZiBzZXF1ZW5jZS4NCj4gDQo+ID4gLSB0 aGUgcHJvcG9zZWQga25vYiB3b3VsZCBoYXZlIHRoZSByb3V0ZXJzIGxlYXJuIGFsbCBhZGRyZXNz ZXMgb2YgYWxsIGhvc3RzDQo+IGluY2x1ZGluZyB0aG9zZSB0aGF0IGRvIG5vdCBnZXQgdHJhZmZp YyBmcm9tIHRoYXQgcm91dGVyLiBUaGlzIGF1Z21lbnRzIHRoZQ0KPiBjaGFuY2VzIG9mIGNhY2hl IHNhdHVyYXRpb24sIHdoaWNoIHJlY3JlYXRlcyB0aGUgcHJvYmxlbSB5b3Ugd2FudCB0byBhdm9p ZC4NCj4gDQo+IEhtbS4uLkluIHRoZSBzY2VuYXJpbyBJJ20gdGhpbmtpbmcgYWJvdXQgKGEgV2lG aSBzZWdtZW50IGluIGFuIGVudGVycHJpc2UNCj4gbmV0d29yaywgZm9yIGV4YW1wbGUpIGFsbCBo b3N0cyBhcmUgZ2V0dGluZyB0cmFmZmljIGZyb20gYWxsIHJvdXRlcnMuDQo+IFlvdSBhcmUgcmln aHQgaXQgbWlnaHQgZ2V0IHRyaWNreSBpbiBtdWx0aWhvbWVkL21QVkQgY2FzZS4NCj4gV2hhdCBz aG91bGQgYmUgbm90ZWQgaGVyZSBpcyB0aGF0IGF0IGxlYXN0IG9uZSBtYWpvciByb3V0ZXIgdmVu ZG9yIGhhcyB0aGlzDQo+IGtub2IgaW1wbGVtZW50ZWQgYW5kIGl0J3MgYWN0aXZlbHkgdXNlZCBB RkFJSy4gU28gaGF2aW5nIGEga25vYiBoYXMgYmVlbg0KPiBwcm92ZWQgdXNlZnVsIC0gaXQgZG9l cyBub3QgaGF2ZSB0byBiZSBhIHNvbGUgc29sdXRpb24gdGhyb3VnaC4uDQo+IA0KPiA+IEFsc28g bm90ZSB0aGF0IHRoZSBmaWRkbGluZyBzbWFydCB3aXJlbGVzcyB3ZWxsIGFzIHNtYXJ0IGZhYnJp Y3MgbWF5IGxlYXJuIHRoZQ0KPiBsb2NhdGlvbiBvZiB0aGUgYWRkcmVzcyBmcm9tIHNub29waW5n IHRoZSBORCBhY3Rpdml0eSAoc2VlDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1iaS1zYXZpLXdsYW4pLiBBIHNlbnNlIGlmIG9yZGVyIG9mIGV2ZW50cyBsaWtlIGENCj4gc2Vx dWVuY2UgY291bnRlciAvIHRpbWUgc3RhbXAgaXMgaW1wb3J0YW50IGZvciBkZXZpY2VzIHRoYXQg bW92ZSBxdWlja2x5LiBTZWUNCj4gZm9yIGluc3RhbmNlIHRoZSBkaXNjdXNzaW9uIGluIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJpZnQtcmlmdC0NCj4gMDYjc2VjdGlv bi01LjMuMy4xIC4NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHJlZmVyZW5jZXMsIEknbGwgY2hlY2sg dGhlbSBvdXQhDQo+IA0KPiA+IEFsbCBpbiBhbGwgdGhlcmUnIHMgYSBsaW1pdCB0byBzdHJldGNo aW5nIG9sZCBkZXNpZ25zIGFuZCBhIHRpbWUgd2hlcmUgYSBuZXcgb25lDQo+IGlzIG5lZWRlZC4g QXNrIHBsYW5lIG1ha2Vycy4uLg0KPiANCj4gSXQgc2VlbXMgbGlrZSB3ZSBtaWdodCBkbyB0d28g dGhpbmdzIGhlcmU6DQo+IC0gZXhwbG9yZSB0aGUgb3B0aW9uIG9mIHVzaW5nIFJGQzg1MDUgKHN0 cmF0ZWdpYyBzb2x1dGlvbik7DQo+IC0gaGF2ZSBzb21lIHRhY3RpY2FsIHdvcmthcm91bmRzIHRv IGRlYWwgd2l0aCBsZWdhY3kgaG9zdHMuDQoNClllcywgd2UgaGF2ZSB0byBkZXNpZ24gZm9yIGxv bmcgdGVybSBjb2V4aXN0ZW5jZS4gDQoNCkF0IENpc2NvLCB3ZSd2ZSBiYXNlZCBvdXIgd29yay1h cm91bmRzIG9uIHNub29waW5nIGFuZCB0aGF0J3MgY29udHJvbGxlZCBieSB0aGUgcm91dGVyIG5v dCB0aGUgaG9zdC4gQmVpbmcgb24gdGhlIHJvdXRlciBzaWRlIHdlIGtub3cgaWYgdGhlIFNMQUFD IGFkZHJlc3MgY29uZmxpY3RzIHdpdGggYW4gZXhpc3RpbmcgY2FjaGUgZW50cnkgYW5kIGlmIG5v dCwgd2UgY2FuIGNyZWF0ZSB3aGF0IHdlIGNhbGwgYSBiaW5kaW5nIGNhY2hlIGVudHJ5IGJhc2Vk IG9uIHRoZSBzb3VyY2UgTUFDIG9mIE5EIHBhY2tldHMgKG1lYW5pbmcgZXZlbiBpZiB0aGVyZSBp cyBubyBTTEFBTykuIFdlIGNhbiBldmVuIGhhdmUgdGhhdCB0cmlnZ2VyZWQgYnkgZGF0YSB0cmFm ZmljLiBUaGVuIGFnYWluLCB0aG9zZSBhcmUgdHJpY2tzIHRoYXQgcmVseSBvbiBzaWRlIGVmZmVj dHMsIGp1c3QgbGlrZSB0aGUgc29sdXRpb25zIHRoYXQgeW91ciBkcmFmdCBwcm9wb3Nlcy4gVGhl eSBhcmUgbGVzcyBlZmZpY2llbnQgb24gd2lyZWxlc3MgYmVjYXVzZSBvZiBsb3NzIGFuZCBtb3Zl bWVudC4gQW5kIHdlIGNhbm5vdCBmdWxseSBlbGltaW5hdGUgdGhlIHJlYWN0aXZlIGJyb2FkY2Fz dHM7IHRoYXQgd2lsbCByZW1haW4gdHJ1ZSBhcyBsb25nIGFzIHRoZXJlIGlzIGNvZXhpc3RlbmNl Lg0KDQpCdXQgdGhlbiwgdGhlIG1vcmUgaG9zdHMgc3VwcG9ydCBSRkMgODUwNSB0aGUgbGVzcyBi cm9hZGNhc3RzIGV2ZXJ5Ym9keSB3aWxsIGdldC4gVGhpcyBzZXJ2ZXMgdGhlIGNvbW11bml0eSBi eSBzYXZpbmcgZW5lcmd5IG5vdCBvbmx5IGZvciB3aXJlbGVzcyBob3N0IGJ1dCBvdmVyIHRoZSB3 aG9sZSBMMiBpbmZyYSAodGhpbmsgZmFicmljcykuIEknZCBleHBlY3QgdGhhdCBzbWFydHBob25l IG1hbnVmYWN0dXJlcnMgYmUgcXVpdGUgc2Vuc2l0aXZlIHRvIHRoZSAiVG9reW8gU3RhdGlvbiIg c2NlbmFyaW8gYXMgd2VsbC4gVGhlIGVmZm9ydCB0byBpbXBsZW1lbnQgdGhlIGNsaWVudCBzaWRl IG9mIFJGQyA4NTA1IGRvZXMgbm90IHNlZW0gc28gaHVnZSB0aGF0IGl0IHdvdWxkIHRha2UgeWVh cnMgdG8gZ2V0IGl0IGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIG1ham9yIHNtYXJ0cGhvbmUg T1Nlcy4gSnVzdCB0aGF0IHdvdWxkIGJlIGEgcXVhbnR1bSBsZWFwIGZvciB0aGUgZXhwZXJpZW5j ZSBieSBJUHY2IHVzZXJzLg0KDQpBbGwgdGhlIGJlc3QsDQoNClBhc2NhbA0KDQoNCg0K From nobody Fri Jul 5 02:34:26 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C161112012A for ; Fri, 5 Jul 2019 02:34:24 -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, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 uarRgtTTxvB6 for ; Fri, 5 Jul 2019 02:34:22 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 7C2111200CE for ; Fri, 5 Jul 2019 02:34:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x659YK9a043278; Fri, 5 Jul 2019 11:34:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0CA75205B12; Fri, 5 Jul 2019 11:34:20 +0200 (CEST) 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 0392B205B10; Fri, 5 Jul 2019 11:34:20 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x659YJiC020154; Fri, 5 Jul 2019 11:34:19 +0200 To: Jen Linkova Cc: V6 Ops List References: <162e470d-a1da-c100-3806-e4ab7640f5e2@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 5 Jul 2019 11:34:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 09:34:25 -0000 Hi Jen, Le 05/07/2019 à 05:50, Jen Linkova a écrit : > Hi Alexandre, > > On Wed, Jul 3, 2019 at 10:49 PM Alexandre Petrescu > wrote: >> I am reading through this draft trying to identify whether the >> indicated ND problem (router lacking ND entry for host's GUA makes >> drop first incoming packet to GUA) happens on a ptp link like 4G, >> or on a shared link like WiFi. >> >> On what was it tried? > > Well, I observed it on WiFi (I guess you should be able to see the > issue in Montreal). It is good to know for WiFI. Let me try on Ethernet. >>> The router ND cache, however, might contain an entry for the >>> device link-local address (if the device has been performing the >>> ND process for the roiter LLA) but there are no entries for the >>> device GUA. >> >> But has the host DADed (sent NAs) when it formed its GUA? I guess >> that would be heard by router, to create that ND cache entry. > > 1) Those NSes are sent from unspecified address 2) they are sent to > the solicited node mcast address so routers might not even receive > them. Ah I see. It's not NSs that are necessary, and worse, the routers that dont implement link scoped multicast on WiFi would not see them either. But how about NA? An NA was issued by my Ethernet adapter of my Windows 10 after I manually assigned fd00::1/65 on it; it was issued to a multicast address, informing all-nodes that it has that MAC address. The Router receiving it would presumably associate that link-layer address to fd00::1/65. I think that's how the GUA of Host is supposed to get its way in the NC of Router, probably. Alex > From nobody Fri Jul 5 12:07:51 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC741200EF; Fri, 5 Jul 2019 12:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVwXgLAToPpd; Fri, 5 Jul 2019 12:07:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B461200A3; Fri, 5 Jul 2019 12:07:40 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id F38C538196; Fri, 5 Jul 2019 15:05:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 96FADB26; Fri, 5 Jul 2019 15:07:37 -0400 (EDT) From: Michael Richardson To: Jen Linkova cc: V6 Ops List , 6man <6man@ietf.org> In-Reply-To: References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> <4250.1562178592@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 19:07:43 -0000 --=-=-= Content-Type: text/plain Jen Linkova wrote: >> 5-10 seconds seems really high... it is really explained by just the >> pathology you described? > Yes, because as soon as the NC entry appears in the router cache the > issue goes away. So users normally complain if they have not connected > the particular device to the network for a while. So let me ask the question differently: why is it taking 5-10 seconds for the NC entry to appear? Let me repeat what you wrote in my own words: 1) device gets online, gets address via RA, uses SLAAC/RFC4941, configures addr Q. I don't think it matters if the device sees a multicast RA, or solicits one with a RS. The device also does DAD here. 2) device sends TCP SYN to "does this work" test A via router X. (http://detectportal.firefox.com/, etc.) 3) respond from A arrives at X, no NCE exists, sends out NS for Q, router X tries to buffer it, but since there are many devices, the reply gets dropped. 4) device answers NS with NA unicast to X, NCE is created. No packet is released, since there isn't one. 5) device eventually retransmits TCP SYN to test A via router X. 6) reply gets back to Q since NCE exists. It has been asserted above that as soon (4) occurs, that it's all good. I'm skeptical, wondering isn't it (5) that is the key point. So I assume that I mis-understand something about how things work. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0fn/gACgkQgItw+93Q 3WWHFgf/cHQULOQWlgRQ4K5VvwCto9jjeXWimVq3ArRITOkPqu0u4hqTE/2nmbpI kz5eK9Gz3NoPjaLhlzyEsVeo1KXjx/16mHmeucVTMNMnbrXO2nz0SKeWI+iGwVnj 2t3nb/EiXfPJ6hBUrYtj8d0s4qp2fcbSB2Vub8H1mb474fBwen0zNjvITDyvYh9F e46QX2WbZFyg+QMbtocwOmhWDLW098CYJteMHMUBDjyE1vJU2l7FaArnZ7/z3QRA fkC6p/6dWk2IQ4XPgZ4GJNqtZrT+/g0l33bYyan9pn3ZFwUqt/j4r7HxDstVu14w MqBgEzdqHuUUynkOabOAndJRLHQKMw== =3TYL -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 5 12:16:19 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A102120118; Fri, 5 Jul 2019 12:16:17 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=avaya365.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 uELQbGY7dPBd; Fri, 5 Jul 2019 12:16:14 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 9AE2F120119; Fri, 5 Jul 2019 12:16:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EkAAANoR9d/wUHmMZmHAEBAQQBAQcEA?= =?us-ascii?q?QGBVAYBAQsBgUNQbXUEMwqEEoNHA45JgluJTY8nFIEQAxgXJQkBAQENASMKAgE?= =?us-ascii?q?BAoQ+AheCGCM1CA4BAwEBAQQBAQEBBAECAmmKNwyCeE0vCgIvAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDQIpHgEBGAEBAQEDEhERDAE?= =?us-ascii?q?BLAsBCwQCAQgNAQMEAQEBAgImAgICHxEVCAgCBA4FCBqDAYFqAx0BAgIKmjcCg?= =?us-ascii?q?QgwiF8BAXCBMhoCgjMqAQEFdYQfDQuCEgkJAYECKAGIQYMdF4FBPoEQAUaCTD6?= =?us-ascii?q?CGkcEGIELJhgkgmQygiaMGYJRmx9ACQKCF4ZWiTqEDoIsbIYyg3kDijKUb4Fzj?= =?us-ascii?q?gkCAgICBAUCDgEBBYFRATeBWHAVO4JsCYI4g3GEWYV6coEpjEoBgSABAQ?= X-IPAS-Result: =?us-ascii?q?A2EkAAANoR9d/wUHmMZmHAEBAQQBAQcEAQGBVAYBAQsBgUN?= =?us-ascii?q?QbXUEMwqEEoNHA45JgluJTY8nFIEQAxgXJQkBAQENASMKAgEBAoQ+AheCGCM1C?= =?us-ascii?q?A4BAwEBAQQBAQEBBAECAmmKNwyCeE0vCgIvAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQUCDQIpHgEBGAEBAQEDEhERDAEBLAsBCwQCAQgNA?= =?us-ascii?q?QMEAQEBAgImAgICHxEVCAgCBA4FCBqDAYFqAx0BAgIKmjcCgQgwiF8BAXCBMho?= =?us-ascii?q?CgjMqAQEFdYQfDQuCEgkJAYECKAGIQYMdF4FBPoEQAUaCTD6CGkcEGIELJhgkg?= =?us-ascii?q?mQygiaMGYJRmx9ACQKCF4ZWiTqEDoIsbIYyg3kDijKUb4FzjgkCAgICBAUCDgE?= =?us-ascii?q?BBYFRATeBWHAVO4JsCYI4g3GEWYV6coEpjEoBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,456,1557201600"; d="scan'208";a="289129879" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Jul 2019 15:16:10 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2019 15:16:10 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by AZ-US1EXHC04.global.avaya.com (135.11.85.15) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 5 Jul 2019 15:16:08 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (104.47.33.56) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Fri, 5 Jul 2019 14:16:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WvwCv4rWvZGgbyTBrikDiVVuuPinG+8sU2BQJ0BEhN0=; b=nxSTt1KH6T/H5ilrD0faD/mSs83lDOMTI/ol/sD1TZhBdOkhf5P4dsLEx0tB7bsSl3AVoDVJOU+rys8V95ov+hPgSfhhpwYC4Rs0+Vwo4BxU1xn7mitw17uaV9e65r5zt/xEPUo0IQDLJBIPSJg82eJ3PhLJ/GThXwRuaCppggQ= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB3259.namprd15.prod.outlook.com (20.179.50.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 19:16:07 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2052.019; Fri, 5 Jul 2019 19:16:07 +0000 From: "Mudric, Dusan (Dusan)" To: Jen Linkova CC: Fred Baker , IPv6 Operations , 6man <6man@ietf.org> Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AQHVMthYQTP2spnzX0G8BrvKPAtN5qa8YmwQ Date: Fri, 5 Jul 2019 19:16:06 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a2b57e3d-0445-4291-9962-08d7017d3b28 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB3259; x-ms-traffictypediagnostic: DM6PR15MB3259: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:289; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(366004)(39860400002)(396003)(13464003)(199004)(189003)(476003)(6246003)(446003)(54906003)(19627235002)(316002)(11346002)(66476007)(52536014)(66446008)(66946007)(73956011)(66556008)(64756008)(2906002)(256004)(86362001)(5660300002)(33656002)(478600001)(3846002)(6116002)(486006)(305945005)(7736002)(66066001)(4326008)(76116006)(71190400001)(966005)(71200400001)(99286004)(6436002)(74316002)(1411001)(6916009)(229853002)(68736007)(14454004)(26005)(53936002)(55236004)(9686003)(8936002)(7696005)(8676002)(6506007)(55016002)(25786009)(81156014)(76176011)(53546011)(102836004)(6306002)(81166006)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB3259; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mXu+Vtn4a5YRPeqyGSDiLx+4+te4RbX7ht/WVLyqr4Qyu2mnLYJx9TRvzK6mxu4D/90oRB7IlEX/Zus2Zj5oh7WYVBRcgdjuutkx0vBmPy9Xk9a/9r4ZYdUiPtMb+ZjA0HMd9m9yG4u8w+vNvXkR81fOeU1XCOZIhlNf3ZevK40Buwg+XoRJNCsopyOoJf3EZLLrw1Zu3XwDtqJl5PQseWCZtMf4xHLDntuSX9jyqPZFY433PcxX3uAZpJWgqLfYDP9A1UIArbjNigiBLj/usqflV69QAEzf0Bf/V0w0lif54fHGUFeK3jsLHL14OISchH/HwE5+HZq5KnK2PNfNECai1exMBwjkQQaCjg1h9jte0d4AwcTSOKmgEfi/jgidEPMORZhACk/6X6AHKr1IXPL9xy697S0DmRX+6z2uJ2E= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a2b57e3d-0445-4291-9962-08d7017d3b28 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 19:16:06.9551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3259 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 19:16:19 -0000 SGkgSmVuLA0KDQpJZiBJUHY0b25seSAtIHRvIC0gSVB2Nm9ubHkgY2xpZW50IGluaXRpYXRlZCBj b21tdW5pY2F0aW9uIG5lZWRzIFNJSVQtREMgKHJmYzc3NTUpLCBhbmQgSVB2Nm9ubHkgLSB0byAt IElQdjRPbmx5IGNsaWVudCBpbml0aWF0ZWQgY29tbXVuaWNhdGlvbiBuZWVkcyBTdGF0ZWZ1bCBO QVQ2NCAocmZjNjE0NiksIGNhbiB0aGUgdHdvIHByb3RvY29scyBiZSBjb21iaW5lZCBpbiB0d28g ZGV2aWNlIChETlMgYW5kICB0cmFuc2xhdG9yKSBhbmQgdXNlZCBhdCB0aGUgc2FtZSB0aW1lIGZv ciBiaWRpcmVjdGlvbmFsIGNvbW11bmljYXRpb24/IElzIGl0IGNhbGxlZCBOQVQ2NC1OQVQ0NiBv ciBzb21ldGhpbmcgc2ltaWxhcj8NCg0KLSBIb3cgY2FuIEROUzY0IHRlbGwgSVB2NiBvbmx5IGNs aWVudCB0aGUgSVAgb2YgSVB2NCBvbmx5IGNsaWVudCwgYW5kIHZpY2UgdmVyc2E/IElzIEROUzY0 IHNlcnZlciByZXR1cm5pbmcgSVB2NG9ueSBjbGllbnQgYWRkcmVzcyB0byBJUHY2b25seSBjbGll bnQsIHVzaW5nIHRoZSBBIFJSPyANCi0gSG93IGNhbiBJUHY0b25seSBjbGllbnQgZ2V0IHRoZSBh ZGRyZXNzIG9mIElQdjZvbmx5IGNsaWVudCAob3IsIGl0IGlzIGltcG9zc2libGUgZm9yIElQdjRv bmx5IGNsaWVudCB0byBnZXQgSVB2NiBhZGRyZXNzIG9mIElQdjZvbmx5IGNsaWVudCk/IA0KLSBE byB0aGVzZSBJUHY0IGFuZCBJUHY2IGNsaWVudCBhZGRyZXNzZXMgbmVlZCB0byBiZSBwcmUtY29u ZmlndXJlZCBvbiB0aGUgdHJhbnNsYXRvciBhbmQvb3IgRE5TNjQ/DQoNClRoYW5rcywNCkR1c2Fu Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEplbiBMaW5rb3ZhIDxm dXJyeTEzQGdtYWlsLmNvbT4NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgNCwgMjAxOSAxMDoyMSBQ TQ0KPiBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pIDxkbXVkcmljQGF2YXlhLmNvbT4NCj4gQ2M6 IEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbT47IElQdjYgT3BlcmF0aW9ucw0K PiA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuIDw2bWFuQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTog TkFUNjQgaW4gUkEsIGRyYWZ0LWlldGYtNm1hbi1yYS1wcmVmNjQNCj4gDQo+IEhpIER1c2FuLA0K PiANCj4gT24gRnJpLCBKdWwgNSwgMjAxOSBhdCA2OjE5IEFNIE11ZHJpYywgRHVzYW4gKER1c2Fu KSA8ZG11ZHJpY0BhdmF5YS5jb20+DQo+IHdyb3RlOg0KPiA+IFdoYXQgaXMgdGhlIGJlc3QgcmVm ZXJlbmNlIGRvY3VtZW50IGZvciBhIFRyYW5zbGF0b3IgdGhhdCBmYWNpbGl0YXRlczoNCj4gPg0K PiA+IC0gSVB2NG9ubHkgLSB0byAtIElQdjZvbmx5LCBhbmQNCj4gDQo+IGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3Rvb2xzLmlldGYub3Jn X2h0bWxfcmZjNzc1NSZkPUR3SUJhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFENCj4gJnI9VVQz Qms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPXJYbi0NCj4gcWNmU0lo akIxRlZacTlmVDBIV0tJRTRGc1ZXNTVQdzR1ZmNkNFFjJnM9NmpneTgxZVBlaVdhQkZNTDNYd1AN Cj4gQzN3RHhHa3lEcnZ6V0cwSmc5T29nX3cmZT0NCj4gDQo+ID4gLSBJUHY2b25seSAtIHRvIC0g SVB2NE9ubHkNCj4gDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0NCj4gM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNjE0NiZkPUR3SUJhUSZjPUJG cFdRdzhic3VLcGwxU2dpWkg2NFENCj4gJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpV MjMwMjlzTVFHUTJrWSZtPXJYbi0NCj4gcWNmU0loakIxRlZacTlmVDBIV0tJRTRGc1ZXNTVQdzR1 ZmNkNFFjJnM9U29iU0Z1dnpQbTlYUTNiV2hTRUwNCj4gYm5oazRLdEFhWUo3eUI1UVdmNzBBNkEm ZT0NCj4gDQo+ID4gY2xpZW50cyBtZXNzYWdlIGV4Y2hhbmdlcz8NCj4gPg0KPiA+IElzIHRoaXMg Y29tbXVuaWNhdGlvbiBiaWRpcmVjdGlvbmFsIG9yIHdvcmtzIG9ubHkgZnJvbSBJUHY2b25seS10 by1JUHY0b25seQ0KPiBjbGllbnQgKG1lYW5pbmcgSVB2Nm9ubHkgY2xpZW50IGhhcyB0byBpbml0 aWF0ZSB0aGUgY29tbXVuaWNhdGlvbik/DQo+ID4NCj4gPiBIb3cgY2FuIFRyYW5zbGF0b3Igb3Ig RE5TNjQgdGVsbCBJUHY2IG9ubHkgY2xpZW50IHRoZSBJUCBvZiBJUHY0IG9ubHkgY2xpZW50LA0K PiBhbmQgdmljZSB2ZXJzYT8NCj4gDQo+IEluIGEgbnV0c2hlbGw6DQo+IA0KPiBJUHY2LW9ubHkg Y2xpZW50IGFza3MgRE5TNjQgc2VydmVyIGZvciBBQUFBIGZvciwgbGV0J3Mgc2F5LA0KPiBpcHY0 b25seS5leGFtcGxlLm5ldCBBcyB0aGF0IHNlcnZlciBpcyBJUHY0LW9ubCwgZG9lcyBub3QgaGF2 ZSBBQUFBIFJSLCB0aGUNCj4gRE5TNjQgc2VydmVyIHN5bnRoZXNpc2UgYSBuZXcgQUFBQSB1c2lu ZyBhbiBJUHY2IHByZWZpeCAodXN1YWxseSAvOTYgLSB0aGUNCj4gV2VsbC1Lbm93biBQcmVmaXgg aXMgNjQ6ZmY5Yjo6Lzk2KSBhbmQgSVB2NCBhZGRyZXNzIGZyb20gdGhlIEEgUlIuIFRoZQ0KPiBh bGdvcml0aG0gZGVzY3JpYmVkIGluIHJmYzYxNDcNCj4gDQo+IFNvIGlmIGlwdjRvbmx5LmV4YW1w bGUubmV0IGhhcyBhbiBJUHY0IGFkZHJlc3MgMTkyLjAuMi4yLCB0aGVuIEROUzY0IHdpbGwNCj4g cmV0dXJuIDY0OmZmOWI6OjE5Mi4wLjIuMiBhcyBBQUFBIFJSLg0KPiBUaGUgaXB2Ni1vbmx5IGNs aWVudCB3b3VsZCBpbml0aWF0ZSBhIGNvbm5lY3Rpb24gdG8gdGhhdCBhZGRyZXNzIC4gQXMNCj4g TkFUNjQgcHJlZml4IGlzIHN1cHBvc2VkIHRvIGJlIHJvdXRlZCB0byB0aGUgTkFUNjQgZGV2aWNl LCB0aGF0IGRldmljZQ0KPiB3b3VsZCB0cmFuc2xhdGUgSVB2NiBwYWNrZXQgdG8gSVB2NCBwYWNr ZXQgdXNpbmcgdGhlIGFsZ29yaXRobSBkZXNjcmliZWQgaW4NCj4gaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fdG9vbHMuaWV0Zi5vcmdfaHRt bF9yZmM2MDUyJmQ9RHdJQmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0UQ0KPiAmcj1VVDNCazlj YkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09clhuLQ0KPiBxY2ZTSWhqQjFG VlpxOWZUMEhXS0lFNEZzVlc1NVB3NHVmY2Q0UWMmcz1YVENZTWpZM0hPS0V4NTM1UFVfSQ0KPiBP cmE4SkFpUkRfVWF5dDFTd3JKbld2OCZlPS4NCj4gDQo+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWls LmNvbT4NCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAzLCAyMDE5IDM6MzIgUE0NCj4gPiA+ IFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNAYXZheWEuY29tPg0KPiA+ID4gQ2M6 IDZtYW4gPDZtYW5AaWV0Zi5vcmc+OyBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPg0K PiA+ID4gU3ViamVjdDogUmU6IE5BVDY0IGluIFJBLCBkcmFmdC1pZXRmLTZtYW4tcmEtcHJlZjY0 DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IE9uIEp1bCAzLCAyMDE5LCBhdCAxMjowMSBQ TSwgTXVkcmljLCBEdXNhbiAoRHVzYW4pDQo+ID4gPiA+IDxkbXVkcmljQGF2YXlhLmNvbT4NCj4g PiA+IHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPiBbRHVzYW5dIFBsZWFzZSBjbGFyaWZ5IGhvdyBJ UHY0LW9ubHkgaG9zdCBjYW4gcmVhY2ggSVB2NiBvbmx5DQo+ID4gPiA+IGhvc3QsIGFuZCB2aWNl DQo+ID4gPiB2ZXJzYS4gQWxzbywgaG93IElQdjYgb25seSBob3N0IGNhbiBrbm93IElQdjQgYWRk cmVzcyBvZiBJUHY0IG9ubHkNCj4gPiA+IGhvc3QsIGFzc3VtaW5nIElQdjQgb25seSBob3N0IGlz IGluIGEgcHVibGljIGRvbWFpbj8NCj4gPiA+DQo+ID4gPiBTaW1wbGUuIFVzaW5nIGEgVHJhbnNs YXRvciwgZWl0aGVyIGF0IGxheWVyIDMgb3IgYWJvdmUgaXQuIEFueSBvdGhlcg0KPiA+ID4gd2F5 IGRvZXNuJ3Qgd29yay4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAtLS0tLS0tLS0tLS0gVGhl IGZhY3QgdGhhdCB0aGVyZSBpcyBhIGhpZ2h3YXkgdG8gaGVsbCBhbmQgYSBzdGFpcndheQ0KPiA+ ID4gdG8gaGVhdmVuIGlzIGFuIGludGVyZXN0aW5nIGNvbW1lbnQgb24gcHJvamVjdGVkIHRyYWZm aWMgdm9sdW1lLi4uDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+IGlwdjZAaWV0Zi5vcmcNCj4gPiBBZG1pbmlzdHJhdGl2 ZSBSZXF1ZXN0czoNCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbA0KPiA+DQo+IG1hbl9saXN0aW5mb19p cHY2JmQ9RHdJQmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTA0KPiBlYUp4 aGYzDQo+ID4gaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09clhuLQ0KPiBxY2ZTSWhqQjFG VlpxOWZUMEhXS0lFNEZzVlc1NVB3NHVmY2QNCj4gPiA0UWMmcz1HSGNOZEVodE9WSl9jTHZPSUli Nm9OTkRKSWdwYjhtX29xSGllUHFZaWNnJmU9DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPiAN Cj4gLS0NCj4gU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQ0K From nobody Fri Jul 5 12:17:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9343F12015F; Fri, 5 Jul 2019 12:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 zdqfLV9dkFy0; Fri, 5 Jul 2019 12:17:02 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC44E120140; Fri, 5 Jul 2019 12:17:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mop8/tyUkPTzbs25DpcqevSHewEsVQY4wRGCvSr/vHkxwF0vk0L5w66x3g4nHt3Z27+0ZSNpa5vB1hfshWgrsr+1++4/OX9eMiFFVzM+0hO9iySfBplmXT5e861bRjrNcQgVkxULVAhlB51VytRbYqC9Huqu4Aw/T1OS+wsUqEivz2tzmPv0PJwY4YwPZ8hogP5USOCjKk6uc2mAtE4XMamrzPHR6bs8dVKvuXvkyVq8F7Eh6y0VkQDNSX97Gv+mlBis9jRiUQ4tcCMmt4LeGt+GIhO4ik/2WbCjpFJCBmWjUi62VKchLIjEOpbbYn3UClilQvgkiYBva9AvThApDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=du4X/vXsJR6C2OkwrPAuJGn6RUaPVCuWMiSX/ESY5CU=; b=KJRbB8SYformxh4nXVrf8iax0zFvK0l4B6Q3DVd+Bqt+LrS08kCmGAVc7jhTUbLZ9DQtxUg538mIJjxqQnPm7pyYS9zaJOyOPgX1kKaj8ZB2d4wvyBecXh5y7IA3BZc0HqD2oOATaLir/+380RhHz9KCfAmwFbjnWJdiE5/WxtqFj9WwEJiI3ppdWvScCqO9Sq8XNUNYn91548DrEVXghyAp6mYgewDmvk1yCj1Q4kDc9nYSdbL0q20WaeeuhpQQOe0yO8GqjB7IqfOuQP7/Ci/rS8/Ue3TwBbiNleLWUy7Ga2K7nIgvbbdAZiFFP5ND7asfKjG2kFlshTqLCEvBlw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=du4X/vXsJR6C2OkwrPAuJGn6RUaPVCuWMiSX/ESY5CU=; b=g7t8PnjdDeKpmbDYzUIxrGX/6Um6iAZR2ZREk22yqgMq8Ehivg2gosP1KvYTE9nmNVdbm1aTnIBYv1I3CAcnj25DRiVhoOSGb3qDkiCjVkpAE4FUED3C32X3P7L/VjtfK4lziA2Yrv6UNha82PsP0/EIP16qWH1OXvCHRjTP8gk= Received: from BN6PR21MB0497.namprd21.prod.outlook.com (10.172.112.7) by BN6PR21MB0834.namprd21.prod.outlook.com (10.173.205.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.2; Fri, 5 Jul 2019 19:16:59 +0000 Received: from BN6PR21MB0497.namprd21.prod.outlook.com ([fe80::5885:95cf:9573:e243]) by BN6PR21MB0497.namprd21.prod.outlook.com ([fe80::5885:95cf:9573:e243%14]) with mapi id 15.20.2073.004; Fri, 5 Jul 2019 19:16:59 +0000 From: Dave Thaler To: tom petch , Suresh Krishnan , int-area , 6man , dhcwg , V6 Ops List , "opsawg@ietf.org" , "softwires@ietf.org" Thread-Topic: [Int-area] AD sponsoring draft-thaler-iftype-reg-02 Thread-Index: AQHVIUvM9WEXtmDvEkCRovcCdcQgcKa8iIaA Date: Fri, 5 Jul 2019 19:16:59 +0000 Message-ID: References: <75825363-B4BA-4F94-A935-B87F474F06C9@kaloom.com> <019801d522ce$34bff3a0$4001a8c0@gateway.2wire.net> In-Reply-To: <019801d522ce$34bff3a0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-05T19:17:02.2121879Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a3b4b581-53d2-45cd-a339-063f355f76bd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [73.59.106.235] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e95636a2-2563-4569-b98b-08d7017d5a95 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BN6PR21MB0834; x-ms-traffictypediagnostic: BN6PR21MB0834: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(346002)(396003)(366004)(136003)(376002)(54094003)(43544003)(45074003)(51444003)(13464003)(53754006)(199004)(189003)(99286004)(256004)(7696005)(33656002)(53546011)(6506007)(102836004)(76176011)(186003)(26005)(790700001)(6116002)(3846002)(110136005)(296002)(316002)(22452003)(5660300002)(2201001)(52536014)(86362001)(71200400001)(71190400001)(6436002)(229853002)(76116006)(73956011)(66446008)(606006)(6246003)(64756008)(6306002)(9686003)(236005)(53936002)(66946007)(476003)(54896002)(8990500004)(486006)(14454004)(478600001)(2906002)(66476007)(11346002)(25786009)(55016002)(7736002)(2501003)(446003)(68736007)(966005)(66066001)(10290500003)(81156014)(81166006)(74316002)(8676002)(10090500001)(8936002)(66556008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0834; H:BN6PR21MB0497.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VcHCideBC6gPSt3P4J8VfuoYxGpxysysckXhxOom9YSznzh+jMU01aVXnFQQlLX8FEXHofYNaqtTd7Qblfm6d5vV15OD7Yx9jpQdpOvSQwB21l9hcPqm7tMwaKeEuaywphNThEodJuHHbwS4qcFjGdTGi/6wPB8J8Kj2I2vSD7WogPwDBHJQQK+H2F/+qpzrRU09m4rOiSb7XUTDPcdyW6O5H0GozUo/DAieFfxyowQGKMXnuYuQcslRLlznUyBhbtLAZMEg8Ixv3GFhuQP0WepUOXtGDaJUDmXjwuCiADM3PGqY6HPYnvWFb//dwNW1l2fJykfa37hQvmrqRbiN6m1eiHQneMyB6YIbOxftJxQWaYZxwv/XmZzwHIIO13+f+xoBttwpv+qeRX8PcdyzyscNpsgCHXCxCeHKf71LhvU= Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0497AE6B319A4879D041AA81A3F50BN6PR21MB0497namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e95636a2-2563-4569-b98b-08d7017d5a95 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 19:16:59.6427 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dthaler@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0834 Archived-At: Subject: Re: [v6ops] [Int-area] AD sponsoring draft-thaler-iftype-reg-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 19:17:17 -0000 --_000_BN6PR21MB0497AE6B319A4879D041AA81A3F50BN6PR21MB0497namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: dhcwg On Behalf Of tom petch Sent: Friday, June 14, 2019 9:28 AM To: Suresh Krishnan ; int-area ; 6man= ; dhcwg ; V6 Ops List ; ops= awg@ietf.org; softwires@ietf.org Subject: Re: [dhcwg] [Int-area] AD sponsoring draft-thaler-iftype-reg-02 Suresh The concern I have is that it muddies the waters further on the standing of= tunnels so while I think that its proposals for ifType per se are fine, I = would like it to make explicit that tunnels are out-of-scope at this time. Tunnels are certainly not out-of-scope. There's two existing registries (i= nterface types and tunnel types), and this draft documents existing registr= ation process, and some process clarifications to address points of process= confusion and ease process friction today. I have been trying to reconcile the workings of softwire, in creating a tun= nel YANG module, with the existing IANA structure and failing. I believe t= hat is because the current status of tunnels is unclear. Thus the softwire= I-D refers to a registry that does not exist Yes it does. The software I-D does not create any new registry. It only= creates another format for retrieving the contents of an existing registry= . Many registries are retrievable in multiple formats (XML, excel, txt, et= c.). This registry is no different. What I can do is add a paragraph explaining the use of multiple formats for= the interface type and tunnel type registries, to make it clear that each = format is not a separate registry, just like getting the TCP port registry = in XML vs excel is not two different registries. Dave (as such) although the URL that the softwire I-D does. I think the timing u= nfortunate in that IMHO the softwires I-D will get pressed ahead before thi= s work can complete, so quite what this I-D then says about tunnels will be= coloured by what then exists for tunnels. So this I-D should make clear what a tunnel is, when it is not an interface= , but otherwise declaring tunnels out-of-scope, for a future I-D to do a co= mparable job for tunnels, setting up a tunnel registry from which MIB modul= es, YANG modules and anything else can be derived (as long as the relevant = data is supplied - SMI needs integers, YANG does not, which I-Ds do not alw= ays recognise although the Designated Experts can take care of that). Finally, when I first encountered this I-D I asked on NETCONF and NETMOD WG= lists if anyone knew of it, where it was being worked on and got no reply = - which surprised me. I note that you have not copied them although they w= ere involved in making the interface type registry what it currently is whe= n creating the YANG module for interface types. I wonder if other WG have = an interest, CCAMP or TEAS perhaps. I agree that int-area is the WG best e= quipped to work on it and that it needs working on. Tom Petch ----- Original Message ----- From: "Suresh Krishnan" > To: "int-area" >; "6man" >; "dhcwg" >; "V6 Ops List" >; >; > Sent: Wednesday, June 12, 2019 7:22 PM Hi all, I would like to AD sponsor the following draft that provides guidelines f= or definition of new interface types in the IANA IfType registries https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-thaler-iftype-reg-02&data=3D02%7C01%7Cdthaler%40= microsoft.com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636961265202763707&sdata=3DHM5asXOFnSuzPaCR4k4kopqsI= HLLdnqZ7PDuu8hPJM4%3D&reserved=3D0 If you have any concerns either with the contents of the draft, or about me= AD sponsoring it please let me know before 2019/06/26. Thanks Suresh NOTE: I have CCed: all the working groups that I thought could be potential= ly interested in this work. If you think I have missed out some WG(s) pleas= e let me know. ------------------------------------------------------------------------ -------- > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=3D02%7C01%7Cdthaler%40 > microsoft.com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91a > b2d7cd011db47%7C1%7C0%7C636961265202763707&sdata=3Dznz7EZ1q%2FwIQUJC > gYZTWfY2H4C7tN6qFhJubCVWxWzc%3D&reserved=3D0 > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fdhcwg&data=3D02%7C01%7Cdthaler%40microsoft= .com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C636961265202763707&sdata=3DOJvbRDz%2FCIlVF3hWR30KCs0cRgi9Kmtn= YLHKbHSeJzc%3D&reserved=3D0 --_000_BN6PR21MB0497AE6B319A4879D041AA81A3F50BN6PR21MB0497namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-= ----
From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of tom petch
Sent: Friday, June 14, 2019 9:28 AM
To: Suresh Krishnan <Suresh@kaloom.com>; int-area <int-area@ietf.o= rg>; 6man <ipv6@ietf.org>; dhcwg <dhcwg@ietf.org>; V6 Ops Li= st <v6ops@ietf.org>; opsawg@ietf.org; softwires@ietf.org
Subject: Re: [dhcwg] [Int-area] AD sponsoring draft-thaler-iftype-reg-02

 

Suresh

 

The concern I have is = that it muddies the waters further on the standing of tunnels so while I th= ink that its proposals for ifType per se are fine, I would like it to make = explicit that tunnels are out-of-scope at this time.

 

Tunnels are certainly= not out-of-scope.  There’s two existing registries (interface t= ypes and tunnel types), and this draft documents existing registration proc= ess, and some process clarifications to address points of process confusion and ease process friction today.

 

 

I have been trying to = reconcile the workings of softwire, in creating a tunnel YANG module, with = the existing IANA structure and failing.  I believe that is because th= e current status of tunnels is unclear.  Thus the softwire I-D refers to a registry that does not exist<= /p>

 

Yes it does.   The software I-D does no= t create any new registry.   It only creates another format for r= etrieving the contents of an existing registry.  Many registries are r= etrievable in multiple formats (XML, excel, txt, etc.).   This registry is no different.

 

What I can do is add a paragraph explaining the u= se of multiple formats for the interface type and tunnel type registries, t= o make it clear that each format is not a separate registry, just like gett= ing the TCP port registry in XML vs excel is not two different registries.

 

Dave

 

(as such) although the= URL that the softwire I-D does. I think the timing unfortunate in that IMH= O the softwires I-D will get pressed ahead before this work can complete, s= o quite what this I-D then says about tunnels will be coloured by what then exists for tunnels.

 

So this I-D should mak= e clear what a tunnel is, when it is not an interface, but otherwise declar= ing tunnels out-of-scope, for a future I-D to do a comparable job for tunne= ls, setting up a tunnel registry from which MIB modules, YANG modules and anything else can be derived (as long = as the relevant data is supplied - SMI needs integers, YANG does not, which= I-Ds do not always recognise although the Designated Experts can take care= of that).

 

Finally, when I first = encountered this I-D I asked on NETCONF and NETMOD WG lists if anyone knew = of it, where it was being worked on and got no reply - which surprised me.&= nbsp; I note that you have not copied them although they were involved in making the interface type registry what it = currently is when creating the YANG module for interface types.  I won= der if other WG have an interest, CCAMP or TEAS perhaps.  I agree that= int-area is the WG best equipped to work on it and that it needs working on.

 

Tom Petch

 

----- Original Message -----

From: "Suresh Krishnan" <Suresh@kaloom.com>

To: "int-area" <int-= area@ietf.org>; "6man" <ipv6@ietf.or= g>; "dhcwg"

<dhcwg@ietf.org>; &= quot;V6 Ops List" <v6ops@ietf.org>; <opsawg@ietf.org>; <sof= twires@ietf.org>

Sent: Wednesday, June 12, 2019 7:22 PM=

 

Hi all,

  I would like to AD sponsor the following d= raft that provides guidelines for definition of new interface types in the = IANA IfType registries

 

https:/= /nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org= %2Fhtml%2Fdraft-thaler-iftype-reg-02&amp;data=3D02%7C01%7Cdthaler%40mic= rosoft.com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91ab2d7cd01= 1db47%7C1%7C0%7C636961265202763707&amp;sdata=3DHM5asXOFnSuzPaCR4k4kopqs= IHLLdnqZ7PDuu8hPJM4%3D&amp;reserved=3D0

 

If you have any concerns either with the contents= of the draft, or about me AD sponsoring it please let me know before 2019/= 06/26.

 

Thanks

Suresh

 

NOTE: I have CCed: all the working groups that I = thought could be potentially interested in this work. If you think I have m= issed out some WG(s) please let me know.

 

 

 

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

--------

 

 

> ____________________________________________= ___

> Int-area mailing list

> Int-area@ietf.org=

> https://nam06.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.

> ietf.org%2Fmailman%2Flistinfo%2Fint-area&= ;amp;data=3D02%7C01%7Cdthaler%40

> microsoft.com%7Cbd9080f665064f564d3608d6f0e5= 5a88%7C72f988bf86f141af91a

> b2d7cd011db47%7C1%7C0%7C636961265202763707&a= mp;amp;sdata=3Dznz7EZ1q%2FwIQUJC

> gYZTWfY2H4C7tN6qFhJubCVWxWzc%3D&amp;rese= rved=3D0

> 

 

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org=

https://nam06.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailma= n%2Flistinfo%2Fdhcwg&amp;data=3D02%7C01%7Cdthaler%40microsoft.com%7Cbd9= 080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C= 636961265202763707&amp;sdata=3DOJvbRDz%2FCIlVF3hWR30KCs0cRgi9KmtnYLHKbH= SeJzc%3D&amp;reserved=3D0

--_000_BN6PR21MB0497AE6B319A4879D041AA81A3F50BN6PR21MB0497namp_-- From nobody Fri Jul 5 13:11:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437E1120118; Fri, 5 Jul 2019 13:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX6qQUbslr-a; Fri, 5 Jul 2019 13:11:22 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 CEEEB1200EF; Fri, 5 Jul 2019 13:11:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x65KBHck010679; Fri, 5 Jul 2019 16:11:17 -0400 Received: from XCH16-01-11.nos.boeing.com (xch16-01-11.nos.boeing.com [144.115.66.39]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x65KBC78010646 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 5 Jul 2019 16:11:12 -0400 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-11.nos.boeing.com (144.115.66.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 5 Jul 2019 13:11:11 -0700 Received: from XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b]) by XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.1713.004; Fri, 5 Jul 2019 13:11:11 -0700 From: "Manfredi (US), Albert E" To: "Mudric, Dusan (Dusan)" CC: IPv6 Operations , 6man <6man@ietf.org> Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AdUx0cT0siGdnGcqO0Oy0E0RKZ7PVQAPuuUAADPtxoAADKc3gAAjb/oAAA0OlrA= Date: Fri, 5 Jul 2019 20:11:11 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: 6D89DBE17893F652DAA7855B1855B9483489F02EA855E84D4311BAB3873358512000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 20:11:24 -0000 -----Original Message----- From: ipv6 On Behalf Of Mudric, Dusan (Dusan) > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and vic= e versa? IPv6 to IPv4 should be straightforward, because it's a one-to-one relations= hip. The other way around would normally not work, but everyone has been ac= customed to that with IPv4 NAPT already. The client behind the NAPT initiat= es. > Is DNS64 server returning IPv4ony client address to IPv6only client, usin= g the A RR? The DNS synthesizes the IPv6 address, which has the IPv4 address embedded i= n it. > - How can IPv4only client get the address of IPv6only client (or, it is i= mpossible for IPv4only client to get IPv6 address of IPv6only client)? That's clearly more difficult, which is why the normal course of action is = for the IPv6 client to initiate the session. > - Do these IPv4 and IPv6 client addresses need to be pre-configured on th= e translator and/or DNS64? For IPv4 to IPv6, if you must allow the IPv4 client to initiate the session= , you'd have to have preconfigure something. Bert From nobody Fri Jul 5 17:59:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FE61200DB; Fri, 5 Jul 2019 17:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 cMUMpydjgbcE; Fri, 5 Jul 2019 17:59:00 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A531200A3; Fri, 5 Jul 2019 17:59:00 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id m202so8334581oig.6; Fri, 05 Jul 2019 17:59:00 -0700 (PDT) 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=owzsl6XFyT+C5dmqMCbuzHtvT9h9Dkmf5Q9sz/vIJv0=; b=FN1ggmX+fvU/4KNt+EFYlkq84bSZ9g4UVY3fZxbcBr4hTQcrRa5DrGvnCmHQsmUuxH AerBkE5B+bDgz5i/mQi7di0EOxqy1ZKVhhN/xTM/kiMw9+6pMhY4rATnKX/zloas5Ctr 2tvdYc2i2DWGTGEFyUcLQ1Fcy+KyUXZRPJ1ljh+fgYBoxz3i46q3d6cnF5MNXW6T1CHx O8lG0faDGR9JcWuSrkRhw0UhTPUc/klWPACNBWfKBRTwJgbgZm8ooYwUBFTpoOeKivpq 6mCFAGik+G+cOXjKvqmtrMADT11FFH8NP8vLjWK3SlcbRCCrJleGG2gKIhpp7+M45sQF +g8Q== 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=owzsl6XFyT+C5dmqMCbuzHtvT9h9Dkmf5Q9sz/vIJv0=; b=N5VbtfqbGAwh/M8/waU+heAZBKKo6PcXobP0rXHbcXFrGyDBOOYANCBhZE/X3UM8X3 jRlACu5TBuBa031QO2d8XecWrRo6ojGTI2+ooXPCw2Zrf/+7cBUaSf+1Ed2RYst0cPzN 3NtAg5zFmG2QMtLMBLMeTXdxxrhGe5+0Sn7lO+h69yfkH5dhoVu1p/h3UBOwh0JHd2Gx DlF/tZ++F3sAmb4OICXBSc/Ic6iudQy1ug4lchQZePkwtBKEpRa7lKrmMuKdFrEgh95E yTc9YnkwJA4weE1XQUgvHJSYv99AxJ7tD2tEL9ekrgTiN+S318uNfbIn+YIL7saft0v+ qVSw== X-Gm-Message-State: APjAAAVgwtbNVmgw5yrhIgbTpgHsC4pkjTyvMkaquAjCaN+sJAcqKov/ gKsInojA4r6WTKN7SHbicKglvZuxJUmIpcO6dVQ= X-Google-Smtp-Source: APXvYqwXCSp38550+o5P7E5x9g1K0tjnk7LFQF+PJExcSqHa8L8IbCfui+2ceE4BqKcOSOruc/hKx/O7QPQawaVw8vk= X-Received: by 2002:a05:6808:8d3:: with SMTP id k19mr476324oij.164.1562374739579; Fri, 05 Jul 2019 17:58:59 -0700 (PDT) MIME-Version: 1.0 References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> <4250.1562178592@localhost> <7744.1562353657@localhost> In-Reply-To: <7744.1562353657@localhost> From: Mark Smith Date: Sat, 6 Jul 2019 10:58:33 +1000 Message-ID: To: Michael Richardson Cc: Jen Linkova , v6ops list , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 00:59:02 -0000 On Sat., 6 Jul. 2019, 05:08 Michael Richardson, wrote: > > > Jen Linkova wrote: > >> 5-10 seconds seems really high... it is really explained by just the > >> pathology you described? > > > Yes, because as soon as the NC entry appears in the router cache the > > issue goes away. So users normally complain if they have not connected > > the particular device to the network for a while. > > So let me ask the question differently: why is it taking 5-10 seconds for the > NC entry to appear? > > Let me repeat what you wrote in my own words: > > 1) device gets online, gets address via RA, uses SLAAC/RFC4941, configures > addr Q. I don't think it matters if the device sees a multicast RA, > or solicits one with a RS. > The device also does DAD here. > > 2) device sends TCP SYN to "does this work" test A via router X. > (http://detectportal.firefox.com/, etc.) > > 3) respond from A arrives at X, no NCE exists, sends out NS for Q, router X > tries to buffer it, but since there are many devices, the reply gets > dropped. > > 4) device answers NS with NA unicast to X, NCE is created. No packet > is released, since there isn't one. > > > > 5) device eventually retransmits TCP SYN to test A via router X. > 6) reply gets back to Q since NCE exists. > > > It has been asserted above that as soon (4) occurs, that it's all good. > I'm skeptical, wondering isn't it (5) that is the key point. > > So I assume that I mis-understand something about how things work. This is what is going to be happening, however the queue of 1 ND trigger packet isn't big enough anymore. From what Jen has described in her draft, nodes are attempting to establish far more than one connection when they first attach to a link. The problem occurring isn't really a new one. Cisco's original IOS ARP implementation doesn't buffer any packets all that trigger an ARP Request, which is why it is common to see the first packet lost when e.g. pinging a destination behind a newly booted router. It would also explain why IOS holds onto ARP entries for 4 hours, rather than the more typical 5 minutes. RFC 1122 permits this behaviour although advises against it. A form of address registration is the only way to overcome this, and also will completely mitigate router ND cache DoS attacks from off-link sources. Host implementations would have to delay allowing applications to attempt to establish connections until address registration is confirmed. Regards, Mark. From nobody Fri Jul 5 19:19:33 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3941201FA; Fri, 5 Jul 2019 19:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 Xe2g2NfWT0wt; Fri, 5 Jul 2019 19:19:16 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 C0F33120145; Fri, 5 Jul 2019 19:19:15 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id e8so10755793otl.7; Fri, 05 Jul 2019 19:19:15 -0700 (PDT) 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:content-transfer-encoding; bh=CTX2PzrAHmmYDa56JNQPReiM136e/fybVoIdxQ41dx4=; b=S/0BppBPINsK0P3mT5DLxQvLQzKXMt5V6RTu+Ce8QxDsHSYy0AuV+j9I73ZFOJTKrT y3eCDM16+CTBbpw7tggViE62zpNHOl2+u5QVXwqzhfTBnEDvj4Bl65ql2Qo+GvpbH0cE iNn8CvpU/mzcAtISjUTAD/NCTIxQ5WfnGbkUJNuHJS7FQKmAp3iBcr0YZJnhuIj55Cfr e7ePSfCBCYpKcmIFHpuuE+6Wo6KcAZALyYtkxYfxaotDZZG/zDe8TVbbTQq3RnybG13A BJXxO+VFDK9/Dl2uPHKgPBcGGmc8KaA+yBhoqRTfoBI5T4s5a2m6o/iU8K5t8rGqV4We HWsA== 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=CTX2PzrAHmmYDa56JNQPReiM136e/fybVoIdxQ41dx4=; b=KWOnmuCuPiTZtZfbIDVcggA/Nm+9X4vNEBjPyZ03J8Z+78KK/sp6YDM8jwKpZE9JSQ 66okTJwPnCkle78F3VAQxma3npLTxzG7ZculDjCTw46cIRu5+7r29Ys2Dgq9UOFs04ES pcQJFinLS5N3lhVgJk3tpv9Yya4Plcxwc3ZqWZZJeO0eiml4fJ0h3UQzJ4Fnon6VAnTJ e2bABAz2f1C77/B/jd29kArdlwWYUbvMGCYgmOUWiHcqvgw5jflVouiTIyil5v9V5Q2f IoNh6pCxJctUzoDjmuagqTH8nkWOsY41I1CxIPdw7uO4hncCeORTPj6cR/qwkkbqw/Zz x/qQ== X-Gm-Message-State: APjAAAXJ+sZvrRVRXx6d+nhGgjLbJA890w8UKE7U5ci+cRaRKN54fUHy T99T91cZKOSaKcK7vo83pxH3ndbc/xVZV42PGgI= X-Google-Smtp-Source: APXvYqwqzllWsLlZGRLEeXzawRv5VF90T9FqPYEDKacoGdFVRJvFz57iKS92Pq9fQD4AFqmNGCfnRAsMAFFzDPCY2j8= X-Received: by 2002:a9d:66c8:: with SMTP id t8mr5410656otm.94.1562379554969; Fri, 05 Jul 2019 19:19:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Sat, 6 Jul 2019 12:18:48 +1000 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Carsten Bormann , Michael Richardson , V6 Ops List , 6man <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 02:19:18 -0000 Hi Pascal, On Thu, 4 Jul 2019 at 23:24, Pascal Thubert (pthubert) wrote: > > Hello Mark: > > > > There are a number of things that the router would like to know in the p= rocess: > > A sense of lifetime; how long should the router/L3AP expect that the addr= ess will be used; at time out, the router can clean up the state. Already being performed by NUD right now. NUD avoids the possibility of the router's view of when an address expires getting out of sync with when the address does or has expired on a host. > A sense of order; if a wireless node moves rapidly from a L3AP to the nex= t, or a VM moves rapidly from a server to the next, which is the most recen= t point of attachment What sort of device is a "L3AP"? In RFC 8200 we don't have that sort of device defined, we just have links, hosts, routers and nodes (IPv6 host or router). I'm guessing it is a combined layer 2/layer 3 device with tight integration between layer 2 and layer 3 processing? If it is, we wouldn't want to create a requirement that all layer 2 devices are also layer 3 routers for all IPv6 networks. > A sense of ownership; if the router maintains a state about the address f= or a requested lifetime, then a proof of ownership can be attached, so only= the owner of the address can modify the state (SAVI) I think that can be achieved using using the state that NUD maintains and is already occurring. For example, an unsolicited NA can be sent to update remote devices' neighbor cache entry for the address with a new link-layer address, however the update only occurs if the remove device already has an existing neighbor cache entry for the address. > A sense of service; what should the router do with that address? Examples= that come to mind are inject in a routing protocol, play sleeping proxy or= ND proxy. > These requirements seem to be more specific to 6lo environments, rather than a more general and common cases. For example, hosts' addresses aren't injected into a routing protocol in most networks. However, once a router has knowledge of the existence of an address, then I think what the router uses that address knowledge for, in addition to forwarding, is out of scope for an address discovery or registration protocol. Regards, Mark. > > > It does not take new messages but a new option is needed to provide all t= hat information. > > > > All the best, > > > > Pascal > > > > From: Mark Smith > Sent: jeudi 4 juillet 2019 14:39 > To: Pascal Thubert (pthubert) > Cc: Carsten Bormann ; Michael Richardson ; V6 Ops List ; 6man <6man@ietf.org>; 6lo@ietf.org > Subject: Re: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs > > > > > > On Thu., 4 Jul. 2019, 21:38 Pascal Thubert (pthubert), wrote: > > This is all very right, Carsten. > > > > RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty m= uch a > > no-brainer, if that foo has points where the 6LBR functionality is natu= rally > > centralized. > > No brainer it is, but for Lorenzo's issues on state preservation or recon= struction upon router reboot. > > > > I think that can be overcome. > > > > I've been thinking for a while how to build something like this using exi= sting protocols and host or router behaviour. > > > > Fundamentally two stages: > > > > - collect nodes' link local addresses > > > > - query nodes' for their other GUA or ULA addresses > > > > Collecting nodes LLAs can be done via collecting source addresses from no= de emitted RSess and/or MLDv2 reports. > > > > Once they've been collected, then nodes are unicast queried by routers fo= r their other addresses via either ICMPv6 Node Information queries or Inver= se ND. > > > > (There is currently a limitation with ICMPv6 NI that it doesn't report te= mporary addresses for security reasons. That could be lifted by e.g. saying= that all addressed including temporaries are reported if the NI query sour= ce address is an LLA i.e. limited to a query from an on-link source, or bot= h LLA source and that the LLA is that of a known default router.) > > > > A new node on the link effectively announces its LLA to existing routers = via RS and MLDv2 joins for solicited node groups for its addresses (and oth= er multicast groups it may join). > > > > If a node configures a new address, it joins the address's Solicited Node= Multicast group. Routers use that as a signal to unicast query the node it= for its updated address list to discover the new address. > > > > (DAD is another possible way for routers to collect new address informati= on, however I think Ericsson have some IPR over that idea, and it also does= n't work for anycast addresses, because DADs aren't performed for them). > > > > Routers detect when an address disappears via standard ND NUD. > > > > A new router on a link can collect existing nodes' LLAs via a general MLD= query, as it does anyway to collect the set of multicast groups on the lin= k. Once the new router has that set of LLAs, it then unicast queries the no= des for their other addresses. > > > > > > Perhaps a bit of pedantry, however if nodes are "Neighbours", since we no= w have possibly multiple addresses per node/neighbour, ND isn't really disc= overing neighbours, it's actually discovering the presence of addresses, no= t "neighbours". Address Discovery or Address Presence Discovery would perha= ps be a more accurate name for this function. > > > > Regards, > > Mark. > > > > > > > > Not so easy for brownfield, i.e., in networks where classic ND is alrea= dy used in > > some hosts and some routers. =E2=80=9CEfficient ND=E2=80=9D (which was= essentially RFC 6775 > > for Ethernet and thus also traditional Wi-Fi) mostly didn=E2=80=99t tak= e off at the time > > because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransitio= n=E2=80=9D) strategy. I=E2=80=99m sure > > we can do that if we put a little more focus on it, leading to another > > specification that describes how to run in mixed classic/efficient ND n= etworks. > > For I started that at 6lo and there is text in https://datatracker.ietf.o= rg/doc/html/draft-ietf-6lo-backbone-router , e.g., in section 3.2. The coex= istence is also discussed in https://tools.ietf.org/html/draft-thubert-6lo-= unicast-lookup but at some point it is not a 6lo problem anymore and that w= ork should really move somewhere else. > > Being non-maintenance, it seems too early for 6MAN. If so maybe we should= form a short-lived WG to sort out the issues raised by Lorenzo, yours (co= existence) and mine (limit use of broadcast / interface with a fabric mappi= ng server and do unicast lookup when possible). > > All the best, > > Pascal > > > -----Original Message----- > > From: Carsten Bormann > > Sent: jeudi 4 juillet 2019 13:22 > > To: Pascal Thubert (pthubert) > > Cc: Michael Richardson ; 6lo@ietf.org; V6 Ops Li= st > > ; 6man <6man@ietf.org> > > Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LA= Ns > > > > RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty m= uch a > > no-brainer, if that foo has points where the 6LBR functionality is natu= rally > > centralized. > > > > Not so easy for brownfield, i.e., in networks where classic ND is alrea= dy used in > > some hosts and some routers. =E2=80=9CEfficient ND=E2=80=9D (which was= essentially RFC 6775 > > for Ethernet and thus also traditional WiFi) mostly didn=E2=80=99t take= off at the time > > because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransitio= n=E2=80=9D) strategy. I=E2=80=99m sure > > we can do that if we put a little more focus on it, leading to another > > specification that describes how to run in mixed classic/efficient ND n= etworks. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) > > wrote: > > > > > > Hello Brian: > > > > > > Yes, I'm willing to make the case. > > > > > > There are a number of reasons to enable a registration method on beyo= nd > > 6lo networks: > > > - It is useful in wireless in general because it addresses non-transi= t > > > multipoint links (see > > > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireles= s > > > /) and NBMA ML-subnets > > > - it is useful in particular in Wi-Fi because it reduces the need for= broadcast > > quite dramatically. > > > - It is useful in a switched fabric to maintain an accurate state in > > > the overlay mapping server (see > > > https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/) > > > - It is useful in a situation of host mobility in general, (see the > > > discussion in > > > https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 ) > > > - It is useful for routers with hardware assist forwarding to avoid > > > the punting dance and dropping of packets > > > - It provides SAVI properties with a workable Secure ND (see > > > https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/) > > > - It provides an abstract interface to the router to get routing > > > services (already used with RIFT, RPL, see > > > https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and > > > ND proxy, see > > > https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/) > > > - It solves a number of problems including Jen's, but also sleeping d= evices on > > non-6lo networks, remote DOS against router and ND cache, and more. > > > > > > All in all I see it as a much needed modernization of ND to cope with= the > > evolutions of the network (IOT, Wi-Fi and overlays) and with the new ne= eds > > and behaviors (instant connectivity, fast roaming). > > > > > > All the best, > > > > > > Pascal > > > > > >> -----Original Message----- > > >> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Michael Richardson > > >> Sent: jeudi 4 juillet 2019 02:58 > > >> To: 6lo@ietf.org; V6 Ops List ; 6man <6man@ietf.org> > > >> Subject: Re: [6lo] ND cache entries creation on first-hop routers > > >> > > >> > > >> Brian E Carpenter wrote: > > >>>> I=E2=80=99m interested to have a parallel discussion on where RFC = 8505 can > > >>>> not apply. In the products and use cases I=E2=80=99m aware of, it = could, > > >>>> since we are actually faking it by snooping ND and DHCP to achieve > > >>>> similar but less accurate results. > > >> > > >>> So if you are advocating a generalisation of RFC8505 to non-6lo > > >>> LANs, that's certainly a discussion we could have, IMHO. > > >> > > >> I think that it could be applied in situations of servers, such as > > >> data centers where there are multiple tenants. (Many VM > > >> infrastructures have shared front-end networks) > > >> > > >> I think that temporary addressess are not a feature in some of those > > >> deployments that everyone wants, and thus having a registration > > >> system is a feature. > > >> > > >> This does not solve the smartphone on new WIFI issue, which is a > > >> different situation completely. > > >> > > >> -- > > >> ] Never tell me the odds! | ipv6 mesh = networks [ > > >> ] Michael Richardson, Sandelman Software Works | IoT arc= hitect [ > > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ > > > > > > _______________________________________________ > > > 6lo mailing list > > > 6lo@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lo > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jul 5 21:07:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FDE1202D1; Fri, 5 Jul 2019 21:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 EAnRPSYcDL2K; Fri, 5 Jul 2019 21:07:05 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 D37A11201F1; Fri, 5 Jul 2019 21:07:04 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id d17so11686395qtj.8; Fri, 05 Jul 2019 21:07:04 -0700 (PDT) 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=t9KmPqwD5ov3v9bkOd4/mlWRZ1R3b3NgXbFjE0tCepY=; b=Smlqxn3DV8yBEmhEVgnf/x+AkgZChU6g0odLEYHknMcbSBmYTC9P9Sw7sDHnfZw5J3 T8znhX/piJ1VcDRtiGR9W4hGfMmEbKE379wr9GF/yxBted+UKzKQpQldqNhHwAFLJ11f ru6SxqqUNNcqh616W/XZWwqKluEyoPWtNl9GVBkOhsu9QMoLYFTcyWRHj9y7uZkkT+3T HPqEdgrNmmSoUwQOvRsR3cnRmUsEq1A4Ann814mwS17BZsoa/HN5PqX35txg0oU7Irh9 qRP9yk6ApyVEuQtXADR9XbuhNjodTitLIx5MmCrdL9CvvlGslV5qEupqUFFNQ3oX4cJr yu6Q== 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=t9KmPqwD5ov3v9bkOd4/mlWRZ1R3b3NgXbFjE0tCepY=; b=WaDOlhsuyvhZKd1JHB4mFPiykbPNlb53gMROU04Y2VkQQWIjWrxT95FZGyYakyJ/86 UMbqKGpwWkl2FkFpFZHZ9h7Eeqk6CblylHyU4v8lP6CgcU4Yk0QyeJQMgl8Hv+iDVMt9 9YNkntm5BI9N1yf6IXeEI/MJQptAiLNiq+KlWRMAuBC70TPpVbgeY6wGqBZ6+pFZH4PY 4z6oiZiYSA1uSWn1OHF6xUZ9tfkre4TB6O0Z5qewReqURQ2zOUG4akyKVwLsv7panYBa jlFXhy2PcfcPfV2lbpgKomyBpP+MQRNWoT02Q0+fyAODdFoQ7h8giyy8M+oqW8V5IBnj 1uCA== X-Gm-Message-State: APjAAAVrQSz8JutRDYOUH3ORXfpk0jlNy/PaMEkrIRUk9GKGxjiuet7Z 4mdi658SzRC7lpXRZN1pEgyswX25dvs+QGbqW1/HEg== X-Google-Smtp-Source: APXvYqyoPAKcjj+UT8iMJN/SqqogEJ5/kyn6QHSsSpW03NO3yzHtXfaNj+phap6UGMy44YrcgDVD2t9+kCCecocDCtY= X-Received: by 2002:a0c:b0a8:: with SMTP id o37mr983471qvc.76.1562386023789; Fri, 05 Jul 2019 21:07:03 -0700 (PDT) MIME-Version: 1.0 References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> <4250.1562178592@localhost> <7744.1562353657@localhost> In-Reply-To: <7744.1562353657@localhost> From: Jen Linkova Date: Sat, 6 Jul 2019 14:06:52 +1000 Message-ID: To: Michael Richardson Cc: V6 Ops List , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 04:07:07 -0000 On Sat, Jul 6, 2019 at 5:07 AM Michael Richardson wrote: > So let me ask the question differently: why is it taking 5-10 seconds for the > NC entry to appear? I'm not saying it takes 5-10 secs for the NC entry to appear. It takes 5-10 secs for applications to receive all traffic they want (with timeouts, retransmits and exponential backoffs) > Let me repeat what you wrote in my own words: > > 1) device gets online, gets address via RA, uses SLAAC/RFC4941, configures > addr Q. I don't think it matters if the device sees a multicast RA, > or solicits one with a RS. > The device also does DAD here. > > 2) device sends TCP SYN to "does this work" test A via router X. > (http://detectportal.firefox.com/, etc.) Device might open multiple parallel connections to various destinations. > 3) respond from A arrives at X, no NCE exists, sends out NS for Q, router X > tries to buffer it, but since there are many devices, the reply gets > dropped. or because there are many packets arriving for Q - so the router buffers the first one only. > 4) device answers NS with NA unicast to X, NCE is created. No packet > is released, since there isn't one. ...or it's just one instead of many. > > > 5) device eventually retransmits TCP SYN to test A via router X. > 6) reply gets back to Q since NCE exists. > > > It has been asserted above that as soon (4) occurs, that it's all good. No, it's all good if (4) becomes (2.5) and happens *before* (3). So when the packets arrive the router has the NC entry already - at least in STALE state. > I'm skeptical, wondering isn't it (5) that is the key point. It is. As soon as (4) happens before (3), there is no delay and (5) does not happen. -- SY, Jen Linkova aka Furry From nobody Fri Jul 5 21:10:41 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB59A120356; Fri, 5 Jul 2019 21:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 uzZ-jyO3uIJa; Fri, 5 Jul 2019 21:10:25 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 0DB1B120363; Fri, 5 Jul 2019 21:10:25 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id k10so5466552qtq.1; Fri, 05 Jul 2019 21:10:24 -0700 (PDT) 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=H9VUFoJBg0SThF/SdUPPG0ygzs6j5gdHQSR3WHo9gaI=; b=HNmGzF5rHfmqIXzrI2FCy5OKxDVj3kgYomDhKlHPHCrF/Yp4Z8ZDN9hJreBYMRZOkx jSpDF1+1dAfzQ6sOjEBn+YR5Fr5jQiD90qninm8qcTQCQPEpLcWQmqNIL4X5tdOnm3zf uVrg8eodfS7aD2GdDx7Wc7J/m9k3iqrDVKCaRAdaJ4TSliRAMr2Q/Jz7ZN8lKJumtYhY KSs9UnbxUq0tG5nKl65P0ogCiXQnOyCfz5b2bS3p90W3XR4DPh3q5UdhORdlUNe/4+fs ZXTMo9QV00f9PNvHtnrJ3mCn1Zf5ZGBW06Nt+2AkJsArk47czQeVMarwNvz2DB2PZb4h OCcQ== 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=H9VUFoJBg0SThF/SdUPPG0ygzs6j5gdHQSR3WHo9gaI=; b=F/W67FAoAzzTlpDaTxWEwUch82dVUHdaFSuME2oVaZcXqMXCiz2rrL6uMU2XrgL7+4 xdGOgJePj6zP41mrR3Aym5Uf8AHX7nNDxZi4FOkxR6c0zGWBYQLMq9FB9gnKzO7huCe7 4KlYn0yB9YTzVXG9a3TB7HHw0JNpDMGNhX1k3uVMx7vQNJrSmyjI6IGmeHhTw/02B5kA HRCI4joR2H90W7RvUAv7g5u1QWnCf3mTYH2hnBzicbQ4cWujLpqyJL5YnfPVDifWkE0t pXoxXIxflpcubZDNuYZEnnG4OgeBAhTy8WNWM0Qg88Lm0dC50UH4NDv8CLwnYcpaguFp eaEQ== X-Gm-Message-State: APjAAAU5jIrVFB51TjEAF1q6G7XvfFQ4JCpiMxrtKq4ft7SGfyhuSQgn nhps+/dAqhcX4iBFGawdy88St2haRXvGE8xeW+GXmeNX X-Google-Smtp-Source: APXvYqwNOiZs8hS/GRJMi+QlAoB8XUg4DbV7w9+Z836IbTGAuPvuOIv8rU8vl7a1xQ0/FMXY4V9OJavrABOrl4rH8Uk= X-Received: by 2002:ac8:2e59:: with SMTP id s25mr5309191qta.94.1562386223871; Fri, 05 Jul 2019 21:10:23 -0700 (PDT) MIME-Version: 1.0 From: Jen Linkova Date: Sat, 6 Jul 2019 14:10:13 +1000 Message-ID: To: V6 Ops List , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] draft-linkova-v6ops-nd-cache-01 submitted X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 04:10:40 -0000 I've submitted -01 version of the draft. Thanks for everyone who responded - I've integrated *some* of the comments but not all - if you do not see you point being addressed it's not because I'm trying to ignore you, it's just because I'd like to submit the improved version before the cut-off date. All remaining comments will be added to -02 version. A new version of I-D, draft-linkova-v6ops-nd-cache-init-01.txt has been successfully submitted by Jen Linkova and posted to the IETF repository. Name: draft-linkova-v6ops-nd-cache-init Revision: 01 Title: Neighbor Cache Entries on First-Hop Routers: Operational Considerations Document date: 2019-07-05 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-linkova-v6ops-nd-cache-init-01.txt Status: https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ Htmlized: https://tools.ietf.org/html/draft-linkova-v6ops-nd-cache-init-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-linkova-v6ops-nd-cache-init Diff: https://www.ietf.org/rfcdiff?url2=draft-linkova-v6ops-nd-cache-init-01 -- SY, Jen Linkova aka Furry From nobody Sat Jul 6 04:00:44 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874511200A1 for ; Sat, 6 Jul 2019 04:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=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=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 yecy9lku74wG for ; Sat, 6 Jul 2019 04:00:39 -0700 (PDT) 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 BB1E312009C for ; Sat, 6 Jul 2019 04:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562410837; x=1563015637; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type; bh=/3xGoiZ8oXJxKen8gXaPLsHKWKubybTm8EKHmUv88w0=; b=qdKTH7C7NKc7ATFW1+MkRcQyj1DqdJpOpZsurSNPMSam8PYfJ/TDX2OdEgzvAk 3W+XiSBlQibUSW8MNHFBuORbcVKBbJogmug/Qq+5mHDg1dbKEyQT6GPd07RVXwo6 mCYyD2MoC3CUcSokO/6CK6nqVsqoclLbEdT/Cm+dtaHto= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 06 Jul 2019 13:00:37 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 06 Jul 2019 13:00:36 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006317396.msg for ; Sat, 06 Jul 2019 13:00:35 +0200 X-MDRemoteIP: 2001:470:1f09:495:b401:3c7c:146d:5899 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Sat, 06 Jul 2019 13:00:35 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=109097686c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Sat, 06 Jul 2019 13:00:35 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <293F8AB3-69DC-4B6E-AF3F-663C33217343@consulintel.es> Thread-Topic: [v6ops] Some comments on draft-palet-v6ops-p2p-links Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3645262835_479327751" Archived-At: Subject: Re: [v6ops] Some comments on draft-palet-v6ops-p2p-links X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 11:00:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3645262835_479327751 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Eric, =20 Thanks a lot for your inputs! =20 Responses below, in-line. =20 If I get new inputs before Monday, I may still be able to update the existi= ng text and have a new version before the cut-off. =20 =20 =20 El 5/7/19 8:35, "v6ops en nombre de Eric Vyncke (evyncke)" escribi=C3=B3: =20 Hello Jordi =20 Just reviewed your I-D and I have some comments. =20 In section 3.2, you talk about the =E2=80=98mitigations=E2=80=99 but it wou= ld be nice to briefly mention the ping-pong attack before. =20 Very good point. I=E2=80=99m going to add specific text at section 3 to rem= ark the section 5.1 from RFC614, as this applies to several of the choices. =20 In section 3.3, do you have data backing the assumption that /112 and /120 = are used on P2P links? =20 Yes, in the survey I=E2=80=99ve been doing for IPv6 deployment (I will add = a reference to it) I got this data: /64 used by 62% of the responders /127 by 7% /126 by 2% /112 by 2% 14% Other choices=20 13% unnumbered =20 BTW, 3.4 is my recommendation in most of the cases ;-) =20 In section 4, s/ different unicast addressing types/ different unicast addr= essing scopes/ ? =20 I=E2=80=99m not sure about this one. In many documents I see it is used =E2= =80=9Ctype=E2=80=9D, but if there is any newer reference that prefers scope= , I=E2=80=99m happy to change that. I see that you used that in RFC7404. =20 I am afraid that I do not understand what is meant in the 2nd and 3rd parag= raph of section 4.3.=20 =20 I mean that RFC7404 already explains that using link-local is possible, and= it has pros and cons, which are detailed there. However, if instead of a r= outer it is a host, some operating systems may not have DHCPv6-PD support, = so the host will only have the link-local address, and thus stay unnumbered= . =20 More description for paragraph 3 of section 6 would also be welcome. =20 Yup, will expand it. I think Mikael raised this issue. =20 Section 6.1, I have also seen ::a and ::b as this also work on /127. Before= that the ::2 has 62 bits of leading zeroes and not 63 ;-) =20 My example is if we use /64. So you mean having also an example for the cas= e where the /64 is reserved but only /127 is used? =20 Section 6.2, you should probably use /64 rather than 2001:db8:aaaa::1/48 =20 No, that=E2=80=99s on purpose (it has been tested). =20 Is there any reason why the last section is only about /64 and no more abou= t /127 ? =20 Got your point, either I do both choices in different sections, or in the s= ame section show one example for /64 and one for /127. =20 You may want to think to remove RFC 6164, 7608 and 7707 from the normative = references as they are more informative imho. =20 Right, willl reorganize them, thanks again! =20 Hope this helps =20 -=C3=A9ric =20 =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. --B_3645262835_479327751 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Eric,

 

Thanks a lot for your inputs!

 

Responses below, in-line.

 

If I get new inputs before Mo= nday, I may still be able to update the existing text and have a new versio= n before the cut-off.

 

<= p class=3DMsoNormal> 

 

El 5/7/19 8:35, "v6ops en= nombre de Eric Vyncke (evyncke)" <v6ops-bounces@ietf.org en nombre de evyncke@cisco.com> escribi=C3=B3:

 

Hello = Jordi

 

Just reviewed your I-D and I have some comments.

 

In section 3.2, you talk about= the =E2=80=98mitigations=E2=80=99 but it would be nice to briefly mention = the ping-pong attack before.

 

Very good point. I= =E2=80=99m going to add specific text at section 3 to remark the section 5.= 1 from RFC614, as this applies to several of the choices.=

 =

In section 3.3, do you have data backing the assumption that /1= 12 and /120 are used on P2P links?

 =

Yes, in the survey= I=E2=80=99ve been doing for IPv6 deployment (I will add a reference to it)= I got this data:

  • /64 used by 62% of the responders
  • /127 by 7%
  • /126 by 2%
  • /112 = by 2%
  • 14% Other choices <= /o:p>
  • 13% unnumbered

 

BTW, 3.4 is my recom= mendation in most of the cases ;-)

 

In section 4, s/ dif= ferent unicast addressing types/ di= fferent unicast addressing scopes/  ?

 

I=E2= =80=99m not sure about this one. In many documents I see it is used =E2=80= =9Ctype=E2=80=9D, but if there is any newer reference that prefers scope, I= =E2=80=99m happy to change that. I see that you used that in RFC7404.<= /o:p>

 <= /o:p>

I am afraid that I do not understand what is meant = in the 2nd and 3rd paragraph of section 4.3.

 

I mean that RFC7404 already explains that using link-l= ocal is possible, and it has pros and cons, which are detailed there. Howev= er, if instead of a router it is a host, some operating systems may not hav= e DHCPv6-PD support, so the host will only have the link-local address, and= thus stay unnumbered.

 

More description = for paragraph 3 of section 6 would also be welcome.

 

Yup, will expand it. I think Mikael raised = this issue.

 

Section 6.1, I have also seen ::a = and ::b as this also work on /127. Before that the ::2 has 62 bits of leadi= ng zeroes and not 63 ;-)

&nb= sp;

My example is if we us= e /64. So you mean having also an example for the case where the /64 is res= erved but only /127 is used?

&nbs= p;

Section 6.2, you = should probably use /64 rather than 2001:db8:aaaa::1/48

 

No, that=E2=80=99s on purpose (it has been tested).

 

Is there any reason why the last section is only about /64 a= nd no more about /127 ?

&nbs= p;

Got your point, either = I do both choices in different sections, or in the same section show one ex= ample for /64 and one for /127.

&= nbsp;

You may want t= o think to remove RFC 6164, 7608 and 7707 from the normative references as = they are more informative imho.

<= o:p> 

Right, willl reorganize t= hem, thanks again!

 <= span lang=3DEN-US>

Hope this helps=

 

-=C3=A9ric

 

 =

_______________________________________________ v6ops mai= ling list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops <= /o:p>


********************************************** 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.

--B_3645262835_479327751-- From nobody Sat Jul 6 09:04:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3E3120047 for ; Sat, 6 Jul 2019 09:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 yfgeA6-eIdpO for ; Sat, 6 Jul 2019 09:04:53 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D51612000F for ; Sat, 6 Jul 2019 09:04:53 -0700 (PDT) Received: from [192.168.1.16] (unknown [41.140.204.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2D9BB84A05; Sat, 6 Jul 2019 18:04:50 +0200 (CEST) References: <156242875288.15242.14064012489544905957.idtracker@ietfa.amsl.com> To: IPv6 Operations From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Cc: Jan Zorz , Richard Patterson X-Forwarded-Message-Id: <156242875288.15242.14064012489544905957.idtracker@ietfa.amsl.com> Message-ID: <47f4c2f5-6ee4-c6bd-9f1b-d7a8a9b08863@si6networks.com> Date: Sat, 6 Jul 2019 17:03:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <156242875288.15242.14064012489544905957.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] SLAAC renum/problems I-D (Fwd: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 16:04:56 -0000 Folks, To make the story short: Based on the discussion we had on draft-gont-6man-slaac-renum, we have posted this new I-D which focuses on discussing the problem, and describing operational mitigations. The document is available at: https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt Comments are welcome. And whenever the chairs deem appropriate, we'd like to know if v6ops would like to work/adopt this document. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt Date: Sat, 06 Jul 2019 08:59:12 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Jan Zorz , Richard Patterson A new version of I-D, draft-gont-v6ops-slaac-renum-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-slaac-renum Revision: 00 Title: Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events Document date: 2019-07-06 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-slaac-renum/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-slaac-renum Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and discusses operational workarounds to improve network robustness. 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 From nobody Sat Jul 6 10:31:28 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E68C120071 for ; Sat, 6 Jul 2019 10:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 L1ph7-nSWnSn for ; Sat, 6 Jul 2019 10:31:23 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 4039B12006A for ; Sat, 6 Jul 2019 10:31:23 -0700 (PDT) Received: from [192.168.1.138] (host-94-248-131-226.kabelnet.hu [94.248.131.226]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x66HVCwc001254 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 6 Jul 2019 19:31:17 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-94-248-131-226.kabelnet.hu [94.248.131.226] claimed to be [192.168.1.138] References: <156243313377.15179.11718999491954856712.idtracker@ietfa.amsl.com> To: v6ops@ietf.org From: =?UTF-8?Q?G=c3=a1bor_LENCSE?= X-Forwarded-Message-Id: <156243313377.15179.11718999491954856712.idtracker@ietfa.amsl.com> Message-ID: <6a756f38-a6b8-011a-9612-f1362a8b7827@hit.bme.hu> Date: Sat, 6 Jul 2019 19:31:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <156243313377.15179.11718999491954856712.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------4A711E4C41B45F373B74A8AE" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=94.248.131.226; helo=[192.168.1.138]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 17:31:27 -0000 This is a multi-part message in MIME format. --------------4A711E4C41B45F373B74A8AE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I have just submitted a new version of our I-D "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" The most important changes are: o The suggestions of Mohamed Boucadair are incorporated. o New considerations regarding possible optimizations. Med, thank you very much for your suggestions in January. Unfortunately, I have lost the XML file which I modified then, thus I tried to reconstruct everything on the basis of the e-mails. I hope that I did not leave out anything. Any comments are welcome! Best regards, Gábor -------- Forwarded Message -------- Subject: New Version Notification for draft-lmhp-v6ops-transition-comparison-03.txt Date: Sat, 06 Jul 2019 10:12:13 -0700 From: internet-drafts@ietf.org To: Lee Howard , Jordi Palet Martinez , Ian Farrer , Jordi Palet , Gabor Lencse , Richard Patterson A new version of I-D, draft-lmhp-v6ops-transition-comparison-03.txt has been successfully submitted by Gabor Lencse and posted to the IETF repository. Name: draft-lmhp-v6ops-transition-comparison Revision: 03 Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS Document date: 2019-07-06 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-03.txt Status: https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ Htmlized: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison Diff: https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison-03 Abstract: Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies considering a number of different aspects to provide network operators with an easy to use reference to assist in selecting the technology that best suits their needs. 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 --------------4A711E4C41B45F373B74A8AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I have just submitted a new version of our I-D "Pros and Cons of IPv6 Transition Technologies for IPv4aaS"

The most important changes are:
   o  The suggestions of Mohamed Boucadair are incorporated.
   o  New considerations regarding possible optimizations.
Med, thank you very much for your suggestions in January. Unfortunately, I have lost the XML file which I modified then, thus I tried to reconstruct everything on the basis of the e-mails. I hope that I did not leave out anything.

Any comments are welcome!

Best regards,

Gábor

-------- Forwarded Message --------
Subject: New Version Notification for draft-lmhp-v6ops-transition-comparison-03.txt
Date: Sat, 06 Jul 2019 10:12:13 -0700
From: internet-drafts@ietf.org
To: Lee Howard <lee@asgard.org>, Jordi Palet Martinez <jordi.palet@theipv6company.com>, Ian Farrer <ian.farrer@telekom.de>, Jordi Palet <jordi.palet@theipv6company.com>, Gabor Lencse <lencse@hit.bme.hu>, Richard Patterson <richard.patterson@sky.uk>



A new version of I-D, draft-lmhp-v6ops-transition-comparison-03.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

Name: draft-lmhp-v6ops-transition-comparison
Revision: 03
Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS
Document date: 2019-07-06
Group: Individual Submission
Pages: 25
URL: https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-03.txt
Status: https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
Htmlized: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-03
Htmlized: https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison
Diff: https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison-03

Abstract:
Several IPv6 transition technologies have been developed to provide
customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
access and/or core network. All these technologies have their
advantages and disadvantages, and depending on existing topology,
skills, strategy and other preferences, one of these technologies may
be the most appropriate solution for a network operator.

This document examines the five most prominent IPv4aaS technologies
considering a number of different aspects to provide network
operators with an easy to use reference to assist in selecting the
technology that best suits their needs.



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

--------------4A711E4C41B45F373B74A8AE-- From nobody Sat Jul 6 12:09:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4719F1200C4 for ; Sat, 6 Jul 2019 12:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 lwJ0_Fp6asSn for ; Sat, 6 Jul 2019 12:09:06 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98E3A120098 for ; Sat, 6 Jul 2019 12:09:06 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id g7so9504613oia.8 for ; Sat, 06 Jul 2019 12:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=DX6jheXaMZD/Nn47kG0IFxsgm7x2AZZuVuTkuxL/WIQ=; b=W/SmpIOCrJWho6rJAhwrjPmf26pjd/MyQNEby1a9eBHNk3ka/irJbuj18v+XuhBINJ 9DWLg4PiCYawdBqptSD8ROqBROu2h8qKuFi5pORK/N5cHaDTPv/4bLLdFI3IlOoDTf0j No0Yaxs44tPL1PJSEifXeUGNoZFAyFWHtBS5CF3B6hNVuoK97/U2c/A9Ch33dXUaZzTg 9tFNaWUBm7LL4qamqC9FKrgwPYiWllIqwB9TW7GvFTKnjuX0T8RkQ1D75HpUkhITc2EO 4HHi9i8DGcxiD4jZjbzIMIYHaNzuWS3ytGdhHlWMbHCwS2ADRWzrrbapS+uQ7YAOs/r1 X55g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=DX6jheXaMZD/Nn47kG0IFxsgm7x2AZZuVuTkuxL/WIQ=; b=EpSt1oC+OuVPpxdsnPjMpSRtjf8n6QnkaMnULAQSyVYg057KXd3dIqNFnBz4OBp9U9 uYDbqfWQjCiLASZ9x2aiL6l99VYOfbJRSLddTojpcXoE3JUip5cc/mH8IjHOIJuwRqUK TEdXXujmQXU5IYRzuH7aNy0iQVKl4I2VfSBBAFcRjy1/EVvklwV2kdppLAKjEmc1+AUS uxeNvF3qBTxV6kmIOFDJCe5YY6IVuI8rcectdR279ZwVPaKv4dFn83wGi18k8k7YaMFu xm63OWoK0gszriTQCj5Hm1Esu39X4NrDQvWKf3NkCl/ovcozcKF1yMkcXXbuc5Q+Ipj/ +4Vw== X-Gm-Message-State: APjAAAWZVms7XGRjdGVTQ/rr8vInuzDqq4EMcUZHgyNlQMxFQWs0hY3d Hmtwpr4E83NT2WWC7fdJjrZaJzs7 X-Google-Smtp-Source: APXvYqyalonNQAEGHc1lLpgun2T/+BI/NRLOpJaPaKMdGnmSZL5vxvhhjHMEp0fLshi9vmAbSWKUoA== X-Received: by 2002:a54:441a:: with SMTP id k26mr2352670oiw.78.1562440145698; Sat, 06 Jul 2019 12:09:05 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1006? ([2600:8802:5903:df16::1006]) by smtp.gmail.com with ESMTPSA id 11sm4433266otc.45.2019.07.06.12.09.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jul 2019 12:09:05 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Sat, 6 Jul 2019 12:09:04 -0700 References: <156243313377.15179.11718999491954856712.idtracker@ietfa.amsl.com> <6a756f38-a6b8-011a-9612-f1362a8b7827@hit.bme.hu> To: IPv6 Operations In-Reply-To: <6a756f38-a6b8-011a-9612-f1362a8b7827@hit.bme.hu> Message-Id: X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-lmhp-v6ops-transition-comparison-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 19:09:10 -0000 As usual, Ron and I are looking for public supportive comment if people = want this on the agenda. > On Jul 6, 2019, at 10:31 AM, G=C3=A1bor LENCSE = wrote: >=20 > Hi, >=20 > I have just submitted a new version of our I-D "Pros and Cons of IPv6 = Transition Technologies for IPv4aaS" >=20 > The most important changes are: > o The suggestions of Mohamed Boucadair are incorporated. > o New considerations regarding possible optimizations. >=20 > Med, thank you very much for your suggestions in January. = Unfortunately, I have lost the XML file which I modified then, thus I = tried to reconstruct everything on the basis of the e-mails. I hope that = I did not leave out anything. >=20 > Any comments are welcome! >=20 > Best regards, >=20 > G=C3=A1bor >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-lmhp-v6ops-transition-comparison-03.txt > Date: Sat, 06 Jul 2019 10:12:13 -0700 > From: internet-drafts@ietf.org > To: Lee Howard , Jordi Palet Martinez = , Ian Farrer , = Jordi Palet , Gabor Lencse = , Richard Patterson >=20 >=20 >=20 > A new version of I-D, draft-lmhp-v6ops-transition-comparison-03.txt > has been successfully submitted by Gabor Lencse and posted to the > IETF repository. >=20 > Name: draft-lmhp-v6ops-transition-comparison > Revision: 03 > Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS > Document date: 2019-07-06 > Group: Individual Submission > Pages: 25 > URL: = https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-compariso= n-03.txt > Status: = https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ > Htmlized: = https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-03 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparis= on > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-lmhp-v6ops-transition-comparison= -03 >=20 > Abstract: > Several IPv6 transition technologies have been developed to provide > customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only > access and/or core network. All these technologies have their > advantages and disadvantages, and depending on existing topology, > skills, strategy and other preferences, one of these technologies may > be the most appropriate solution for a network operator. >=20 > This document examines the five most prominent IPv4aaS technologies > considering a number of different aspects to provide network > operators with an easy to use reference to assist in selecting the > technology that best suits their needs. >=20 >=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 > The IETF Secretariat >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war,=20 Defeated warriors go to war first and then seek to win.=20 Sun Tzu From nobody Sat Jul 6 12:10:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAF91201D8 for ; Sat, 6 Jul 2019 12:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 QbJW4tRRy04D for ; Sat, 6 Jul 2019 12:10:37 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 174A01200FD for ; Sat, 6 Jul 2019 12:10:37 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id z23so12146651ote.13 for ; Sat, 06 Jul 2019 12:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C6rTu/6h2ORivMsnumEL99M5qGJZLO6YLzxBeTPwwWs=; b=AACaplxJwJI/hA7A3xPGtWd7DJ71nBGVsNSg0MPtuFbHvb2fBpMfyfUD0CYOTe+iWf /h+gd3R9nohX0PRZVbewalJ6G5gyn48b2POBjNwgzx+xTMmPPl2Zw78PF4+P5dhnXkSn wLkQY56I0yLoWcSlBL2huw30UcSM3VAj5002JWeUntPgI0B7i+zAR9l4Bli3TMc2UupZ 1hh+xwEAOMzJMoH1VMmoANMAClDJimd73R+yDkPoU81Mm6imx7KOWh0co80Oq6Sei3VS KjU5Gw9MXf/Mxvemwomp5wzCEiP6YzlS7FJIrfdDho37W3GevidhycnwRkVHNVkXz6Ug 6Ryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C6rTu/6h2ORivMsnumEL99M5qGJZLO6YLzxBeTPwwWs=; b=bLlePRpz46nPgiShWW3OHJg96pdxw1Hu//m4Y9gl+X2+ORdl6CLaRqHJ1/J/DkOhCA pB2MtwfUfR2/doftXcFnSueYJU3cqetq7sBHl7i5ACUWxHLQ3aA3D+jNJYyJOt3i013e GGRVmDCB/IzQ8stFPpTqbwJL7OJ8ctvIIi9LtG/oY8T7pwUj0+7buKz7tAbJ4iKApIda 3oZqgifIFKz9t0qoMogBESLxK/t52e6W0pnKs91/akQRbo5g+kg1Dt1dS2mVUAyw0lDc ejz7XfpNOSO6X+7ppP4vu8SwTnNpbUktrGRxe85+TUnaoStkuLMdM8LcbGK6sN1P8liv MCaA== X-Gm-Message-State: APjAAAWMFrJAOiBiE/IenZGormQ8Q5hAVECRj34LMP7Q0+VxNY9haUx6 ZtDHhqX3y0SThoQ6AlcVbdnWwb0T X-Google-Smtp-Source: APXvYqxhUUjSCJsHHV25nPeD/7lijrklXrvMVvPRDLk34zDKKEGYJsEBKQ6ILWDjTNOBby+hRb444Q== X-Received: by 2002:a9d:7c1:: with SMTP id 59mr2058636oto.210.1562440236352; Sat, 06 Jul 2019 12:10:36 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1006? ([2600:8802:5903:df16::1006]) by smtp.gmail.com with ESMTPSA id 9sm4089765oij.25.2019.07.06.12.10.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jul 2019 12:10:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) From: Fred Baker In-Reply-To: <47f4c2f5-6ee4-c6bd-9f1b-d7a8a9b08863@si6networks.com> Date: Sat, 6 Jul 2019 12:10:34 -0700 Cc: Jan Zorz , Richard Patterson , Fernando Gont Content-Transfer-Encoding: quoted-printable Message-Id: References: <156242875288.15242.14064012489544905957.idtracker@ietfa.amsl.com> <47f4c2f5-6ee4-c6bd-9f1b-d7a8a9b08863@si6networks.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [v6ops] SLAAC renum/problems I-D (Fwd: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 19:10:53 -0000 As usual, Ron and I are looking for supportive public commentary if = people want it on the IETF 105 agenda, and if people would like to see = it adopted as a working group draft. > On Jul 6, 2019, at 9:03 AM, Fernando Gont = wrote: >=20 > The document is available at: > = https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt >=20 > Comments are welcome. >=20 > And whenever the chairs deem appropriate, we'd like to know if v6ops > would like to work/adopt this document. = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... From nobody Sat Jul 6 14:32:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF87120113; Sat, 6 Jul 2019 14:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 rtF5-hGglXKw; Sat, 6 Jul 2019 14:31:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EA7120127; Sat, 6 Jul 2019 14:31:46 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id EFD6D38191; Sat, 6 Jul 2019 17:29:45 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2AA4498F; Sat, 6 Jul 2019 17:31:44 -0400 (EDT) From: Michael Richardson To: Jen Linkova cc: V6 Ops List , 6man <6man@ietf.org> In-Reply-To: References: <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> <4250.1562178592@localhost> <7744.1562353657@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] ND cache entries creation on first-hop routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 21:32:01 -0000 --=-=-= Content-Type: text/plain Jen Linkova wrote: >> It has been asserted above that as soon (4) occurs, that it's all good. > No, it's all good if (4) becomes (2.5) and happens *before* (3). So > when the packets arrive the router has the NC entry already - at least > in STALE state. Right, and that's what you are attempting to add. >> I'm skeptical, wondering isn't it (5) that is the key point. > It is. As soon as (4) happens before (3), there is no delay and (5) > does not happen. I'm glad that my understanding of the problem is correct. Back to the question of your solutions, and wondering what things can be done unilaterally, and what actions require coordination to get any effect. > 2.3.1: Host Sending Unsolicited NA. Do any hosts do this already? It seems that this would be a good thing to do unilaterally. This has a small airtime impact, but nothing compared to retransmitting packets, I'd think. Maybe there is a privacy impact if the host sends an Unsolicited NA for a privacy address that it hasn't started using yet. It doesn't help unless routers start acting on them though, but you note that this seems to already be implemented in some platforms. > o Some wireless devices are known to fiddle with ND packets and > perform various non-obvious forms of ND proxy actions. In some > cases unsolicited NAs might not even reach the routers. so it might not work in some situations, and there little handset makers can do. That wifi network will just appear to suck. I would love to have automated, unspammable yelp for wifi networks... > 2.3.2. Host Sending NS to the Router Address from Its GUA This seems to require no innovation (no new code on routers), but can't be done until the address is out of the Optimistic State, so it takes longer. Can this method be *combined* with 2.3.1? > 2.3.3. Host Sending Router Solicitation from its GUA Also no new code on routers, same time restriction as 2.3.2, but reaches all routers. Can this method be combined with 2.3.1? Seems like it is better than 2.3.3 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0hEz8ACgkQgItw+93Q 3WWk2Af/bneLPK1vIzNOOljdGNOvMKeth7behOqC9YdnrdS+lcT2hkNiqLW7r1K8 uc/10NIP9is7j8oD/dD93fYy1GPoJFw2IZbDKnxVZcRA7O3Sg2JrFOGxKzca+qe9 SChyGA6GYakHGs3LX3b/PyN9mwhCJEBAeU4WO5hRTlNCoSAlgZzR32T8JgNshkAR W9fI/BoymtaTrHy2VqBPxACb3rqm9MyCKsYLus45VPztoZTx81Wbnwz/l+YYBqoT jDGtR25/4V/Wl9kMBs+0v4k2aXFtOB+Te8LrqQLGj5tA+Wga0bMbekx7yMECD/Mh xxGDrQ3ot+M+3/zSIAePSDko62c8RA== =bXjV -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 7 05:49:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A430812009C for ; Sun, 7 Jul 2019 05:49:23 -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, SPF_HELO_NONE=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 0iBRZiLPCBIR for ; Sun, 7 Jul 2019 05:49:21 -0700 (PDT) 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 068DF12002E for ; Sun, 7 Jul 2019 05:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562503757; x=1563108557; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=FP2lnB/R JEdg7stK4QAhLjfQXBq8PZc9o+/D3zrl8Cg=; b=Jm7W2sTNpSGWgdKNEIBsU1aL /F/AwZN6lnjpeVbsXs9e+5VHU1VtV1uuBI/aEikG8mS8zklVQOamY6YzsmW7F89C +7j1swEkLuLDkfYYOzyS4JP4+uo8GsaHQzYmBeFBJ223Y9XBYdjXrGLhSnHWQzM+ LyVOUbWYrOqYJK+l2Bs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 07 Jul 2019 14:49:17 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 07 Jul 2019 14:49:16 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006318095.msg for ; Sun, 07 Jul 2019 14:49:15 +0200 X-MDRemoteIP: 2001:470:1f09:495:a535:af53:c0dc:94a0 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Sun, 07 Jul 2019 14:49:15 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10912358bc=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Sun, 07 Jul 2019 14:49:14 +0200 From: JORDI PALET MARTINEZ To: Martin Hunek , Message-ID: <1F70DF2B-C5D6-4D69-9501-FE60194B815C@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt References: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> <1571307.uvGIkSPLC4@rumburak.ite.tul.cz> <13355366.0fiuOKKrGf@rumburak.ite.tul.cz> In-Reply-To: <13355366.0fiuOKKrGf@rumburak.ite.tul.cz> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 12:49:24 -0000 Hi Martin, I've been thinking about this and I think you're right. We should consider = a solution that doesn't break the reverse-proxy cases, even if this means t= hat they aren't optimized. The best approach to me seems to avoid creating an EAMT entry (and thus not= optimizing those cases), in order to avoid breaking anything or creating o= ther delays in case a client already started the communication with an exis= ting EAMT entry and another client is then connecting to another service us= ing the same reverse-proxy. This is the case we have: 1) Client asks for A record of a.example.com. 2) CPE would also ask for AAAA. 3) CPE receives: a.example.com IN A 192.0.2.1 a.example.com IN AAAA 2001:db8::a 4) CPE makes EAMT entry: 192.0.2.1 <-> 2001:db8::a 5) CPE sends A record to client. 6) Client starts to communicate with 2001:db8::a without knowing it. 7) Client (same or another) asks for A record of b.example.com. 8) CPE would also ask for AAAA. 9) CPE receives: b.example.com IN A 192.0.2.1 b.example.com IN AAAA 2001:db8::b 10) CPE does what with EAMT entry? There is already EAMT entry present = for 192.0.2.1! Let's see the options: a) Each time the CPE uses an EAMT (already created) re-check with an A and = AAAA query if it is consistent with the existing EAMT. In the case there is= no match, it means it is a reverse-proxy and the communication is to a dif= ferent server. We could drop the EAMT and create a new one, but then existi= ng communication with previous clients is broken. It may be recovered by th= e application, but this is a recurrent query re-check and will happen every= time in the same network multiple clients use different resources from the= same reverse-proxy. I think is better don't risking for it. b) Add a field in each EAMT entry, with the SNI that has been queried. One = more field to mark that entry as "invalid" (not to be optimized). This is a= lso useful if you want to manually use a GUI in the CPE (or by provisioning= ) to disallow optimization to some destinations. If the CPE receives a query for=20 a.example.com IN A 192.0.2.1 a.example.com IN AAAA 2001:db8::a It creates the EAMT entry and marks it as valid. If afterwards, it gets a query for=20 b.example.com IN A 192.0.2.1 b.example.com IN AAAA 2001:db8::b and the TTL is still fine, but the CPE realizes that the entry A/AAAA/FQDN = (b.example.com 192.0.2.1 2001:db8::b) is conflicting with the existing one = (a.example.com 192.0.2.1 2001:db8::a). The conflict is the existence of the= same IPv4 address for different IPv6 ones with also have different FQDN. I= n other cases, there is no conflict. It means that there is a reverse-proxy= (or equivalent) and the EAMT needs to be invalidated. This allows the optimization only if one or several clients (on this CPE) a= re using a single resource of a specific reverse proxy. But disables optimi= zation if multiple clients in the same CPE are using multiple resources fro= m the same reverse-proxy (if they share the same IPv4 address, but differen= t IPv6 ones). Of course, the EAMT still expires with the TTL, so it allows to re-enable o= ptimization if anything changed. What do you think? Other options? Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 25/6/19 1:46, "v6ops en nombre de Martin Hunek" escribi=C3=B3: Hi Jordi, =20 don worry I'll manage, I wrote that just that you know some clients (km= ail in my case) have issue with this quotation style. :-) =20 Anyway, see reply in-line (shortened to relevant parts). =20 Regards, Martin =20 Dne pond=C4=9Bl=C3=AD 24. =C4=8Dervna 2019 23:39:52 CEST, JORDI PALET M= ARTINEZ napsal(a): > Hi Martin, >=20 > I use Outlook and it doesn't allow (as I know) anything else than ind= entation. I will try to find a solution, I just need some time ... but is n= ot top priority. >=20 > When I see my emails back in the list, it works for me, so it is difi= cult ... >=20 > See below, in-line. >=20 > Regards, > Jordi > @jordipalet > =20 > =20 >=20 > =EF=BB=BFEl 24/6/19 23:14, "v6ops en nombre de Martin Hunek" escribi=C3=B3: > > =EF=BB=BFEl 24/6/19 0:28, "v6ops en nombre de Martin Hunek" escribi=C3=B3: > > How did you solve situation in which multiple IPv6 services= would share single IPv4 to IPv6 proxy? > >=20 > > When you mean a proxy, what do you exactly mean? I'm confused h= ere with your example. Do you refer to SNI ? If that's the case, I believe = it is resolved already, because what it matters here is the IPv6 address (t= he AAAA). > =20 > Sort of. I mean essentially IPv4 web proxy shared by multiple IPv= 6 only servers. Proxy would use SNI to distinguish between target server to= which it would send payload to. Thing is that you won't be able to do conc= urrent bindings in EAMT table for this case. >=20 > -> We need to see if this is really common. My guess is that even if = you use SNI, the IPv4 and the IPv6 page is still hosted by the same dual-st= ack server. In that case, I don't think we have the problem you mention. Yo= u are describing a case where the IPv4 and IPv6 content is hosted by a diff= erent server, not a dual-stack one, right? We really need to check if CDNs/= caches do that. =20 Actually hosted on single (IPv6-only) server, on IPv4 there would be on= ly proxy. By Apache terminology "reverse proxy". For a moment forget CDNs/c= aches, those wouldn't probably need that as they do have different tools ho= w to deal with IPv4 runout. Think more like VPS providers. This is likely t= o happen when operator is running IPv6-only infrastructure. =20 > > Remember that what it matters here is the contents in IPv6, bec= ause the EAMT entry will bring the SmartTV (for example) either to the AAAA= for a.example.com or b.example.com. So, if those AAAA provide the right ad= dress for IPv6, for the right service, it should work correctly. > =20 > No problem on IPv6 side, problem would be to which IPv6 destinati= on should IPv4 destination get mapped to. As in that case you get two bindi= ngs in EAMT: > 192.0.2.1 <-> 2001:db8::a > 192.0.2.1 <-> 2001:db8::b > Both would be valid but which should be chosen by NAT46? > >=20 > > Otherwise (according to your example), you get different result= s for an IPv4 only host and IPv6-only hosts. Normally this is not done in p= roduction services, and again, if this is done, the result of the optimizat= ion is like the IPv4-only SmartTV is actually an IPv6-enabled one, so it wo= rks again, as intended. > =20 > Maybe it is bit "ad absurdum" case, certainly for CDNs. But I thi= nk that it is not discouraged/prohibited and I can see its use for VPS prov= ider which would like to save some IPv4 addresses. By the way, it would be = somehow similar to what you are proposing: get IPv6-only services accessibl= e by IPv4-only hosts. Only tools would be different. >=20 > -> We need to see if this is a real and usual production case. IPv6-o= nly services today can be deployed with SIIT-DC to allow dual-stack access,= but this will not suffer the problem you mention. =20 You are right, but SIIT-DC requires as many IPv4 addresses as IPv4-enab= led services (n:n). It provides stateless translation. I'm talking one IPv4= address for multiple IPv4-services (1:n). > >=20 > > This means (and I think is the *normal* way) to do that, that t= he "server" is dual-stack and is the "apache" (or whatever), using the SNI = the way that resolves the problem. Is that what you mean? > =20 > No. I case I'm trying to present multiple servers would be IPv6-o= nly. And A record would point to web proxy (dual-staked) which would proxy = web requests according to SNI (or request in HTTP) to appropriate IPv6-only= server. Hosting provider would save IPv4 addresses and IPv6-only web serve= r would still be accessible by IPv4. Clearly win-win, except that it would = be broken by this optimization. >=20 > -> Avoiding the EAMT entry will resolve the problem, but will not be = optimized. =20 Yes it would solve that problem, but as it is written right now, you ha= ve no way of knowing that for this specific address EAMT entry should be av= oided. =20 This is how it could get broken and how NAT46 device would be able to d= etect that: 1) Client asks for A record of a.example.com. 2) CPE would also ask for AAAA. 3) CPE receives: a.example.com IN A 192.0.2.1 a.example.com IN AAAA 2001:db8::a 4) CPE makes EAMT entry: 192.0.2.1 <-> 2001:db8::a 5) CPE sends A record to client. 6) Client starts to communicate with 2001:db8::a without knowing it. 7) Client (same or another) asks for A record of b.example.com. 8) CPE would also ask for AAAA. 9) CPE receives: b.example.com IN A 192.0.2.1 b.example.com IN AAAA 2001:db8::b 10) CPE does what with EAMT entry? There is already EAMT entry present = for 192.0.2.1! =20 Option A: CPE would simply update EAMT entry: 10a) EAMT entry gets updated to: 192.0.2.1 <-> 2001:db8::b 11a) CPE sends A record to client. 12a) Client starts communication with 2001:db8::b but connection with 2= 001:db8::a is severed Result: a.example.com is not accessible until its TTL expire. =20 Option B: CPE ignores new EAMT entry: 10b) CPE checks if A record for a.example.com have been changed if yes = than option A, if not than: 11b) EAMT entry stays: 192.0.2.1 <-> 2001:db8::a 12b) CPE sends A record to client. 13b) Client is unable to connect to b.example.com but connection to a.e= xample.com is not interrupted. Result: b.example.com is not accessible until TTL of a.example.com expi= re. =20 Option C: CPE excludes 192.0.2.1 from EAMT: 10c) CPE checks if A record for a.example.com have been changed if yes = than option A, if not than: 11c) EAMT entry of 192.0.2.1 <-> 2001:db8::a gets deleted: 12c) CPE sends A record to client. 13c) Client is able to connect to b.example.com but connection to a.exa= mple.com is momentary interrupted. Result: Session made to a.example.com via IPv6 is severed and had to be= reinitiated, but both are accessible. =20 Option D: CPE handles additional entries for 192.0.2.1 as it would not = have A record: 10d) CPE checks if A record for a.example.com have been changed if yes = than option A, if not than: 11d) CPE generates pseudo IPv4 address 198.51.100.1 for 2001:db8::b 12d) CPE makes EAMT entry: 198.51.100.1 <-> 2001:db8::b 13d) CPE send 198.51.100.1 to client. 14d) Client communicate with 2001:db8::b, communication with 2001:db8::= a is not interrupted. Result: If client is validating DNSSEC, then validation would fail. Sam= e way as if service would be IPv6-only as A query would end up with NSEC(3)= with NODATA response. If client attempts validation b.example.com would no= t be accessible. =20 > =20 > Just so we would be on same page, connections to such deployment = would look like this: > a) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4= ---> Proxy <--- IPv6 ---> IPv6 Server > b) IPv6 Client <--- IPv6 ---> IPv6 Server > =20 > You are proposing: > c) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> IPv6 Server > We can probably all agree that "b" is best and "c" is better than= "a". Problem is that you have no way of knowing if you are talking to actu= al server or just proxy. > =20 > Another example when this optimization would not work exactly as = planted would be case in which service provider deployed IPv6 by NAT64 plac= ed before its IPv4-only infrastructure. But in this case I would say that s= uch operator would deserve higher load on its NAT64. :-) > This would be case: > d) IPv6 Client <--- IPv6 ---> NAT64 <--- IPv4 ---> IPv4 Server > Optimization would result in: > e) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4= ---> IPv4 Server > But in this case NAT64 would be in the servers' network rather th= an clients'. This is actually good as it is transferring load from network = doing IPv6 right to network doing it wrong. :-) >=20 > -> I think d) is using "only" NAT64, but it is a broken model, becaus= e it doesn't work for IPv4-only hosts behind the CPE. So not in scope for o= ur document. e) is the "normal" case for 464XLAT when we don't have the opt= imization described in this document. =20 Never mind d) and e), this is not important as this would not be actual= ly broken. Difference is between transporting IPv4 or IPv6 packets over int= ernet. IPv4 without optimization, IPv6 with. >=20 > >=20 > > Possible solution: > > Maybe this could be solved by some kind of "blacklist for s= hared IPv4 addresses with different IPv6 target" thing. This situation shou= ld be detectable if there would be EAMT record already present with differe= nt IPv6 address. Then if CPE would ask for DNS record which created EAMT re= cord and DNS record has not changed it should delete EAMT and blacklist tha= t IPv4 address so it would not make more EAMT records for it. > >=20 > > Right now, we have this in the ID: > > TBD. Should a way to manually exclude EAMT entries be consider= ed? > > May be a manual config in the CPE and by means of operator c= onfig. > > This is way-out to ensure nothing is broken by surprise and = is not > > solvable. > >=20 > > May be what you mention help to be able to also do it automated= . > =20 > Doing it manually would not quite cut it as you are proposing to = done optimization on CPE and as it may be under customer control, you may n= ot be able to provision it with updated EAMT excludes. It had to be somehow= automated as it would be hard to instruct customer to modify EAMT by hand. >=20 > -> Agree that manually only makes sense if there is a strange case or= the user for some reason doesn't want optimization. It is a special case 9= 9% of users will not use it, but must be supported. > =20 > However there is also trade-off with automated approach as it wou= ld have to either severe session for user which is already using present bi= nding (when conflicting binding appears). As user starts to communicate ove= r IPv4 (from servers' perspective) as it would get excluded from EAMT. Or y= ou would have to forge fake IPv4 for conflicting binding and corresponding = A record, which would break DNSSEC. >=20 > -> I can't parse the complete paragraph ... =20 See Option C and Option D above. Thing is that you had to choose betwee= n terminating current connection by deleting EAMT entry or making fake addr= ess for new connections. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Sun Jul 7 05:53:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE611200B5 for ; Sun, 7 Jul 2019 05:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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 Arj0Au4YtA8Z for ; Sun, 7 Jul 2019 05:53:40 -0700 (PDT) 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 D200F12002E for ; Sun, 7 Jul 2019 05:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562504018; x=1563108818; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=JuJEsxT5 +JRbpH7wtgsODetIo4cAV5NF/Pnq09E2UhU=; b=PVn90Z4SqsJGZC1YLD9aIo1B a9X8sOQcKksqSyalBFqD81+ikDV2SBsQUwrYmEqs7/efkfUcvbeBvpwXyqd0RRoh IOkuYbQ5aVky5l4Z8Gb9K3TxrecfUsERDz7UvHRol0/3WJsOn2rPpmFy5MdZlwYV wb49jwlmghr/mJREhQE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 07 Jul 2019 14:53:38 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 07 Jul 2019 14:53:37 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006318103.msg for ; Sun, 07 Jul 2019 14:53:35 +0200 X-MDRemoteIP: 2001:470:1f09:495:a535:af53:c0dc:94a0 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Sun, 07 Jul 2019 14:53:35 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10912358bc=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Sun, 07 Jul 2019 14:53:30 +0200 From: JORDI PALET MARTINEZ To: Martin Hunek , Message-ID: <3C6E058D-4DD1-4D0C-A0E8-3948AF88E54A@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt References: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> <1571307.uvGIkSPLC4@rumburak.ite.tul.cz> In-Reply-To: <13355366.0fiuOKKrGf@rumburak.ite.tul.cz> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 12:53:43 -0000 Disregard the previous one, small but important type to understand the opti= on b correctly. =EF=BB=BFHi Martin, I've been thinking about this and I think you're right. We should consider = a solution that doesn't break the reverse-proxy cases, even if this means t= hat they aren't optimized. The best approach to me seems to avoid creating an EAMT entry (and thus not= optimizing those cases), in order to avoid breaking anything or creating o= ther delays in case a client already started the communication with an exis= ting EAMT entry and another client is then connecting to another service us= ing the same reverse-proxy. This is the case we have: 1) Client asks for A record of a.example.com. 2) CPE would also ask for AAAA. 3) CPE receives: a.example.com IN A 192.0.2.1 a.example.com IN AAAA 2001:db8::a 4) CPE makes EAMT entry: 192.0.2.1 <-> 2001:db8::a 5) CPE sends A record to client. 6) Client starts to communicate with 2001:db8::a without knowing it. 7) Client (same or another) asks for A record of b.example.com. 8) CPE would also ask for AAAA. 9) CPE receives: b.example.com IN A 192.0.2.1 b.example.com IN AAAA 2001:db8::b 10) CPE does what with EAMT entry? There is already EAMT entry present = for 192.0.2.1! Let's see the options: a) Each time the CPE uses an EAMT (already created) re-check with an A and = AAAA query if it is consistent with the existing EAMT. In the case there is= no match, it means it is a reverse-proxy and the communication is to a dif= ferent server. We could drop the EAMT and create a new one, but then existi= ng communication with previous clients is broken. It may be recovered by th= e application, but this is a recurrent query re-check and will happen every= time in the same network multiple clients use different resources from the= same reverse-proxy. I think is better don't risking for it. b) Add a field in each EAMT entry, with the FQDN that has been queried. One= more field to mark that entry as "invalid" (not to be optimized). This is = also useful if you want to manually use a GUI in the CPE (or by provisionin= g) to disallow optimization to some destinations. If the CPE receives a query for=20 a.example.com IN A 192.0.2.1 a.example.com IN AAAA 2001:db8::a It creates the EAMT entry and marks it as valid. If afterwards, it gets a query for=20 b.example.com IN A 192.0.2.1 b.example.com IN AAAA 2001:db8::b and the TTL is still fine, but the CPE realizes that the entry to be create= d A/AAAA/FQDN (b.example.com 192.0.2.1 2001:db8::b) is conflicting with the= existing one (a.example.com 192.0.2.1 2001:db8::a). The conflict is the ex= istence of the same IPv4 address for different IPv6 ones with also have dif= ferent FQDN. In other cases, there is no conflict. It means that there is a= reverse-proxy (or equivalent) and the EAMT needs to be invalidated, so no = more optimization will be performed for that IPv4 address. This allows the optimization only if one or several clients (on this CPE) a= re using a single resource of a specific reverse proxy. But disables optimi= zation if multiple clients in the same CPE are using multiple resources fro= m the same reverse-proxy (if they share the same IPv4 address, but differen= t IPv6 ones). Of course, the EAMT still expires with the TTL, so it allows to re-enable o= ptimization if anything changed. What do you think? Other options? Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 25/6/19 1:46, "v6ops en nombre de Martin Hunek" escribi=C3=B3: Hi Jordi, =20 don worry I'll manage, I wrote that just that you know some clients (km= ail in my case) have issue with this quotation style. :-) =20 Anyway, see reply in-line (shortened to relevant parts). =20 Regards, Martin =20 Dne pond=C4=9Bl=C3=AD 24. =C4=8Dervna 2019 23:39:52 CEST, JORDI PALET M= ARTINEZ napsal(a): > Hi Martin, >=20 > I use Outlook and it doesn't allow (as I know) anything else than ind= entation. I will try to find a solution, I just need some time ... but is n= ot top priority. >=20 > When I see my emails back in the list, it works for me, so it is difi= cult ... >=20 > See below, in-line. >=20 > Regards, > Jordi > @jordipalet > =20 > =20 >=20 > =EF=BB=BFEl 24/6/19 23:14, "v6ops en nombre de Martin Hunek" escribi=C3=B3: > > =EF=BB=BFEl 24/6/19 0:28, "v6ops en nombre de Martin Hunek" escribi=C3=B3: > > How did you solve situation in which multiple IPv6 services= would share single IPv4 to IPv6 proxy? > >=20 > > When you mean a proxy, what do you exactly mean? I'm confused h= ere with your example. Do you refer to SNI ? If that's the case, I believe = it is resolved already, because what it matters here is the IPv6 address (t= he AAAA). > =20 > Sort of. I mean essentially IPv4 web proxy shared by multiple IPv= 6 only servers. Proxy would use SNI to distinguish between target server to= which it would send payload to. Thing is that you won't be able to do conc= urrent bindings in EAMT table for this case. >=20 > -> We need to see if this is really common. My guess is that even if = you use SNI, the IPv4 and the IPv6 page is still hosted by the same dual-st= ack server. In that case, I don't think we have the problem you mention. Yo= u are describing a case where the IPv4 and IPv6 content is hosted by a diff= erent server, not a dual-stack one, right? We really need to check if CDNs/= caches do that. =20 Actually hosted on single (IPv6-only) server, on IPv4 there would be on= ly proxy. By Apache terminology "reverse proxy". For a moment forget CDNs/c= aches, those wouldn't probably need that as they do have different tools ho= w to deal with IPv4 runout. Think more like VPS providers. This is likely t= o happen when operator is running IPv6-only infrastructure. =20 > > Remember that what it matters here is the contents in IPv6, bec= ause the EAMT entry will bring the SmartTV (for example) either to the AAAA= for a.example.com or b.example.com. So, if those AAAA provide the right ad= dress for IPv6, for the right service, it should work correctly. > =20 > No problem on IPv6 side, problem would be to which IPv6 destinati= on should IPv4 destination get mapped to. As in that case you get two bindi= ngs in EAMT: > 192.0.2.1 <-> 2001:db8::a > 192.0.2.1 <-> 2001:db8::b > Both would be valid but which should be chosen by NAT46? > >=20 > > Otherwise (according to your example), you get different result= s for an IPv4 only host and IPv6-only hosts. Normally this is not done in p= roduction services, and again, if this is done, the result of the optimizat= ion is like the IPv4-only SmartTV is actually an IPv6-enabled one, so it wo= rks again, as intended. > =20 > Maybe it is bit "ad absurdum" case, certainly for CDNs. But I thi= nk that it is not discouraged/prohibited and I can see its use for VPS prov= ider which would like to save some IPv4 addresses. By the way, it would be = somehow similar to what you are proposing: get IPv6-only services accessibl= e by IPv4-only hosts. Only tools would be different. >=20 > -> We need to see if this is a real and usual production case. IPv6-o= nly services today can be deployed with SIIT-DC to allow dual-stack access,= but this will not suffer the problem you mention. =20 You are right, but SIIT-DC requires as many IPv4 addresses as IPv4-enab= led services (n:n). It provides stateless translation. I'm talking one IPv4= address for multiple IPv4-services (1:n). > >=20 > > This means (and I think is the *normal* way) to do that, that t= he "server" is dual-stack and is the "apache" (or whatever), using the SNI = the way that resolves the problem. Is that what you mean? > =20 > No. I case I'm trying to present multiple servers would be IPv6-o= nly. And A record would point to web proxy (dual-staked) which would proxy = web requests according to SNI (or request in HTTP) to appropriate IPv6-only= server. Hosting provider would save IPv4 addresses and IPv6-only web serve= r would still be accessible by IPv4. Clearly win-win, except that it would = be broken by this optimization. >=20 > -> Avoiding the EAMT entry will resolve the problem, but will not be = optimized. =20 Yes it would solve that problem, but as it is written right now, you ha= ve no way of knowing that for this specific address EAMT entry should be av= oided. =20 This is how it could get broken and how NAT46 device would be able to d= etect that: 1) Client asks for A record of a.example.com. 2) CPE would also ask for AAAA. 3) CPE receives: a.example.com IN A 192.0.2.1 a.example.com IN AAAA 2001:db8::a 4) CPE makes EAMT entry: 192.0.2.1 <-> 2001:db8::a 5) CPE sends A record to client. 6) Client starts to communicate with 2001:db8::a without knowing it. 7) Client (same or another) asks for A record of b.example.com. 8) CPE would also ask for AAAA. 9) CPE receives: b.example.com IN A 192.0.2.1 b.example.com IN AAAA 2001:db8::b 10) CPE does what with EAMT entry? There is already EAMT entry present = for 192.0.2.1! =20 Option A: CPE would simply update EAMT entry: 10a) EAMT entry gets updated to: 192.0.2.1 <-> 2001:db8::b 11a) CPE sends A record to client. 12a) Client starts communication with 2001:db8::b but connection with 2= 001:db8::a is severed Result: a.example.com is not accessible until its TTL expire. =20 Option B: CPE ignores new EAMT entry: 10b) CPE checks if A record for a.example.com have been changed if yes = than option A, if not than: 11b) EAMT entry stays: 192.0.2.1 <-> 2001:db8::a 12b) CPE sends A record to client. 13b) Client is unable to connect to b.example.com but connection to a.e= xample.com is not interrupted. Result: b.example.com is not accessible until TTL of a.example.com expi= re. =20 Option C: CPE excludes 192.0.2.1 from EAMT: 10c) CPE checks if A record for a.example.com have been changed if yes = than option A, if not than: 11c) EAMT entry of 192.0.2.1 <-> 2001:db8::a gets deleted: 12c) CPE sends A record to client. 13c) Client is able to connect to b.example.com but connection to a.exa= mple.com is momentary interrupted. Result: Session made to a.example.com via IPv6 is severed and had to be= reinitiated, but both are accessible. =20 Option D: CPE handles additional entries for 192.0.2.1 as it would not = have A record: 10d) CPE checks if A record for a.example.com have been changed if yes = than option A, if not than: 11d) CPE generates pseudo IPv4 address 198.51.100.1 for 2001:db8::b 12d) CPE makes EAMT entry: 198.51.100.1 <-> 2001:db8::b 13d) CPE send 198.51.100.1 to client. 14d) Client communicate with 2001:db8::b, communication with 2001:db8::= a is not interrupted. Result: If client is validating DNSSEC, then validation would fail. Sam= e way as if service would be IPv6-only as A query would end up with NSEC(3)= with NODATA response. If client attempts validation b.example.com would no= t be accessible. =20 > =20 > Just so we would be on same page, connections to such deployment = would look like this: > a) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4= ---> Proxy <--- IPv6 ---> IPv6 Server > b) IPv6 Client <--- IPv6 ---> IPv6 Server > =20 > You are proposing: > c) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> IPv6 Server > We can probably all agree that "b" is best and "c" is better than= "a". Problem is that you have no way of knowing if you are talking to actu= al server or just proxy. > =20 > Another example when this optimization would not work exactly as = planted would be case in which service provider deployed IPv6 by NAT64 plac= ed before its IPv4-only infrastructure. But in this case I would say that s= uch operator would deserve higher load on its NAT64. :-) > This would be case: > d) IPv6 Client <--- IPv6 ---> NAT64 <--- IPv4 ---> IPv4 Server > Optimization would result in: > e) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4= ---> IPv4 Server > But in this case NAT64 would be in the servers' network rather th= an clients'. This is actually good as it is transferring load from network = doing IPv6 right to network doing it wrong. :-) >=20 > -> I think d) is using "only" NAT64, but it is a broken model, becaus= e it doesn't work for IPv4-only hosts behind the CPE. So not in scope for o= ur document. e) is the "normal" case for 464XLAT when we don't have the opt= imization described in this document. =20 Never mind d) and e), this is not important as this would not be actual= ly broken. Difference is between transporting IPv4 or IPv6 packets over int= ernet. IPv4 without optimization, IPv6 with. >=20 > >=20 > > Possible solution: > > Maybe this could be solved by some kind of "blacklist for s= hared IPv4 addresses with different IPv6 target" thing. This situation shou= ld be detectable if there would be EAMT record already present with differe= nt IPv6 address. Then if CPE would ask for DNS record which created EAMT re= cord and DNS record has not changed it should delete EAMT and blacklist tha= t IPv4 address so it would not make more EAMT records for it. > >=20 > > Right now, we have this in the ID: > > TBD. Should a way to manually exclude EAMT entries be consider= ed? > > May be a manual config in the CPE and by means of operator c= onfig. > > This is way-out to ensure nothing is broken by surprise and = is not > > solvable. > >=20 > > May be what you mention help to be able to also do it automated= . > =20 > Doing it manually would not quite cut it as you are proposing to = done optimization on CPE and as it may be under customer control, you may n= ot be able to provision it with updated EAMT excludes. It had to be somehow= automated as it would be hard to instruct customer to modify EAMT by hand. >=20 > -> Agree that manually only makes sense if there is a strange case or= the user for some reason doesn't want optimization. It is a special case 9= 9% of users will not use it, but must be supported. > =20 > However there is also trade-off with automated approach as it wou= ld have to either severe session for user which is already using present bi= nding (when conflicting binding appears). As user starts to communicate ove= r IPv4 (from servers' perspective) as it would get excluded from EAMT. Or y= ou would have to forge fake IPv4 for conflicting binding and corresponding = A record, which would break DNSSEC. >=20 > -> I can't parse the complete paragraph ... =20 See Option C and Option D above. Thing is that you had to choose betwee= n terminating current connection by deleting EAMT entry or making fake addr= ess for new connections. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Sun Jul 7 05:58:21 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0512002E; Sun, 7 Jul 2019 05:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson , v6ops-chairs@ietf.org, swmike@swm.pp.se, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com> Date: Sun, 07 Jul 2019 05:58:13 -0700 Archived-At: Subject: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-nat64-deployment-06=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 12:58:14 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello Jordi, Thank you for the work put into this clear and well-written document. I only wonder whether section 3 and section 4 should be swapped for a more logical flow: explain the issues, then describe working solutions. Probably too late in the publication to change though. The underlying message of "464XLAT solves everything" is annoying but I must admit that this is true ;-) Please find below many COMMENTs in the hope of improving the readability and factual data points in the document. -éric == COMMENTS == Is there a description of the use of DNS64 in the host as it fixes the DNSSEC issues ? (except in section 3.2.2.) -- Section 3.1 -- "known to work": can you add references or data backing this statement ? -- Section 3.1.1 -- When discussing scenarii, please refer to the figure ID in the text for clarity. -- Section 3.1.2 -- It is unclear to me whether "The support of this scenario" refers to the UE-only or the CPE deployment. Same demand as above: please refer to the figure ID in the text for clarity. -- Sectio 3.2.1 -- I really wonder whether it is useful to describe this scenario as 'working under special conditions'... those 'special conditions' will probably never met in real life. More generally, I am unsure about the value of the whole section 3.2 (it is more like an academic thing). -- Section 4.1.1. -- Can you add reference and/or data for "monitored by some governmental bodies and other institutions". Please add a reference for the use of "ipv4only.arpa". AFAIK draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead. -- Section 4.1.2 -- The leading paragraph is a little confusing as it assumed that CLAT exists (stated in the text but not in the section title). -- Section 4.1.5 -- The section title is rather misleading "ACL of clients" and I wonder why a dual-stack client would use a DNS64 server as its recursive DNS server. Isn't it an obvious configuration mistake? -- Section 4.4.1 -- Some explanations of the consequences of a foreign DNS would be welcome. -- Section 4.4.2 -- Rather than using "DNS privacy" please use "DNS request confidentiality" as the DNS64 will learn/glean about the client activities. -- Section 4.6 -- Please explain why older API is a problem (or rather rephrase it into applications using IPv4-only API). -- Section 4.10 -- draft-ietf-tram-turnbis is also able to support IPv6-only client. It is currently in the same IESG status as this document. -- Section 5 -- Please add data/references for "with hundreds of millions of users" -- Section 7 -- Not so much about security but about privacy. I would appreciate to have some text around the lack of privacy when using an external DNS64 as this server will learn about all clients activities. == NITS == Generally, please refrain from using "HEv2" in place of "Happy Eyeball version 2". -- Section 3.1.1. -- Figure 1 shows a box containing both NAT64 and DNS64 while those functions could reside in different devices. s/One more equivalent scenario/One additional equivalent scenario/ ? -- Section 4.1 -- s/to an IPv6-only WAN/to an IPv6-only access network/ From nobody Sun Jul 7 14:25:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594D5120219; Sun, 7 Jul 2019 14:24:35 -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, SPF_HELO_NONE=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 HvQJcL0J_lxr; Sun, 7 Jul 2019 14:24:31 -0700 (PDT) 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 AAE481201F8; Sun, 7 Jul 2019 14:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562534666; x=1563139466; 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=XpCAKzXt9E81k7dsXJDKGbbhdzZZis1YvQUDpo2KhDY=; b=mT0/UBQ1JVaPB rX+dVPBCS5MaueDwasylepcphbsy1ayHQPSHBex5P94rZFy9Zh3OmrZos/Z3WFli Zoev3le65ZwdcrwmRxF/wB2oEQVYonDWH1bzhZFciMe4VInbNzhvgMIqkUhf5aSb Jv124SvHGyDHCpXvk+jqGsipUKtlE0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 07 Jul 2019 23:24:26 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 07 Jul 2019 23:24:25 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006318371.msg; Sun, 07 Jul 2019 23:24:23 +0200 X-MDRemoteIP: 2001:470:1f09:495:f45a:6729:ba13:4125 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Sun, 07 Jul 2019 23:24:23 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10912358bc=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Sun, 07 Jul 2019 23:24:21 +0200 From: JORDI PALET MARTINEZ To: =?UTF-8?B?w4lyaWM=?= Vyncke , The IESG CC: , , Message-ID: <75A5EB61-3879-4F83-83BB-D65EE8799AF3@consulintel.es> Thread-Topic: [v6ops] =?UTF-8?B?w4lyaWM=?= Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT) References: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com> In-Reply-To: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-nat64-deployment-06=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 21:24:52 -0000 Hi Eric, Thanks a lot for your review! Comments in-line below. Most of them I will reword some text or correct nit= s, but there are a couple of questions for you to clarify. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 7/7/19 14:59, "v6ops en nombre de =C3=89ric Vyncke via Datatrac= ker" escribi=C3=B3: =C3=89ric Vyncke has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-06: No Objection =20 When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) =20 =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 Hello Jordi, =20 Thank you for the work put into this clear and well-written document. =20 I only wonder whether section 3 and section 4 should be swapped for a m= ore logical flow: explain the issues, then describe working solutions. Prob= ably too late in the publication to change though. I think that will be a major change, because I've a lot of references to th= e "possible" deployment scenarios to explain the different issues. My "flow= " was thinking in how you can deploy it, and then what are the issues that = you need to consider. =20 The underlying message of "464XLAT solves everything" is annoying but I= must admit that this is true ;-) This document started as 464XLAT deployment guidelines, and the WG asked me= to turn it also to "NAT64". I think that explains it, but in any case, as = you well say, it is true ... and there is explicit text to indicate that if= you're sure that everything inside the network is supporting IPv6, no lite= rals, etc., then it may be fine with just NAT64. However we all know that t= his is a non-realistic scenario. =20 Please find below many COMMENTs in the hope of improving the readabilit= y and factual data points in the document. =20 -=C3=A9ric =20 =3D=3D COMMENTS =3D=3D =20 Is there a description of the use of DNS64 in the host as it fixes the = DNSSEC issues ? (except in section 3.2.2.) Not sure to completely understand what you mean here, just trying ... This = is not something that the service provider can solve, as it is up to the OS= (for all the devices in that network). That's why I think is not something= for this document. However, I just realized that this is described in sect= ion 7.2 of RFC6147. I can add a reference to that in section 3.2.2. =20 -- Section 3.1 -- =20 "known to work": can you add references or data backing this statement = ? Well, those are the models being used today in cellular and broadband netwo= rks. So I can just say that? =20 -- Section 3.1.1 -- =20 When discussing scenarii, please refer to the figure ID in the text for= clarity. Done (I'm already editing a new version while writing this, pending on some= that you can provide to my comments). =20 -- Section 3.1.2 -- =20 It is unclear to me whether "The support of this scenario" refers to th= e UE-only or the CPE deployment. It is referring to the "service provider network support". Will clarify it. =20 Same demand as above: please refer to the figure ID in the text for cla= rity. Done! =20 -- Sectio 3.2.1 -- =20 I really wonder whether it is useful to describe this scenario as 'work= ing under special conditions'... those 'special conditions' will probably n= ever met in real life. =20 More generally, I am unsure about the value of the whole section 3.2 (i= t is more like an academic thing). I think some of those scenarios are possible in some networks, may be not c= onnecting to Internet, or for example, you may want to configure explicit m= appings, which can be done with EAM. I just realized that I've not cited th= at. I will do. =20 -- Section 4.1.1. -- =20 Can you add reference and/or data for "monitored by some governmental b= odies and other institutions". I believe that was pointed out by somebody in the WG, but it is true that s= ome regulators do that. I recall having seen something about that in France= , but I'm not 100% sure right now. =20 Please add a reference for the use of "ipv4only.arpa". AFAIK Right, this is defined by RFC7050, done! draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead. This is one of the issues that I've commented with Warren, responding to IA= NA. I understand he is sponsoring that document.=20 =20 -- Section 4.1.2 -- =20 The leading paragraph is a little confusing as it assumed that CLAT exi= sts (stated in the text but not in the section title). Will clarify it. =20 -- Section 4.1.5 -- =20 The section title is rather misleading "ACL of clients" and I wonder wh= y a dual-stack client would use a DNS64 server as its recursive DNS server.= Isn't it an obvious configuration mistake? No, I think that text is correct, but I will try to reword it to make it cl= earer. You may have a situation with IPv4-only servers, which are located, = in the path between the dual-stack hosts and the NAT64. So, if the DNS64 is= not configured to exclude those servers, it will synthetize the AAAA recor= ds and they will become unreachable. So that's why bind and other DNS64 ser= vers provide this ACL function. =20 -- Section 4.4.1 -- =20 Some explanations of the consequences of a foreign DNS would be welcome= . Done! =20 -- Section 4.4.2 -- =20 Rather than using "DNS privacy" please use "DNS request confidentiality= " as the DNS64 will learn/glean about the client activities. I used this terminology as it was suggested as the common one for the diffe= rent protocols in this category. I will try to confirm if is the right one = just in case. May be rewording the title as "DNS Privacy/Encryption Mechani= sms" ? =20 -- Section 4.6 -- =20 Please explain why older API is a problem (or rather rephrase it into applications using IPv4-only API). Done! =20 -- Section 4.10 -- =20 draft-ietf-tram-turnbis is also able to support IPv6-only client. It is currently in the same IESG status as this document. Definitively, will add a reference to it! =20 -- Section 5 -- =20 Please add data/references for "with hundreds of millions of users" I can cite several cellular networks, but I will do in a generic way, I don= 't think we should mention explicit providers, right?.=20 =20 -- Section 7 -- =20 Not so much about security but about privacy. I would appreciate to hav= e some text around the lack of privacy when using an external DNS64 as this se= rver will learn about all clients activities. Good point, thanks. Will do! =20 =3D=3D NITS =3D=3D =20 Generally, please refrain from using "HEv2" in place of "Happy Eyeball = version 2". Done! =20 -- Section 3.1.1. -- =20 Figure 1 shows a box containing both NAT64 and DNS64 while those functi= ons could reside in different devices. Will clarify it. =20 s/One more equivalent scenario/One additional equivalent scenario/ ? Done! =20 -- Section 4.1 -- =20 s/to an IPv6-only WAN/to an IPv6-only access network/ =20 Done! =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Sun Jul 7 23:45:55 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B876E1200FB; Sun, 7 Jul 2019 23:45:45 -0700 (PDT) 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, 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 header.b=YxizwZ6s; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YM2/y/dp 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 LCgf0aUUvkV9; Sun, 7 Jul 2019 23:45:43 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8C8120099; Sun, 7 Jul 2019 23:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9858; q=dns/txt; s=iport; t=1562568342; x=1563777942; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JO9LEyqYqxKaAS+kJg9uE6gn6Cgj2q8Des22NdJXThw=; b=YxizwZ6saiNP1p5Y0u9SfFdZGj6Ng4BOlfIjRV26fPvol+5PfvBpcZud 7/wZY1L5yBHwnAfFLFdzHEVoo8/SHN7uu7ooU/2f6/dLxLR+cFBNFU5b7 cFKAiZhCPAoiuLBgyZzedBKAGVWLaGv8HHzbez1AK/R9AOTowFdfr8zV0 A=; IronPort-PHdr: =?us-ascii?q?9a23=3A1ACSJBCQzz2dhbLmKLT/UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIeD7aSc5EexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAAC35SJd/4YNJK1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYFDUANqVSAECyiEHINHA4RSiXaCNpdrgS4UgRADVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGEQAIXghwjNAkOAQMBAQQBAQIBBW2KNwyFSwIEAQEQERE?= =?us-ascii?q?MAQEsCwEPAgEIGgImAgICJQsVBQsCBAENBRkJgwABgWoDHQECDJtuAoE4iGB?= =?us-ascii?q?xgTKCeQEBBYEyAYNIGIISCYEMKAGKQIEeF4FAPyZrJwwTgkw+gmEBAYElJi2?= =?us-ascii?q?CczKCJot5CAFLgiOFIIhEjRVtCQKCF4ZWgUGJOoIzG4IsbYY0BY4sgyWKC5c?= =?us-ascii?q?9AgQCBAUCDgEBBYFQOIFYcBUaISoBgkEJgjg3gWqBUIUUhT9ygSmNRgsBAQ?= X-IronPort-AV: E=Sophos;i="5.63,465,1557187200"; d="scan'208";a="301448402" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2019 06:45:41 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x686jf7P014186 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2019 06:45:41 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 01:45:40 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 01:45:40 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Jul 2019 02:45:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JO9LEyqYqxKaAS+kJg9uE6gn6Cgj2q8Des22NdJXThw=; b=YM2/y/dpR88lBJNEqXd5xmOzyZZ0bcRJz0ehJUQZ1qakDABDtHqM9V39VV51QLv8ukTXLR0KQQo3eDpu0UNw1Fp9tcC9FvxHJD6sGQyys6OFEOGAYRc7Rf5FwAjZPak+cf2AIKv7zC7tPFGrpCfkNHspg8YeyKtMrRtIPZauE5g= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4368.namprd11.prod.outlook.com (52.135.36.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 06:11:56 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474%6]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 06:11:56 +0000 From: "Eric Vyncke (evyncke)" To: JORDI PALET MARTINEZ , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: =?utf-8?B?W3Y2b3BzXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-v6ops-nat64-deployment-06:_(with_COMMENT)?= Thread-Index: AQHVNQx+J0S3s5dcFUGOU27vUA5fYabAX4IA Date: Mon, 8 Jul 2019 06:11:56 +0000 Message-ID: References: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com> <75A5EB61-3879-4F83-83BB-D65EE8799AF3@consulintel.es> In-Reply-To: <75A5EB61-3879-4F83-83BB-D65EE8799AF3@consulintel.es> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c0:1008::f4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 668c7d73-8e0d-4e83-ba89-08d7036b2e13 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4368; x-ms-traffictypediagnostic: MN2PR11MB4368: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(376002)(396003)(366004)(199004)(189003)(51444003)(6246003)(966005)(6436002)(25786009)(478600001)(53936002)(6306002)(6512007)(53386004)(14454004)(2906002)(256004)(5024004)(6116002)(229853002)(6486002)(14444005)(316002)(110136005)(58126008)(54906003)(36756003)(4326008)(33656002)(486006)(446003)(11346002)(73956011)(2616005)(476003)(64756008)(66476007)(6506007)(102836004)(7736002)(224303003)(66946007)(66446008)(76116006)(305945005)(8936002)(66574012)(91956017)(76176011)(46003)(66556008)(186003)(5660300002)(86362001)(81166006)(81156014)(71200400001)(71190400001)(68736007)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4368; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rkpyvk0h6OaidI3/fKzO+tRO13RAK/hyA1yVzu04cVnf/UBd/WFZU4nqMD7I3FLbH9cU5W30ZTxmP0n7eYr3CTflOJYOZcVHzn+QMBNAbKMlyUdBY5oC4I6HSceMf10oL6iJKd5OjA8TkJTa+8hInlNRUDfd2r261L596ms8wkp5dYb/4oWsP2oIsXg6vAogZzuHbLqt86mbZcyw3u38ra7X7rTYSQh52kP5tfZCMTBbL4SsyUL7WqfyzVYncsGab2ML330ssVF5Dj564775+CfuVfZAFbtCCErrrlPhQ0oPuxS1kpAQhaiBnD6lWQ0w3IrztM984op7MfEsaJafGLfAK5P2V/ZXq6H//YqhsDwbarQoIqKzBigw4mCVq53uZgBzO0KVuF5wxURvIBCGEErmIzUQn71PyKcC7yV98EY= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 668c7d73-8e0d-4e83-ba89-08d7036b2e13 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 06:11:56.3034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4368 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-nat64-deployment-06=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 06:45:46 -0000 SG9sYSBKb3JkaSwNCg0KQSBjb3VwbGUgb2YgbXkgY29tbWVudHMgd2VyZSBhYm91dCBsYWNraW5n IG9mIHJlZmVyZW5jZXMgZm9yICJrbm93biB0byB3b3JrIiBvciAibW9uaXRvcmVkIGJ5IHNvbWUg Z292ZXJubWVudGFsIGJvZGllcyBhbmQgb3RoZXIgaW5zdGl0dXRpb25zIiBvciAiIndpdGggaHVu ZHJlZHMgb2YgbWlsbGlvbnMgb2YgdXNlcnMiIHdoaWNoIGFyZSBzdHJvbmcgc3RhdGVtZW50cyB3 aXRob3V0IGFueSBmYWN0dWFsIGRhdGEgYmVoaW5kIHRoZW0uIEkgbWFrZSBtZSBmZWVsIHVuY29t Zm9ydGFibGUuLi4gdGhlIGRvY3VtZW50IHdvdWxkIGJlIG11Y2ggc3Ryb25nZXIgaWYgdGhlcmUg d2VyZSByZWZlcmVuY2VzIChleHRlcm5hbCBwYXBlcnMgYXJlIGZpbmUpLg0KDQpZb3VyIGV4cGxh bmF0aW9ucyBmb3IgIkFDTCBvZiBjbGllbnRzIiBhcmUgY2xlYXIgbm93LiBJIHN1Z2dlc3QgdGhh dCB5b3UgcmV3cml0ZSB0aGUgc2VjdGlvbiB0byBhZGQgdGhlIGV4YW1wbGUgZ2l2ZW4gaW4geW91 ciByZXBseS4gQW5kLCB1c2UgYSBkaWZmZXJlbnQgbmFtZSB0byB0aGUgc2VjdGlvbiA7LSkNCg0K VGhhbmsgeW91IGZvciBhbGwgdGhlIGZpeGVzIGFuZCBmb3IgYXV0aG9yaW5nIHRoZSBkb2N1bWVu dA0KDQotw6lyaWMNCg0K77u/T24gMDcvMDcvMjAxOSwgMjM6MzksICJKT1JESSBQQUxFVCBNQVJU SU5FWiIgPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPiB3cm90ZToNCg0KICAgICAgICAtLSBT ZWN0aW9uIDMuMSAtLQ0KICAgICAgICANCiAgICAgICAgImtub3duIHRvIHdvcmsiOiBjYW4geW91 IGFkZCByZWZlcmVuY2VzIG9yIGRhdGEgYmFja2luZyB0aGlzIHN0YXRlbWVudCA/DQogICAgDQog ICAgV2VsbCwgdGhvc2UgYXJlIHRoZSBtb2RlbHMgYmVpbmcgdXNlZCB0b2RheSBpbiBjZWxsdWxh ciBhbmQgYnJvYWRiYW5kIG5ldHdvcmtzLiBTbyBJIGNhbiBqdXN0IHNheSB0aGF0Pw0KICAgICAg ICANCiAgICAgICAgLS0gU2VjdGlvbiAzLjEuMSAtLQ0KICAgICAgICANCiAgICAgICAgV2hlbiBk aXNjdXNzaW5nIHNjZW5hcmlpLCBwbGVhc2UgcmVmZXIgdG8gdGhlIGZpZ3VyZSBJRCBpbiB0aGUg dGV4dCBmb3IgY2xhcml0eS4NCiAgICANCiAgICBEb25lIChJJ20gYWxyZWFkeSBlZGl0aW5nIGEg bmV3IHZlcnNpb24gd2hpbGUgd3JpdGluZyB0aGlzLCBwZW5kaW5nIG9uIHNvbWUgdGhhdCB5b3Ug Y2FuIHByb3ZpZGUgdG8gbXkgY29tbWVudHMpLg0KICAgICAgICANCiAgICAgICAgLS0gU2VjdGlv biAzLjEuMiAtLQ0KICAgICAgICANCiAgICAgICAgSXQgaXMgdW5jbGVhciB0byBtZSB3aGV0aGVy ICJUaGUgc3VwcG9ydCBvZiB0aGlzIHNjZW5hcmlvIiByZWZlcnMgdG8gdGhlDQogICAgICAgIFVF LW9ubHkgb3IgdGhlIENQRSBkZXBsb3ltZW50Lg0KICAgIA0KICAgIEl0IGlzIHJlZmVycmluZyB0 byB0aGUgInNlcnZpY2UgcHJvdmlkZXIgbmV0d29yayBzdXBwb3J0Ii4gV2lsbCBjbGFyaWZ5IGl0 Lg0KICAgICAgICANCiAgICAgICAgU2FtZSBkZW1hbmQgYXMgYWJvdmU6IHBsZWFzZSByZWZlciB0 byB0aGUgZmlndXJlIElEIGluIHRoZSB0ZXh0IGZvciBjbGFyaXR5Lg0KICAgIA0KICAgIERvbmUh DQogICAgICAgIA0KICAgICAgICAtLSBTZWN0aW8gMy4yLjEgLS0NCiAgICAgICAgDQogICAgICAg IEkgcmVhbGx5IHdvbmRlciB3aGV0aGVyIGl0IGlzIHVzZWZ1bCB0byBkZXNjcmliZSB0aGlzIHNj ZW5hcmlvIGFzICd3b3JraW5nDQogICAgICAgIHVuZGVyIHNwZWNpYWwgY29uZGl0aW9ucycuLi4g dGhvc2UgJ3NwZWNpYWwgY29uZGl0aW9ucycgd2lsbCBwcm9iYWJseSBuZXZlciBtZXQNCiAgICAg ICAgaW4gcmVhbCBsaWZlLg0KICAgICAgICANCiAgICAgICAgTW9yZSBnZW5lcmFsbHksIEkgYW0g dW5zdXJlIGFib3V0IHRoZSB2YWx1ZSBvZiB0aGUgd2hvbGUgc2VjdGlvbiAzLjIgKGl0IGlzDQog ICAgICAgIG1vcmUgbGlrZSBhbiBhY2FkZW1pYyB0aGluZykuDQogICAgDQogICAgSSB0aGluayBz b21lIG9mIHRob3NlIHNjZW5hcmlvcyBhcmUgcG9zc2libGUgaW4gc29tZSBuZXR3b3JrcywgbWF5 IGJlIG5vdCBjb25uZWN0aW5nIHRvIEludGVybmV0LCBvciBmb3IgZXhhbXBsZSwgeW91IG1heSB3 YW50IHRvIGNvbmZpZ3VyZSBleHBsaWNpdCBtYXBwaW5ncywgd2hpY2ggY2FuIGJlIGRvbmUgd2l0 aCBFQU0uIEkganVzdCByZWFsaXplZCB0aGF0IEkndmUgbm90IGNpdGVkIHRoYXQuIEkgd2lsbCBk by4NCiAgICAgICAgDQogICAgICAgIC0tIFNlY3Rpb24gNC4xLjEuIC0tDQogICAgICAgIA0KICAg ICAgICBDYW4geW91IGFkZCByZWZlcmVuY2UgYW5kL29yIGRhdGEgZm9yICJtb25pdG9yZWQgYnkg c29tZSBnb3Zlcm5tZW50YWwgYm9kaWVzDQogICAgICAgIGFuZCBvdGhlciBpbnN0aXR1dGlvbnMi Lg0KICAgIA0KICAgIEkgYmVsaWV2ZSB0aGF0IHdhcyBwb2ludGVkIG91dCBieSBzb21lYm9keSBp biB0aGUgV0csIGJ1dCBpdCBpcyB0cnVlIHRoYXQgc29tZSByZWd1bGF0b3JzIGRvIHRoYXQuIEkg cmVjYWxsIGhhdmluZyBzZWVuIHNvbWV0aGluZyBhYm91dCB0aGF0IGluIEZyYW5jZSwgYnV0IEkn bSBub3QgMTAwJSBzdXJlIHJpZ2h0IG5vdy4NCiAgICAgICAgDQogICAgICAgIFBsZWFzZSBhZGQg YSByZWZlcmVuY2UgZm9yIHRoZSB1c2Ugb2YgImlwdjRvbmx5LmFycGEiLiBBRkFJSw0KICAgIA0K ICAgIFJpZ2h0LCB0aGlzIGlzIGRlZmluZWQgYnkgUkZDNzA1MCwgZG9uZSENCiAgICANCiAgICAg ICAgZHJhZnQtY2hlc2hpcmUtc3Vkbi1pcHY0b25seS1kb3QtYXJwYSBhcHBlYXJzIHRvIGJlIGRv cm1hbnQvZGVhZC4NCiAgICANCiAgICBUaGlzIGlzIG9uZSBvZiB0aGUgaXNzdWVzIHRoYXQgSSd2 ZSBjb21tZW50ZWQgd2l0aCBXYXJyZW4sIHJlc3BvbmRpbmcgdG8gSUFOQS4gSSB1bmRlcnN0YW5k IGhlIGlzIHNwb25zb3JpbmcgdGhhdCBkb2N1bWVudC4gDQogICAgDQogICAgICAgIA0KICAgICAg ICAtLSBTZWN0aW9uIDQuMS4yIC0tDQogICAgICAgIA0KICAgICAgICBUaGUgbGVhZGluZyBwYXJh Z3JhcGggaXMgYSBsaXR0bGUgY29uZnVzaW5nIGFzIGl0IGFzc3VtZWQgdGhhdCBDTEFUIGV4aXN0 cw0KICAgICAgICAoc3RhdGVkIGluIHRoZSB0ZXh0IGJ1dCBub3QgaW4gdGhlIHNlY3Rpb24gdGl0 bGUpLg0KICAgIA0KICAgIFdpbGwgY2xhcmlmeSBpdC4NCiAgICAgICAgDQogICAgICAgIC0tIFNl Y3Rpb24gNC4xLjUgLS0NCiAgICAgICAgDQogICAgICAgIFRoZSBzZWN0aW9uIHRpdGxlIGlzIHJh dGhlciBtaXNsZWFkaW5nICJBQ0wgb2YgY2xpZW50cyIgYW5kIEkgd29uZGVyIHdoeSBhDQogICAg ICAgIGR1YWwtc3RhY2sgY2xpZW50IHdvdWxkIHVzZSBhIEROUzY0IHNlcnZlciBhcyBpdHMgcmVj dXJzaXZlIEROUyBzZXJ2ZXIuIElzbid0DQogICAgICAgIGl0IGFuIG9idmlvdXMgY29uZmlndXJh dGlvbiBtaXN0YWtlPw0KICAgIA0KICAgIE5vLCBJIHRoaW5rIHRoYXQgdGV4dCBpcyBjb3JyZWN0 LCBidXQgSSB3aWxsIHRyeSB0byByZXdvcmQgaXQgdG8gbWFrZSBpdCBjbGVhcmVyLiBZb3UgbWF5 IGhhdmUgYSBzaXR1YXRpb24gd2l0aCBJUHY0LW9ubHkgc2VydmVycywgd2hpY2ggYXJlIGxvY2F0 ZWQsIGluIHRoZSBwYXRoIGJldHdlZW4gdGhlIGR1YWwtc3RhY2sgaG9zdHMgYW5kIHRoZSBOQVQ2 NC4gU28sIGlmIHRoZSBETlM2NCBpcyBub3QgY29uZmlndXJlZCB0byBleGNsdWRlIHRob3NlIHNl cnZlcnMsIGl0IHdpbGwgc3ludGhldGl6ZSB0aGUgQUFBQSByZWNvcmRzIGFuZCB0aGV5IHdpbGwg YmVjb21lIHVucmVhY2hhYmxlLiBTbyB0aGF0J3Mgd2h5IGJpbmQgYW5kIG90aGVyIEROUzY0IHNl cnZlcnMgcHJvdmlkZSB0aGlzIEFDTCBmdW5jdGlvbi4NCiAgICAgICAgDQogICAgICAgIC0tIFNl Y3Rpb24gNC40LjEgLS0NCiAgICAgICAgDQogICAgICAgIFNvbWUgZXhwbGFuYXRpb25zIG9mIHRo ZSBjb25zZXF1ZW5jZXMgb2YgYSBmb3JlaWduIEROUyB3b3VsZCBiZSB3ZWxjb21lLg0KICAgIA0K ICAgIERvbmUhDQogICAgICAgIA0KICAgICAgICAtLSBTZWN0aW9uIDQuNC4yIC0tDQogICAgICAg IA0KICAgICAgICBSYXRoZXIgdGhhbiB1c2luZyAiRE5TIHByaXZhY3kiIHBsZWFzZSB1c2UgIkRO UyByZXF1ZXN0IGNvbmZpZGVudGlhbGl0eSIgYXMgdGhlDQogICAgICAgIEROUzY0IHdpbGwgbGVh cm4vZ2xlYW4gYWJvdXQgdGhlIGNsaWVudCBhY3Rpdml0aWVzLg0KICAgIA0KICAgIEkgdXNlZCB0 aGlzIHRlcm1pbm9sb2d5IGFzIGl0IHdhcyBzdWdnZXN0ZWQgYXMgdGhlIGNvbW1vbiBvbmUgZm9y IHRoZSBkaWZmZXJlbnQgcHJvdG9jb2xzIGluIHRoaXMgY2F0ZWdvcnkuIEkgd2lsbCB0cnkgdG8g Y29uZmlybSBpZiBpcyB0aGUgcmlnaHQgb25lIGp1c3QgaW4gY2FzZS4gTWF5IGJlIHJld29yZGlu ZyB0aGUgdGl0bGUgYXMgIkROUyBQcml2YWN5L0VuY3J5cHRpb24gTWVjaGFuaXNtcyIgPw0KICAg IA0KICAgIA0KICAgICAgICANCiAgICAgICAgLS0gU2VjdGlvbiA0LjYgLS0NCiAgICAgICAgDQog ICAgICAgIFBsZWFzZSBleHBsYWluIHdoeSBvbGRlciBBUEkgaXMgYSBwcm9ibGVtIChvciByYXRo ZXIgcmVwaHJhc2UgaXQgaW50bw0KICAgICAgICBhcHBsaWNhdGlvbnMgdXNpbmcgSVB2NC1vbmx5 IEFQSSkuDQogICAgDQogICAgRG9uZSENCiAgICAgICAgDQogICAgICAgIC0tIFNlY3Rpb24gNC4x MCAtLQ0KICAgICAgICANCiAgICAgICAgZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMgaXMgYWxzbyBh YmxlIHRvIHN1cHBvcnQgSVB2Ni1vbmx5IGNsaWVudC4gSXQgaXMNCiAgICAgICAgY3VycmVudGx5 IGluIHRoZSBzYW1lIElFU0cgc3RhdHVzIGFzIHRoaXMgZG9jdW1lbnQuDQogICAgDQogICAgRGVm aW5pdGl2ZWx5LCB3aWxsIGFkZCBhIHJlZmVyZW5jZSB0byBpdCENCiAgICAgICAgDQogICAgICAg IC0tIFNlY3Rpb24gNSAtLQ0KICAgICAgICANCiAgICAgICAgUGxlYXNlIGFkZCBkYXRhL3JlZmVy ZW5jZXMgZm9yICJ3aXRoIGh1bmRyZWRzIG9mIG1pbGxpb25zIG9mIHVzZXJzIg0KICAgIA0KICAg IEkgY2FuIGNpdGUgc2V2ZXJhbCBjZWxsdWxhciBuZXR3b3JrcywgYnV0IEkgd2lsbCBkbyBpbiBh IGdlbmVyaWMgd2F5LCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBtZW50aW9uIGV4cGxpY2l0IHBy b3ZpZGVycywgcmlnaHQ/LiANCiAgICAgICAgDQogICAgICAgIC0tIFNlY3Rpb24gNyAtLQ0KICAg ICAgICANCiAgICAgICAgTm90IHNvIG11Y2ggYWJvdXQgc2VjdXJpdHkgYnV0IGFib3V0IHByaXZh Y3kuIEkgd291bGQgYXBwcmVjaWF0ZSB0byBoYXZlIHNvbWUNCiAgICAgICAgdGV4dCBhcm91bmQg dGhlIGxhY2sgb2YgcHJpdmFjeSB3aGVuIHVzaW5nIGFuIGV4dGVybmFsIEROUzY0IGFzIHRoaXMg c2VydmVyDQogICAgICAgIHdpbGwgbGVhcm4gYWJvdXQgYWxsIGNsaWVudHMgYWN0aXZpdGllcy4N CiAgICANCiAgICBHb29kIHBvaW50LCB0aGFua3MuIFdpbGwgZG8hDQogICAgICAgIA0KICAgICAg ICA9PSBOSVRTID09DQogICAgICAgIA0KICAgICAgICBHZW5lcmFsbHksIHBsZWFzZSByZWZyYWlu IGZyb20gdXNpbmcgIkhFdjIiIGluIHBsYWNlIG9mICJIYXBweSBFeWViYWxsIHZlcnNpb24NCiAg ICAgICAgMiIuDQogICAgDQogICAgRG9uZSENCiAgICAgICAgDQogICAgICAgIC0tIFNlY3Rpb24g My4xLjEuIC0tDQogICAgICAgIA0KICAgICAgICBGaWd1cmUgMSBzaG93cyBhIGJveCBjb250YWlu aW5nIGJvdGggTkFUNjQgYW5kIEROUzY0IHdoaWxlIHRob3NlIGZ1bmN0aW9ucw0KICAgICAgICBj b3VsZCByZXNpZGUgaW4gZGlmZmVyZW50IGRldmljZXMuDQogICAgDQogICAgV2lsbCBjbGFyaWZ5 IGl0Lg0KICAgICAgICANCiAgICAgICAgcy9PbmUgbW9yZSBlcXVpdmFsZW50IHNjZW5hcmlvL09u ZSBhZGRpdGlvbmFsIGVxdWl2YWxlbnQgc2NlbmFyaW8vID8NCiAgICANCiAgICBEb25lIQ0KICAg ICAgICANCiAgICAgICAgLS0gU2VjdGlvbiA0LjEgLS0NCiAgICAgICAgDQogICAgICAgIHMvdG8g YW4gSVB2Ni1vbmx5IFdBTi90byBhbiBJUHY2LW9ubHkgYWNjZXNzIG5ldHdvcmsvDQogICAgICAg IA0KICAgIERvbmUhICAgIA0KICAgIA0KICAgIA0KICAgICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QN CiAgICAgICAgdjZvcHNAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wcw0KICAgICAgICANCiAgICANCiAgICANCiAgICANCiAgICAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgSVB2NCBpcyBv dmVyDQogICAgQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQogICAgaHR0cDov L3d3dy50aGVpcHY2Y29tcGFueS5jb20NCiAgICBUaGUgSVB2NiBDb21wYW55DQogICAgDQogICAg VGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJl IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQg dG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFi b3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29w eWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1h dGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5z ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFu eSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50 cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFj aGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBj cmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVy IHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCiAgICAN CiAgICANCiAgICANCiAgICANCg0K From nobody Mon Jul 8 05:41:29 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0A120168; Mon, 8 Jul 2019 05:41:27 -0700 (PDT) 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, 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 header.b=R98F2Wl+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rnzp/tzG 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 pcElIzPoiq-C; Mon, 8 Jul 2019 05:41:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0B212010D; Mon, 8 Jul 2019 05:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6360; q=dns/txt; s=iport; t=1562589684; x=1563799284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sgKn3x8UN4Rwd+B/o7bYeOu975NZp3se9y3U7mDyZDQ=; b=R98F2Wl+bX8bbZf7XFljZmEqj3Xt8d6/J6cM/lFMxeVVTmuywo2ceT74 EBRT0d7J2g4vm0W9BcIDu/Dz/XIx2sWzl7ivJx7x9tDdKLZPhVxapbXOl cew1whOS4UBcY1aDxEsqLnjpM1mBSowMZRTKxBXYG7R6TuO1e7CcSiqiS g=; IronPort-PHdr: =?us-ascii?q?9a23=3AYWmwUBw/CjwDt73XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAADHOCNd/5hdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGBQ1ADalUgBAsoCoQSg0cDjkiCW36WSIEugSQ?= =?us-ascii?q?DVAkBAQEMAQEjCgIBAYRAAheCICM1CA4BAwEBBAEBAgEFbYo3DIVKAQEBAwE?= =?us-ascii?q?SEREMAQErDAEECwIBCBoCJgICAjAVEAEBBA4NGoMBgWoDDg8BAgyeUgKBOIh?= =?us-ascii?q?gcYEygnkBAQWBRkGCdBiCEgMGgQwoAYRxhm0XgUA/gRFGgU5JBy4+gQSBXQE?= =?us-ascii?q?BAgEBgUcYgwgygiaLehiCXocok1FtCQKCF4ZWhGyIXYIslVKOYIYQj30CBAI?= =?us-ascii?q?EBQIOAQEFgVIBNYFYcBWDJ4JBg3GFFIU/cgEBgSeMLgGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,466,1557187200"; d="scan'208";a="504308830" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2019 12:41:22 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x68CfNaC032023 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2019 12:41:23 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 07:41:22 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 08:41:21 -0400 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Jul 2019 08:41:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sgKn3x8UN4Rwd+B/o7bYeOu975NZp3se9y3U7mDyZDQ=; b=rnzp/tzGsymyI0Y3tEn4u9zRX8YXglwVSTcj6h4QO/OnRxRTaGAUpSpe+YI8dAoSp2H8whUSyrA50rsPOkfb1sXypZDKfZwq+2mfaL+nUjDL6BYyHBqTDg0RSG41PUzFlj7Gcocq4e3Sg0FFGTl2cL1+7bBVbj+0ckl1S3p7GKw= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4141.namprd11.prod.outlook.com (20.179.150.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Mon, 8 Jul 2019 12:41:20 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 12:41:20 +0000 From: "Pascal Thubert (pthubert)" To: Mark Smith CC: Carsten Bormann , Michael Richardson , V6 Ops List , 6man <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs Thread-Index: AdUyXLsjbUS9G1zfTQuzwoWpAiUtYQACLMYAAAC/GgAATi6UAAB5DMJQ Date: Mon, 8 Jul 2019 12:41:04 +0000 Deferred-Delivery: Mon, 8 Jul 2019 12:40:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 69fe8431-8dfe-4214-9f99-08d703a193f4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4141; x-ms-traffictypediagnostic: MN2PR11MB4141: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(346002)(376002)(199004)(189003)(51444003)(229853002)(52536014)(14444005)(256004)(5024004)(53936002)(74316002)(99286004)(66066001)(6436002)(8676002)(3846002)(6116002)(9686003)(6306002)(55016002)(305945005)(8936002)(66446008)(7736002)(73956011)(66556008)(64756008)(81156014)(81166006)(102836004)(76176011)(5660300002)(66476007)(76116006)(66946007)(6506007)(7696005)(6916009)(2906002)(486006)(54906003)(68736007)(478600001)(476003)(26005)(4326008)(446003)(86362001)(186003)(11346002)(316002)(6246003)(25786009)(33656002)(966005)(66574012)(71190400001)(71200400001)(14454004)(1411001)(6666004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4141; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lYoid3a3uHmBWTVnRQm9Qf632/AlB+UrATXJCxZ+zozw07ccaL9sRnCykHaXNFq+5QXTKGASwCfFWXKhbu22mwXwVKq6InOKfaNAJFp4H1RxVGIDhTxB1Q9RuLEHL27g6gTfu4I2Ugd+GtFBH42Ld2uzJJSQLedILXsIEinxVrp6AWqSVIwK7ct6wOeM2cmBXgDceCh7dglUVVwtGRVIwN6jecanvLXiKgD7rkI1s3TVmDStQVucErlS6HdOkoIwBKtggdmnbDROZE+xLR5O+kM83ehJCXGsKBSBRSkdvBecVT8rDVCjIAFrBUhqltPPxs/JbEh/x7gbb8u38HLNpv0f3n8hHPSjq0HTcmEsq+R4WSvxsICfwOXoHPLcXf0eNImATVnTI4TnkMQu8yNN5NDL5qILtnz609H7UR6te4w= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 69fe8431-8dfe-4214-9f99-08d703a193f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 12:41:20.1565 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4141 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 12:41:28 -0000 SGVsbG8gTWFyazoNCg0KPiA+IEEgc2Vuc2Ugb2YgbGlmZXRpbWU7IGhvdyBsb25nIHNob3VsZCB0 aGUgcm91dGVyL0wzQVAgZXhwZWN0IHRoYXQgdGhlDQo+IGFkZHJlc3Mgd2lsbCBiZSB1c2VkOyBh dCB0aW1lIG91dCwgdGhlIHJvdXRlciBjYW4gY2xlYW4gdXAgdGhlIHN0YXRlLg0KPiANCj4gQWxy ZWFkeSBiZWluZyBwZXJmb3JtZWQgYnkgTlVEIHJpZ2h0IG5vdy4NCj4gDQo+IE5VRCBhdm9pZHMg dGhlIHBvc3NpYmlsaXR5IG9mIHRoZSByb3V0ZXIncyB2aWV3IG9mIHdoZW4gYW4gYWRkcmVzcyBl eHBpcmVzDQo+IGdldHRpbmcgb3V0IG9mIHN5bmMgd2l0aCB3aGVuIHRoZSBhZGRyZXNzIGRvZXMg b3IgaGFzIGV4cGlyZWQgb24gYSBob3N0Lg0KDQpOVUQgaXMgc3RpbGwgaW1wb3J0YW50IGluIFJG QyA2Nzc1Lzg1MDUuIFRoZSBsaWZldGltZSBvZiBhIHJlZ2lzdHJhdGlvbiBoYXMgYWRkaXRpb25h bCB2YWx1ZS4gSXQgaXMgYSBuZWdvdGlhdGVkIGNvbnRyYWN0IHRoYXQgdGhlIHJvdXRlciB3aWxs IG1haW50YWluIGFuZCBwb3NzaWJseSBkZWZlbmQgLyByZS1hZHZlcnRpc2UgdGhlIHN0YXRlIGR1 cmluZyB0aGF0IHBlcmlvZC4gSXQgY2FuIGJlIHZlcnkgc2hvcnQgZm9yIHNob3J0LWxpdmVkIGFk ZHJlc3MgKGUuZy4sIG9uZSB3YWtlIHRpbWUgb2YgeW91ciB0YWJsZXQpIGFuZCB2ZXJ5IGxvbmcg Zm9yIGFuIGV4aXQgc2lnbi4gTlVEIGRlZmF1bHRzIHNob3cgbGltaXRzIHRoZXJlLg0KDQo+IA0K PiA+IEEgc2Vuc2Ugb2Ygb3JkZXI7IGlmIGEgd2lyZWxlc3Mgbm9kZSBtb3ZlcyByYXBpZGx5IGZy b20gYSBMM0FQIHRvIHRoZQ0KPiA+IG5leHQsIG9yIGEgVk0gbW92ZXMgcmFwaWRseSBmcm9tIGEg c2VydmVyIHRvIHRoZSBuZXh0LCB3aGljaCBpcyB0aGUNCj4gPiBtb3N0IHJlY2VudCBwb2ludCBv ZiBhdHRhY2htZW50DQo+IA0KPiBXaGF0IHNvcnQgb2YgZGV2aWNlIGlzIGEgIkwzQVAiPyBJbiBS RkMgODIwMCB3ZSBkb24ndCBoYXZlIHRoYXQgc29ydCBvZiBkZXZpY2UNCj4gZGVmaW5lZCwgd2Ug anVzdCBoYXZlIGxpbmtzLCBob3N0cywgcm91dGVycyBhbmQgbm9kZXMgKElQdjYgaG9zdCBvciBy b3V0ZXIpLg0KDQpMaWtlIGEgTDMtc3dpdGNoIGJ1dCB3aXJlbGVzcy4gQW4gQVAgaXMgYSBicmlk Z2UgdGhhdCBpcyBwcm9hY3RpdmVseSBwcm9ncmFtbWVkIG9uIHRoZSB3aXJlbGVzcyBzaWRlIHdp dGggdGhlIGFzc29jaWF0aW9uIHByb2Nlc3MsIGFzIG9wcG9zZWQgdG8gYSBsZWFybmluZyAodHJh bnNwYXJlbnQpIGJyaWRnZSB0aGF0IHJlcXVpcmVzIHRoZSBicm9hZGNhc3QuIFJGQyA2Nzc1IC8g ODUwNSBpcyB0aGUgc2FtZSB0aGluZyBhdCBMMy4gSWYgeW91IGFkZCBMMyBmZWF0dXJlcyBsaWtl IGFuIFNWSSB0byB0aGUgQVAsIGFuZCBMMyBmdW5jdGlvbnMgaW4gdGhlcmUgbGlrZSBSRkM4NTA1 LCByb3V0aW5nLCBhbmQvb3IgTkQgcHJveHksIHRoZW4geW91IGhhdmUgYW4gTDMtQVAuDQoNCj4g SSdtIGd1ZXNzaW5nIGl0IGlzIGEgY29tYmluZWQgbGF5ZXIgMi9sYXllciAzIGRldmljZSB3aXRo IHRpZ2h0IGludGVncmF0aW9uDQo+IGJldHdlZW4gbGF5ZXIgMiBhbmQgbGF5ZXIgMyBwcm9jZXNz aW5nPyBJZiBpdCBpcywgd2Ugd291bGRuJ3Qgd2FudCB0byBjcmVhdGUgYQ0KPiByZXF1aXJlbWVu dCB0aGF0IGFsbCBsYXllciAyIGRldmljZXMgYXJlIGFsc28gbGF5ZXIgMyByb3V0ZXJzIGZvciBh bGwgSVB2Ng0KPiBuZXR3b3Jrcy4NCg0KVGhlcmUgc2hvdWxkIGJlIG9uZSBzdWNoIHRoaW5nIG9u IHRoZSBwYXRoLCB3ZSB1c3VhbGx5IHBsYWNlIGl0IGF0IHRoZSBlZGdlLCBkZXZpY2UgZmFjaW5n LCBha2EgQm9yZGVyIE5vZGVzLiBUaGVyZSBhcmUgcm9sZXMgdG8gYmUgcGxheWVkIGF0IGluZ3Jl c3MsIGxpa2UgdGhlIHJlZ2lzdHJhdGlvbiwgTkQgc25vb3BpbmcsIGFuZCBvdmVybGF5IGVuY2Fw c3VsYXRpb24uIE90aGVycyBhdCBlZ3Jlc3MgbGlrZSBtdWx0aWNhc3Qgc3VwcHJlc3Npb24uDQoN Cj4gDQo+ID4gQSBzZW5zZSBvZiBvd25lcnNoaXA7IGlmIHRoZSByb3V0ZXIgbWFpbnRhaW5zIGEg c3RhdGUgYWJvdXQgdGhlDQo+ID4gYWRkcmVzcyBmb3IgYSByZXF1ZXN0ZWQgbGlmZXRpbWUsIHRo ZW4gYSBwcm9vZiBvZiBvd25lcnNoaXAgY2FuIGJlDQo+ID4gYXR0YWNoZWQsIHNvIG9ubHkgdGhl IG93bmVyIG9mIHRoZSBhZGRyZXNzIGNhbiBtb2RpZnkgdGhlIHN0YXRlIChTQVZJKQ0KPiANCj4g SSB0aGluayB0aGF0IGNhbiBiZSBhY2hpZXZlZCB1c2luZyB1c2luZyB0aGUgc3RhdGUgdGhhdCBO VUQgbWFpbnRhaW5zIGFuZCBpcw0KPiBhbHJlYWR5IG9jY3VycmluZy4gRm9yIGV4YW1wbGUsIGFu IHVuc29saWNpdGVkIE5BIGNhbiBiZSBzZW50IHRvIHVwZGF0ZQ0KPiByZW1vdGUgZGV2aWNlcycg bmVpZ2hib3IgY2FjaGUgZW50cnkgZm9yIHRoZSBhZGRyZXNzIHdpdGggYSBuZXcgbGluay1sYXll cg0KPiBhZGRyZXNzLCBob3dldmVyIHRoZSB1cGRhdGUgb25seSBvY2N1cnMgaWYgdGhlIHJlbW92 ZSBkZXZpY2UgYWxyZWFkeSBoYXMgYW4NCj4gZXhpc3RpbmcgbmVpZ2hib3IgY2FjaGUgZW50cnkg Zm9yIHRoZSBhZGRyZXNzLg0KPiANCg0KVHJ1ZSwgYW5kIHdlIGRvIHRoYXQgYWxyZWFkeS4gQnV0 IGEgc29saWQgYW5kIGxvY2FsIHByb29mIHRoYXQgaXQgaXMgdGhlIHNhbWUgZ3V5IGlzIGJldHRl ciwgZS5nLiBpbiBmYXN0IG1vYmlsaXR5IHRvIGF2b2lkIHNsb3dpbmcgZG93biB0aGUgcm9hbWlu Zywgb3IgaWYgdGhlIHRhcmdldCBpcyB1bnJlYWNoYWJsZSBmb3IgYSBzZWNvbmQsIHNsZWVwaW5n LCByZWJvb3RpbmcsIHdoYXRldmVyLCBpbiB3aGljaCBjYXNlIHRoZSBhZGRyZXNzIGlzIGVhc3kg dG8gc3RlYWwuIA0KVGhlIGNvbXBhbmlvbiBkcmFmdCBmb3IgUkZDIDg1MDUgaXMgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNmxvLWFwLW5kLiANCg0KPiA+IEEgc2Vuc2Ug b2Ygc2VydmljZTsgd2hhdCBzaG91bGQgdGhlIHJvdXRlciBkbyB3aXRoIHRoYXQgYWRkcmVzcz8g RXhhbXBsZXMNCj4gdGhhdCBjb21lIHRvIG1pbmQgYXJlIGluamVjdCBpbiBhIHJvdXRpbmcgcHJv dG9jb2wsIHBsYXkgc2xlZXBpbmcgcHJveHkgb3IgTkQNCj4gcHJveHkuDQo+ID4NCj4gDQo+IFRo ZXNlIHJlcXVpcmVtZW50cyBzZWVtIHRvIGJlIG1vcmUgc3BlY2lmaWMgdG8gNmxvIGVudmlyb25t ZW50cywgcmF0aGVyDQo+IHRoYW4gYSBtb3JlIGdlbmVyYWwgYW5kIGNvbW1vbiBjYXNlcy4gRm9y IGV4YW1wbGUsIGhvc3RzJw0KPiBhZGRyZXNzZXMgYXJlbid0IGluamVjdGVkIGludG8gYSByb3V0 aW5nIHByb3RvY29sIGluIG1vc3QgbmV0d29ya3MuDQoNCkFub3RoZXIgZXhhbXBsZSBpcyB0aGUg ZGF0YSBjZW50ZXIgdW5kZXJsYXksIHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1yaWZ0LXJpZnQtMDYjc2VjdGlvbi01LjMuMy4gDQoNCkFsc28gODAyLjExT0NCLCBz ZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC02bWFuLWlw djYtb3Zlci13aXJlbGVzcy8uDQoNCkFzIHNvb24gYXMgeW91ciBsaW5rIGlzIG11bHRpYWNjZXNz IHlldCBub24tdHJhbnNpdGl2ZSwgb3IgeW91ciBzdWJuZXQgaXMgbXVsdGlsaW5rLCB5b3Ugc2hv dWxkIGNvbnNpZGVyIEwzIHJvdXRpbmcuIEFsdCB5b3UgbGV0IHRoZSBMMiBkbyBpdCBmb3IgeW91 IGxpa2UgaW4gU3dpdGNoZWQgRXRoZXJuZXQgYW5kIFdpLUZpIGluZnJhc3RydWN0dXJlIG1vZGUs IGJ1dCB0aGVuIGl0IGNvbWVzIGF0IGEgY29zdCB0aGF0IHlvdSBtYXkgYmUgd2lsbGluZyB0byBh dm9pZCwgZS5nLiwgIEwzIGJyb2FkY2FzdHMuIA0KDQpUaGUgLzY0IHBlciBob3N0IGlzIGEgdmFs aWQgYXBwcm9hY2ggdG8gZ2V0IHRoZXJlLCBidXQgaXQgdGhyb3dzIE5EIHdpdGggdGhlIHdhdGVy IG9mIHRoZSBiYXRoIGFuZCBzZWVtcyB3YXN0ZWZ1bCBhdCBzY2FsZSwgZS5nLiAsIGZvciBJT1Qg ZGV2aWNlcyBhbmQgVk1zLiANCg0KSSdtIGFkdm9jYXRpbmcgZm9yIGEgbW9kZXJuaXphdGlvbiBv ZiBORCB0aGF0IGlzIG5vdCBhbnRhZ29uaXN0aWMgdG8gdGhhdCBidXQgY29tcGxlbWVudGFyeSB3 aXRoIHRoZSAvNjQgcGVyIGhvc3QgdG93YXJkcyBhIHNhbWUgZ29hbCBvZiBtb3JlIEwzIC8gcHJv YWN0aXZlLCBsZXNzIGJyb2FkY2FzdHMgLyByZWFjdGl2ZS4NCg0KPiBIb3dldmVyLCBvbmNlIGEg cm91dGVyIGhhcyBrbm93bGVkZ2Ugb2YgdGhlIGV4aXN0ZW5jZSBvZiBhbiBhZGRyZXNzLCB0aGVu IEkNCj4gdGhpbmsgd2hhdCB0aGUgcm91dGVyIHVzZXMgdGhhdCBhZGRyZXNzIGtub3dsZWRnZSBm b3IsIGluIGFkZGl0aW9uIHRvDQo+IGZvcndhcmRpbmcsIGlzIG91dCBvZiBzY29wZSBmb3IgYW4g YWRkcmVzcyBkaXNjb3Zlcnkgb3IgcmVnaXN0cmF0aW9uIHByb3RvY29sLg0KPiANCg0KQWdyZWVk LCB0aGUgcmVnaXN0cmF0aW9uIGlzIGFic3RyYWN0IHRvIHRoZSByb3V0ZXIgb3BlcmF0aW9uLiBU aGUgcG9pbnQgaXMgdGhhdCB0aGUgcm91dGVyIG9wZXJhdGlvbiBjYW4gYmUgdmFzdGx5IGltcHJv dmVkIGJ5IHNpbXBsZSB0aGluZ3MgbGlrZSBhIHNlcXVlbmNlIG51bWJlciBvciBhIGxpZmV0aW1l Lg0KDQpBbGwgdGhlIGJlc3QsDQoNClBhc2NhbA0K From nobody Mon Jul 8 05:51:26 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8325D12017E; Mon, 8 Jul 2019 05:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 0dytK6IQRtzt; Mon, 8 Jul 2019 05:51:06 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF55D1201BC; Mon, 8 Jul 2019 05:51:06 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45j50m61WVzyWd; Mon, 8 Jul 2019 14:51:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 8 Jul 2019 14:51:04 +0200 Cc: Mark Smith , Michael Richardson , 6man <6man@ietf.org>, V6 Ops List , "6lo@ietf.org" <6lo@ietf.org> X-Mao-Original-Outgoing-Id: 584283062.758004-77ec78b223e01b6df58edc7f1b9b5865 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Pascal Thubert X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 12:51:18 -0000 On Jul 8, 2019, at 14:41, Pascal Thubert (pthubert) = wrote: >=20 >> What sort of device is a "L3AP"? In RFC 8200 we don't have that sort = of device >> defined, we just have links, hosts, routers and nodes (IPv6 host or = router). >=20 > Like a L3-switch but wireless. An AP is a bridge that is proactively = programmed on the wireless side with the association process, as opposed = to a learning (transparent) bridge that requires the broadcast. RFC 6775 = / 8505 is the same thing at L3. If you add L3 features like an SVI to = the AP, and L3 functions in there like RFC8505, routing, and/or ND = proxy, then you have an L3-AP. Hi Pascal, out there again confusing everyone with needlessly invented terminology? = :-) These things are called 6LRs in RFC 6775/8505, for people who want to = look up what they do (or do you mean 6LBRs?). Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 8 06:08:22 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6440B1201D8; Mon, 8 Jul 2019 06:08:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <156259129434.808.7315076639487140626@ietfa.amsl.com> Date: Mon, 08 Jul 2019 06:08:14 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 13:08:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-07.txt Pages : 45 Date : 2019-07-08 Abstract: This document describes how NAT64 (including 464XLAT) can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise, and possible optimizations. The document also discusses issues to be considered when having IPv6-only connectivity, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-07 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-deployment-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 06:11:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4BB120179; Mon, 8 Jul 2019 06:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 uyXIOWQED0Ck; Mon, 8 Jul 2019 06:11:45 -0700 (PDT) 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 2BA87120165; Mon, 8 Jul 2019 06:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562591501; x=1563196301; 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=M7GYib7bPAWrYt6elYpjrRTP6tiArwYPTTBIkn+xgaU=; b=vq/b6WOVEAAhE k021PiKStwVp0h4dS9PxyQWOuTvcoDjC8OKEtDq0hRrJOgdX18mteytBXDMg0eHE RBHEjVbnFCgBkcp5Dvxz+DtroHYeSf9yx+d8lIbLmaYeqC09jwjS12JPcUO/aSE+ O0R43iK1pdSjumJ8GtY6RgNXNrFMak= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 08 Jul 2019 15:11:41 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 08 Jul 2019 15:11:40 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006319141.msg; Mon, 08 Jul 2019 15:11:39 +0200 X-MDRemoteIP: 2001:470:1f09:495:b8dc:4079:28f8:8ce7 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Mon, 08 Jul 2019 15:11:39 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1092a35ad6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Mon, 08 Jul 2019 15:11:38 +0200 From: JORDI PALET MARTINEZ To: "Eric Vyncke (evyncke)" , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Message-ID: <000E42C7-8564-4C7E-930E-076F1C0F1D11@consulintel.es> Thread-Topic: [v6ops] =?UTF-8?B?w4lyaWM=?= Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT) References: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com> <75A5EB61-3879-4F83-83BB-D65EE8799AF3@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-nat64-deployment-06=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 13:11:49 -0000 Hi Eric, I just posted a new version (https://datatracker.ietf.org/doc/draft-ietf-v6= ops-nat64-deployment/). I believe it addresses all the issues and nits that you have raised (plus o= ther nits that I've found as well). Again, thanks a lot for the very detailed review! Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 8/7/19 8:45, "Eric Vyncke (evyncke)" escrib= i=C3=B3: Hola Jordi, =20 A couple of my comments were about lacking of references for "known to = work" or "monitored by some governmental bodies and other institutions" or = ""with hundreds of millions of users" which are strong statements without a= ny factual data behind them. I make me feel uncomfortable... the document w= ould be much stronger if there were references (external papers are fine). =20 Your explanations for "ACL of clients" are clear now. I suggest that yo= u rewrite the section to add the example given in your reply. And, use a di= fferent name to the section ;-) =20 Thank you for all the fixes and for authoring the document =20 -=C3=A9ric =20 =EF=BB=BFOn 07/07/2019, 23:39, "JORDI PALET MARTINEZ" wrote: =20 -- Section 3.1 -- =20 "known to work": can you add references or data backing this st= atement ? =20 Well, those are the models being used today in cellular and broadba= nd networks. So I can just say that? =20 -- Section 3.1.1 -- =20 When discussing scenarii, please refer to the figure ID in the = text for clarity. =20 Done (I'm already editing a new version while writing this, pending= on some that you can provide to my comments). =20 -- Section 3.1.2 -- =20 It is unclear to me whether "The support of this scenario" refe= rs to the UE-only or the CPE deployment. =20 It is referring to the "service provider network support". Will cla= rify it. =20 Same demand as above: please refer to the figure ID in the text= for clarity. =20 Done! =20 -- Sectio 3.2.1 -- =20 I really wonder whether it is useful to describe this scenario = as 'working under special conditions'... those 'special conditions' will pr= obably never met in real life. =20 More generally, I am unsure about the value of the whole sectio= n 3.2 (it is more like an academic thing). =20 I think some of those scenarios are possible in some networks, may = be not connecting to Internet, or for example, you may want to configure ex= plicit mappings, which can be done with EAM. I just realized that I've not = cited that. I will do. =20 -- Section 4.1.1. -- =20 Can you add reference and/or data for "monitored by some govern= mental bodies and other institutions". =20 I believe that was pointed out by somebody in the WG, but it is tru= e that some regulators do that. I recall having seen something about that i= n France, but I'm not 100% sure right now. =20 Please add a reference for the use of "ipv4only.arpa". AFAIK =20 Right, this is defined by RFC7050, done! =20 draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dea= d. =20 This is one of the issues that I've commented with Warren, respondi= ng to IANA. I understand he is sponsoring that document.=20 =20 =20 -- Section 4.1.2 -- =20 The leading paragraph is a little confusing as it assumed that = CLAT exists (stated in the text but not in the section title). =20 Will clarify it. =20 -- Section 4.1.5 -- =20 The section title is rather misleading "ACL of clients" and I w= onder why a dual-stack client would use a DNS64 server as its recursive DNS= server. Isn't it an obvious configuration mistake? =20 No, I think that text is correct, but I will try to reword it to ma= ke it clearer. You may have a situation with IPv4-only servers, which are l= ocated, in the path between the dual-stack hosts and the NAT64. So, if the = DNS64 is not configured to exclude those servers, it will synthetize the AA= AA records and they will become unreachable. So that's why bind and other D= NS64 servers provide this ACL function. =20 -- Section 4.4.1 -- =20 Some explanations of the consequences of a foreign DNS would be= welcome. =20 Done! =20 -- Section 4.4.2 -- =20 Rather than using "DNS privacy" please use "DNS request confide= ntiality" as the DNS64 will learn/glean about the client activities. =20 I used this terminology as it was suggested as the common one for t= he different protocols in this category. I will try to confirm if is the ri= ght one just in case. May be rewording the title as "DNS Privacy/Encryption= Mechanisms" ? =20 =20 =20 -- Section 4.6 -- =20 Please explain why older API is a problem (or rather rephrase i= t into applications using IPv4-only API). =20 Done! =20 -- Section 4.10 -- =20 draft-ietf-tram-turnbis is also able to support IPv6-only clien= t. It is currently in the same IESG status as this document. =20 Definitively, will add a reference to it! =20 -- Section 5 -- =20 Please add data/references for "with hundreds of millions of us= ers" =20 I can cite several cellular networks, but I will do in a generic wa= y, I don't think we should mention explicit providers, right?.=20 =20 -- Section 7 -- =20 Not so much about security but about privacy. I would appreciat= e to have some text around the lack of privacy when using an external DNS64 as= this server will learn about all clients activities. =20 Good point, thanks. Will do! =20 =3D=3D NITS =3D=3D =20 Generally, please refrain from using "HEv2" in place of "Happy = Eyeball version 2". =20 Done! =20 -- Section 3.1.1. -- =20 Figure 1 shows a box containing both NAT64 and DNS64 while thos= e functions could reside in different devices. =20 Will clarify it. =20 s/One more equivalent scenario/One additional equivalent scenar= io/ ? =20 Done! =20 -- Section 4.1 -- =20 s/to an IPv6-only WAN/to an IPv6-only access network/ =20 Done! =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven 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 th= e original sender to inform about this communication and delete it. =20 =20 =20 =20 =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 Mon Jul 8 08:06:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD4412018A; Mon, 8 Jul 2019 08:06:12 -0700 (PDT) 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, 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 header.b=PvM6jjpt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KyXyuwFL 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 4nnYgZcnRJNY; Mon, 8 Jul 2019 08:06:09 -0700 (PDT) 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 B3138120221; Mon, 8 Jul 2019 08:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2020; q=dns/txt; s=iport; t=1562598344; x=1563807944; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hg7xvtcpeynrYClSC+UDzbmgtXb/t+R3EukyfGRwTFQ=; b=PvM6jjptgV8PdU4uAR1NLXl26DauxfCiu45CQrDGqJlKN2mJOmRNDRmK oaOTMKUD9bLtx6XjcbOrZd2/NKospNvcreDD76stnJ+SH6r85XgRn5nbu n31DpPTRHyWUb8EVYGLYkp0qF44P62Sxuzv4AdJj/5gOiSpWk8y8dUG2o w=; IronPort-PHdr: =?us-ascii?q?9a23=3AL64VoBfhcRdg+4Nvu1mZPt21lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAABKWyNd/49dJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBQ1ADgT8gBAsohByDRwOEUol2gluJTY15gS6?= =?us-ascii?q?BJANUCQEBAQwBAS0CAQGEQAIXgiEjNAkOAQMBAQQBAQIBBW2KNwyFSgEBAQE?= =?us-ascii?q?DEhERDAEBKwwBCwQCAQYCDgMEAQEBAgImAgICHxEVCAgCBA4FCBqEawMdAQK?= =?us-ascii?q?OH5BgAoE4iGBxgTKCeQEBBYR6DQuCEgmBDCgBhHGGbReBQD+BV4IeLj6BBIE?= =?us-ascii?q?WgiyDCDKCJo5wmyZACQKCF5ARhA6XfpZjjgoCBAIEBQIOAQEFgVA4gVhwFTu?= =?us-ascii?q?CbIJBg3GKU3KBKY1IAQE?= X-IronPort-AV: E=Sophos;i="5.63,466,1557187200"; d="scan'208";a="591287212" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2019 15:05:24 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x68F5OCJ011969 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2019 15:05:24 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 10:05:23 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 11:05:13 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Jul 2019 11:05:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hg7xvtcpeynrYClSC+UDzbmgtXb/t+R3EukyfGRwTFQ=; b=KyXyuwFLhJwZVlNYfbmcJOV5t0ZiAQBvMxeFGWjp3Nv0eHD5wMdjbikk5zy34waYxefnPIQFR9tZqbcPNHRHLxcKU421QAF26lOl2vOoeaJrhY2trC5yJh4F4EmsxCcnStKWDIBoDkPVMl1uFVhCRBIckgJ3meF0LdYSsHR6DfE= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3952.namprd11.prod.outlook.com (10.255.181.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Mon, 8 Jul 2019 14:31:51 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 14:31:51 +0000 From: "Pascal Thubert (pthubert)" To: Carsten Bormann CC: Mark Smith , Michael Richardson , 6man <6man@ietf.org>, V6 Ops List , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs Thread-Index: AdUyXLsjbUS9G1zfTQuzwoWpAiUtYQACLMYAAAC/GgAATi6UAAB5DMJQAAGdWgAAAAZqIA== Date: Mon, 8 Jul 2019 14:31:27 +0000 Deferred-Delivery: Mon, 8 Jul 2019 12:54:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1001::89] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 40cac201-2e2a-44db-f9c0-08d703b10483 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3952; x-ms-traffictypediagnostic: MN2PR11MB3952: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(396003)(346002)(376002)(199004)(189003)(13464003)(71190400001)(446003)(71200400001)(11346002)(476003)(46003)(486006)(5660300002)(81166006)(52536014)(8676002)(81156014)(53546011)(7696005)(76176011)(316002)(6506007)(102836004)(186003)(99286004)(6916009)(76116006)(305945005)(14454004)(66574012)(6666004)(256004)(66556008)(8936002)(74316002)(66476007)(7736002)(66446008)(64756008)(2906002)(66946007)(73956011)(6246003)(25786009)(6436002)(4326008)(33656002)(478600001)(229853002)(54906003)(6116002)(9686003)(53936002)(55016002)(68736007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3952; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: neEiE/2ZjpW2yWi+XSb96MGrH8K0EsTexeXNEDx9LkRqkd0GGNO6/vJQxkRqLmRGowmXt0bjsdb2m0ZVJKMrbFiMjscziKFtE1fifS1SK/yy5DAmGuxjFImRXHWj2fmWC90ncHalaNKpPdbfltNOP6VCKaWu/TVUj8G5W4iVuRtN5koi9UdYXV+VC+pCOPWEI+4nTpG3/Sid/UI5v1idsNYudZqdN9Jpma4y8rW/EK6lHDhC2Nk0BPLLi3fEyMEDeOLSZpJwIiyymYgPneUId6yRsdiYZKapN1uWaPiBFZ/ke6lgkZ4chsYP4ehDb3LkR3/phEjUvCziS4IBZq/dqwUusVT5vWxQdUHZpOv3tnI0FnFhLY5ItfFYaDshT5rYkI7Et64gRCcMmxnA2vIFpIIFXSMk0bSOZhPgp/QmLhg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 40cac201-2e2a-44db-f9c0-08d703b10483 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 14:31:51.4887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3952 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 15:06:13 -0000 SGVsbG8gQ2Fyc3RlbjoNCg0KVGhlIDZMUiwgb3IgNkxCUiwgYXJlIGxvZ2ljYWwgZnVuY3Rpb25z LiBBIEwzLXN3aXRjaCBpcyBhIGJveCB0aGF0IGhhcyBpdHMgZGlmZmVyZW5jZXMgd2l0aCBhIHJv dXRlci4NCg0KQWxsIHRoZSBiZXN0LA0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCj4gU2VudDog bHVuZGkgOCBqdWlsbGV0IDIwMTkgMTQ6NTENCj4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVy dCkgPHB0aHViZXJ0QGNpc2NvLmNvbT4NCj4gQ2M6IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBn bWFpbC5jb20+OyBNaWNoYWVsIFJpY2hhcmRzb24NCj4gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47 IDZtYW4gPDZtYW5AaWV0Zi5vcmc+OyBWNiBPcHMgTGlzdA0KPiA8djZvcHNAaWV0Zi5vcmc+OyA2 bG9AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFs2bG9dIEFkdm9jYXRpbmcgYSBnZW5lcmFsaXph dGlvbiBvZiBSRkM4NTA1IHRvIG5vbi02bG8gTEFOcw0KPiANCj4gT24gSnVsIDgsIDIwMTksIGF0 IDE0OjQxLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+DQo+ IHdyb3RlOg0KPiA+DQo+ID4+IFdoYXQgc29ydCBvZiBkZXZpY2UgaXMgYSAiTDNBUCI/IEluIFJG QyA4MjAwIHdlIGRvbid0IGhhdmUgdGhhdCBzb3J0DQo+ID4+IG9mIGRldmljZSBkZWZpbmVkLCB3 ZSBqdXN0IGhhdmUgbGlua3MsIGhvc3RzLCByb3V0ZXJzIGFuZCBub2RlcyAoSVB2NiBob3N0IG9y DQo+IHJvdXRlcikuDQo+ID4NCj4gPiBMaWtlIGEgTDMtc3dpdGNoIGJ1dCB3aXJlbGVzcy4gQW4g QVAgaXMgYSBicmlkZ2UgdGhhdCBpcyBwcm9hY3RpdmVseQ0KPiBwcm9ncmFtbWVkIG9uIHRoZSB3 aXJlbGVzcyBzaWRlIHdpdGggdGhlIGFzc29jaWF0aW9uIHByb2Nlc3MsIGFzIG9wcG9zZWQgdG8N Cj4gYSBsZWFybmluZyAodHJhbnNwYXJlbnQpIGJyaWRnZSB0aGF0IHJlcXVpcmVzIHRoZSBicm9h ZGNhc3QuIFJGQyA2Nzc1IC8gODUwNSBpcw0KPiB0aGUgc2FtZSB0aGluZyBhdCBMMy4gSWYgeW91 IGFkZCBMMyBmZWF0dXJlcyBsaWtlIGFuIFNWSSB0byB0aGUgQVAsIGFuZCBMMw0KPiBmdW5jdGlv bnMgaW4gdGhlcmUgbGlrZSBSRkM4NTA1LCByb3V0aW5nLCBhbmQvb3IgTkQgcHJveHksIHRoZW4g eW91IGhhdmUgYW4NCj4gTDMtQVAuDQo+IA0KPiBIaSBQYXNjYWwsDQo+IA0KPiBvdXQgdGhlcmUg YWdhaW4gY29uZnVzaW5nIGV2ZXJ5b25lIHdpdGggbmVlZGxlc3NseSBpbnZlbnRlZCB0ZXJtaW5v bG9neT8gOi0pDQo+IA0KPiBUaGVzZSB0aGluZ3MgYXJlIGNhbGxlZCA2TFJzIGluIFJGQyA2Nzc1 Lzg1MDUsIGZvciBwZW9wbGUgd2hvIHdhbnQgdG8gbG9vaw0KPiB1cCB3aGF0IHRoZXkgZG8gKG9y IGRvIHlvdSBtZWFuIDZMQlJzPykuDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQoNCg== From nobody Mon Jul 8 08:49:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D41C1201AA; Mon, 8 Jul 2019 08:49:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 r3PMk3RMAbMM; Mon, 8 Jul 2019 08:49:25 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 4D3B912015A; Mon, 8 Jul 2019 08:49:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HlBQC+ZCNd/yYyC4dlHQEBBQEHBQGBZ?= =?us-ascii?q?4FEUIFfAwQzCodZA4UxiRiCW5oYAxg8CQEBAQ0BLQIBAQKEPgKCXDgTAQMBAQE?= =?us-ascii?q?EAQEBAQQBAgJpijcMg0U5MgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQUCODgBAQEBAgESKAYBATAHAQQHBAIBCBUhEDIlAgQOBQgTB4RrAw4?= =?us-ascii?q?PAQICnw0CgQgwiF8BAYIiGoJfAQEFhHsYghIJCQGBKot2gUE+gRFGgkw+hC4Yg?= =?us-ascii?q?zqCJqpWCQKCF5QfjUYDijWkbQICAgIEBQIOAQEFgWcigVhwFYMngkGDcYpTcgG?= =?us-ascii?q?BKIwnAYEgAQE?= X-IPAS-Result: =?us-ascii?q?A2HlBQC+ZCNd/yYyC4dlHQEBBQEHBQGBZ4FEUIFfAwQzCod?= =?us-ascii?q?ZA4UxiRiCW5oYAxg8CQEBAQ0BLQIBAQKEPgKCXDgTAQMBAQEEAQEBAQQBAgJpi?= =?us-ascii?q?jcMg0U5MgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCODg?= =?us-ascii?q?BAQEBAgESKAYBATAHAQQHBAIBCBUhEDIlAgQOBQgTB4RrAw4PAQICnw0CgQgwi?= =?us-ascii?q?F8BAYIiGoJfAQEFhHsYghIJCQGBKot2gUE+gRFGgkw+hC4YgzqCJqpWCQKCF5Q?= =?us-ascii?q?fjUYDijWkbQICAgIEBQIOAQEFgWcigVhwFYMngkGDcYpTcgGBKIwnAYEgAQE?= Received: from mailauth.avaya.com (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Jul 2019 11:49:23 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2019 11:49:22 -0400 Received: from PW365VMAP01.avaya.com (135.11.29.21) by az-us1exhc01.global.avaya.com (135.11.85.12) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Jul 2019 11:49:22 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.58) by PW365VMAP01.avaya.com (135.11.29.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Mon, 8 Jul 2019 10:49:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4TL99YKmyq+DqdFvDypAdPbPXniQVU/oGFhrFg89k+w=; b=bt8MI6LnZ9iINjJqt0gWV7TrC2s6Ms+LDMkGqwHJ4uNKg07bAXef71ACDOvZqjs4q1P5qlxEcwBtG9B6YyMxvGKTs3quFZ2/8rmnssUMo5X5ki21eT8oZnCswGMGNk6+TEnzPN6QU+nCOrLTEhHeD1yix+Rdv3SferKVTQ+D4qk= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2985.namprd15.prod.outlook.com (20.178.231.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 15:49:21 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 15:49:21 +0000 From: "Mudric, Dusan (Dusan)" To: "Manfredi (US), Albert E" CC: IPv6 Operations , 6man <6man@ietf.org> Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AQHVM23JQTP2spnzX0G8BrvKPAtN5qbA4JKA Date: Mon, 8 Jul 2019 15:49:21 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2d6ea21-c75c-4060-a069-08d703bbd7da x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2985; x-ms-traffictypediagnostic: DM6PR15MB2985: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(136003)(39860400002)(396003)(189003)(199004)(13464003)(68736007)(6116002)(446003)(3846002)(11346002)(316002)(66066001)(476003)(486006)(6246003)(25786009)(55236004)(86362001)(76176011)(7696005)(4326008)(33656002)(6436002)(478600001)(6916009)(54906003)(66476007)(8936002)(66446008)(66556008)(66946007)(256004)(64756008)(229853002)(26005)(6506007)(7736002)(76116006)(5660300002)(8676002)(81166006)(81156014)(73956011)(305945005)(52536014)(99286004)(74316002)(14454004)(186003)(53936002)(71190400001)(71200400001)(55016002)(9686003)(2906002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2985; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1GlfNO0nXVXY9MIX2ifhswd1qYzWw8OH0fF2hXtoVFTWPabzFEQNFCPCQEJTxTe6mBBY54FlDPTwsbJCrLYvB2FlE9OPuMOsvM4lIA6QyTe1QpcVxkqs7tUaaIdYYeXHttNEsjBa3i5mOEaF6ANx3hKMP2Q9bNRfrBl2BNs1RQkf03VauIhEn7X9Fs30XRt/uNKKyRZhpo4O2/bRqZ+AnS6AxacVqHPX9um8n0dq458Ja30E7A0pvV8gOnvhu2chtnHQAX1iqkTno5Lenvv0mIJJX3vEVepSC0hwo9Vq4qWNOK/VS/EaZ9eia4M3UzYC9wjVq4znGmSAc92btcwLmD7cidnQ+v0YEqX08TL8Mgs0/gYortNWOTo19DrZT9tSEokd+CHlmtGIkdmysrgatJrX83RnVIueRxo0Ni8L5b8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c2d6ea21-c75c-4060-a069-08d703bbd7da X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 15:49:21.0662 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2985 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 15:49:29 -0000 > -----Original Message----- > From: Manfredi (US), Albert E >=20 > -----Original Message----- > From: ipv6 On Behalf Of Mudric, Dusan (Dusan) >=20 > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and v= ice > versa? >=20 > IPv6 to IPv4 should be straightforward, because it's a one-to-one > relationship. The other way around would normally not work,=20 [Dusan] There is no solution for IPv4only client to reach IPv6only client?= =20 > but everyone > has been accustomed to that with IPv4 NAPT already.=20 [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed= not to be able to call IPv6only users (like Apple IPv6 only phones)? >The client behind the > NAPT initiates. >=20 > > Is DNS64 server returning IPv4ony client address to IPv6only client, us= ing > the A RR? >=20 > The DNS synthesizes the IPv6 address, which has the IPv4 address > embedded in it. >=20 > > - How can IPv4only client get the address of IPv6only client (or, it is > impossible for IPv4only client to get IPv6 address of IPv6only client)? >=20 > That's clearly more difficult, which is why the normal course of action i= s for > the IPv6 client to initiate the session. [Dusan] What if IPv4only client needs to initiate the session to IPv6only c= lient? What is the solution for that use case? >=20 > > - Do these IPv4 and IPv6 client addresses need to be pre-configured on = the > translator and/or DNS64? >=20 > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the sessi= on, you'd > have to have preconfigure something. [Dusan] Where and how is this configuration done? >=20 > Bert From nobody Mon Jul 8 09:07:46 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEAC1202FD for ; Mon, 8 Jul 2019 09:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 oKbvkQoxezTT for ; Mon, 8 Jul 2019 09:07:33 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12A61202B7 for ; Mon, 8 Jul 2019 09:07:32 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1C245406BA for ; Mon, 8 Jul 2019 18:07:30 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0AFF4406B7; Mon, 8 Jul 2019 18:07:30 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id F0490B41D; Mon, 8 Jul 2019 18:07:29 +0200 (CEST) Date: Mon, 8 Jul 2019 18:07:29 +0200 From: Gert Doering To: "Mudric, Dusan (Dusan)" Cc: "Manfredi (US), Albert E" , IPv6 Operations , 6man <6man@ietf.org> Message-ID: <20190708160729.GW14471@Space.Net> References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 16:07:44 -0000 Hi, On Mon, Jul 08, 2019 at 03:49:21PM +0000, Mudric, Dusan (Dusan) wrote: > > IPv6 to IPv4 should be straightforward, because it's a one-to-one > > relationship. The other way around would normally not work, > [Dusan] There is no solution for IPv4only client to reach IPv6only client? Of course there is - upgrade the IPv4-only client to do IPv6, and get rid of all the translator stuff. > > has been accustomed to that with IPv4 NAPT already. > [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed not to be able to call IPv6only users (like Apple IPv6 only phones)? SIP stuff usually goes via a media gateway / session border controller anyway. That gateway would be dual-stacked then. 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 Jul 8 09:21:49 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2471202B9; Mon, 8 Jul 2019 09:21:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 1vB0x1_50TSh; Mon, 8 Jul 2019 09:21:36 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 68987120282; Mon, 8 Jul 2019 09:21:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EKAAAebSNd/yYyC4dlGgEBAQEBAgEBA?= =?us-ascii?q?QEHAgEBAQGBVAQBAQEBCwGBQykngV8DBDMKh1kDhTGJGYJbl0aBLoEkAxg8CQE?= =?us-ascii?q?BAQ0BLQIBAQKEPgKCXDUIDgEDAQEBBAEBAQEEAQICaYo3DINFOTIBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAjg4AQEBAQIBEigGAQEwBwE?= =?us-ascii?q?LBAIBCBEEAQEBHhAyHQgCBA4FCBMHhGsDDg8BAgKfIwKBCDCIXwEBgiIagl8BA?= =?us-ascii?q?QWEfRiCEgkJAYEqAYt1gUE+gRFGgkw+hEaDOoImjE0BnggJAoIXlB+NRgOKNaR?= =?us-ascii?q?tAgICAgQFAg4BAQWBUgE2gVhwFYMngkEMF4EDAQKCSIpTcgGBKIwnAYEgAQE?= X-IPAS-Result: =?us-ascii?q?A2EKAAAebSNd/yYyC4dlGgEBAQEBAgEBAQEHAgEBAQGBVAQ?= =?us-ascii?q?BAQEBCwGBQykngV8DBDMKh1kDhTGJGYJbl0aBLoEkAxg8CQEBAQ0BLQIBAQKEP?= =?us-ascii?q?gKCXDUIDgEDAQEBBAEBAQEEAQICaYo3DINFOTIBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEFAjg4AQEBAQIBEigGAQEwBwELBAIBCBEEAQEBH?= =?us-ascii?q?hAyHQgCBA4FCBMHhGsDDg8BAgKfIwKBCDCIXwEBgiIagl8BAQWEfRiCEgkJAYE?= =?us-ascii?q?qAYt1gUE+gRFGgkw+hEaDOoImjE0BnggJAoIXlB+NRgOKNaRtAgICAgQFAg4BA?= =?us-ascii?q?QWBUgE2gVhwFYMngkEMF4EDAQKCSIpTcgGBKIwnAYEgAQE?= Received: from mailauth.avaya.com (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Jul 2019 12:21:32 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2019 12:21:31 -0400 Received: from PWEXCVMAP01.global.avaya.com (135.11.85.80) by AZ-US1EXHC03.global.avaya.com (135.11.85.14) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 8 Jul 2019 12:21:31 -0400 Received: from PWEXCVMAP01.global.avaya.com (135.11.85.80) by PWEXCVMAP01.global.avaya.com (135.11.85.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Mon, 8 Jul 2019 12:21:31 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by PWEXCVMAP01.global.avaya.com (135.11.85.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1531.3 via Frontend Transport; Mon, 8 Jul 2019 12:21:31 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (104.47.49.54) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Mon, 8 Jul 2019 11:21:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OL6m6DWBgnTKVZiwzuubbiSJ8gBNmuz9f0VhbTlWI5Q=; b=KI+9RxJOeQg8DVweTekgVJZE/ow2EHotecaVfWGFeoBHAwgN0rvJZXrWcjwNd1q6RO4MmhTDOS6ih15+7bfbXwr7aOEwIkujBVtNWSqnY9E0tu3i3R67VOWps5wyP4coYyuMdBFobq5gpsKPk0XjfofpfeNbquqMfft72iNI4kw= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2426.namprd15.prod.outlook.com (20.176.65.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.17; Mon, 8 Jul 2019 16:21:30 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 16:21:30 +0000 From: "Mudric, Dusan (Dusan)" To: Gert Doering CC: "Manfredi (US), Albert E" , IPv6 Operations , 6man <6man@ietf.org> Thread-Topic: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AQHVM23JQTP2spnzX0G8BrvKPAtN5qbA4JKAgAAHDoCAAAIUsA== Date: Mon, 8 Jul 2019 16:21:30 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <20190708160729.GW14471@Space.Net> In-Reply-To: <20190708160729.GW14471@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 24d1478e-80ef-4c7f-54b2-08d703c055bc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2426; x-ms-traffictypediagnostic: DM6PR15MB2426: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(396003)(39860400002)(346002)(13464003)(189003)(199004)(55016002)(6436002)(9686003)(53936002)(52536014)(6116002)(3846002)(54906003)(76116006)(66066001)(6246003)(14454004)(25786009)(316002)(86362001)(4326008)(26005)(73956011)(102836004)(64756008)(66446008)(66476007)(478600001)(6506007)(66556008)(476003)(256004)(55236004)(71200400001)(53546011)(33656002)(8676002)(14444005)(446003)(486006)(8936002)(5660300002)(186003)(71190400001)(229853002)(2906002)(305945005)(7736002)(81156014)(66946007)(99286004)(76176011)(11346002)(68736007)(74316002)(7696005)(81166006)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2426; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OqMax/VewXMDqmNfbkx7GsT0Ao5QJsDl9G4hdvQXT9bwuQddEDNl5l7Qjkbwho3/2HgwoTFWvjFHEDEtV4cq6ISRi0dJumgB5QfMC1Lc1H9xdhMXJhQhhNULu8nl3fg9xW9anHUFEBzPcOPevXhiZxMQIaiP3uHTo1ooo/T59r1/3nnGFKVDuDOTY9UDQieaMlvB4rVZePR9k2gdXmkouk+OAbGJFbkg/LEXJl0/M6idMD0liOL2YOLujekvHDt/xx/+bq6EH6sBkb49Y8JQYhsioLcjNaxoGWQ5MowdI9H4YAZOiziJyzjGNN60Xqt6p1nKKakcVL7r+s+7fL1OrogJauB3U85FWOdahdliG0Au51BQbCLdX4rwSrwFBO+uJXbqdK1rwIlMtrZnIUC9kFpyXVpc5ENa4k9OIxYz6zA= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 24d1478e-80ef-4c7f-54b2-08d703c055bc X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 16:21:30.1755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2426 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 16:21:48 -0000 > -----Original Message----- > From: Gert Doering > Sent: Monday, July 8, 2019 12:07 PM > To: Mudric, Dusan (Dusan) > Cc: Manfredi (US), Albert E ; IPv6 > Operations ; 6man <6man@ietf.org> > Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 >=20 > Hi, >=20 > On Mon, Jul 08, 2019 at 03:49:21PM +0000, Mudric, Dusan (Dusan) wrote: > > > IPv6 to IPv4 should be straightforward, because it's a one-to-one > > > relationship. The other way around would normally not work, > > [Dusan] There is no solution for IPv4only client to reach IPv6only clie= nt? >=20 > Of course there is - upgrade the IPv4-only client to do IPv6, and get rid= of all > the translator stuff. [Dusan] The question was not about IPv6only client reaching IPv6only client= . The question was about IPv4only client in IPv4only network reaching IPv6o= nly client in IPv6only network. Which translation technology provides a sol= ution for that? >=20 > > > has been accustomed to that with IPv4 NAPT already. > > [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be > accustomed not to be able to call IPv6only users (like Apple IPv6 only > phones)? >=20 > SIP stuff usually goes via a media gateway / session border controller > anyway. That gateway would be dual-stacked then. [Dusan] Imposing all enterprises to immediately upgrade to dual networks, t= o be able to talk to IPV6only devices, is not a realist request. The questi= on is what is the translation technology that makes IPv4only client and gat= eway in IPv4only network, interwork with IPv6only client in IPv6only networ= k? >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > 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 Jul 8 09:58:18 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933581202ED for ; Mon, 8 Jul 2019 09:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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=umn.edu 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 TU2UXpsJa2A6 for ; Mon, 8 Jul 2019 09:58:03 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 5CD8C120318 for ; Mon, 8 Jul 2019 09:57:09 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 8D5EE840 for ; Mon, 8 Jul 2019 16:57:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqM6nwByi8FJ for ; Mon, 8 Jul 2019 11:57:08 -0500 (CDT) Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 3CDFA5DA for ; Mon, 8 Jul 2019 11:57:08 -0500 (CDT) Received: by mail-vk1-f200.google.com with SMTP id 21so6822451vki.1 for ; Mon, 08 Jul 2019 09:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uwmqLIPO8GaLyZlI+hv4GEkm1ySPGdbcHSBQ1t1VoRc=; b=BYfFV+Ef8MF2XVuawcfrSCyTjbGSEHaYMIsIZnC65pfHW1ip/EHGG51328Vulw6oV5 vJwgE6HLAOrQjoTwmuiXwIBqQhsWheos1fHewPDTHHyaAZpOMoDlmRPid6cSHFZcTRZ7 q648Xs8J5Q7/npV0cFgtCmoeZR2fgFtGiRyp6cEXn/V32fEROGfIMeoWT2GGm0xHdrsl c46e+rLJCM9PxxCj5zjqZvxISsjEd/VuZOg4x7CIUHIOUSs25LM4U5qpGl6z/L5qBYsS tZ27ZA/FsFeka3Ri4QQsmLRR39rl8NYlqWFuqTpO5H/Q3hsO1fvc3HtXW62KwXwDANKz 7XYw== 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=uwmqLIPO8GaLyZlI+hv4GEkm1ySPGdbcHSBQ1t1VoRc=; b=K/79LNV1zTqyBGgAHk5gr7o1I3Aoj50Hg+lqhsbk/dL3f/POLSgKygQaS47rk5LgWX XD4rG6NUZ+mRnAfBfDr8+sxgQgZsGSjbe+bH/t8n0szn8IAo3X/BwnjPFzA+KozekoxB ng6kVd9/EawMkLLcC8DpRsEfkaqk2Cku0hWubWH2M7lp4YoD52E1XE8R9s9a8Qxm7OEF B99LIlQiubdzK4eI7RnA/pnKRKWTbfvztYj5/XuSS5Tyydgeug35RnYhHnsuCg9uUTaV UXkVlQFWDxhEak2JqsH1LT4GSUVs2YN2w6BIpGPVG/kGKQ5CNHJYUXOiTe3x40rEiU29 vDzQ== X-Gm-Message-State: APjAAAXPi7eIN4c2/GB/sbqxIj3aCIzw6VPzO4U/7tyZQa/VRoGC6luI nI7WAti/YGc4V5vZKKgCExugDDFHtX3NF8T4woIZAQMt35xqya/4YdG2n/qx/ZUUaqJXShNkbym ezTOGf9SOl7zOvpO0ap20j7M1qw== X-Received: by 2002:a1f:19ce:: with SMTP id 197mr5741280vkz.60.1562605027058; Mon, 08 Jul 2019 09:57:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqxzHd2TXHOsavXe0oBaeG9u2VaNArgQbIUuqJEndLdQ+I7m/L3aBW2CPu26gsnzgJnhdXGtAWkHoBJZ46Kf1Sw= X-Received: by 2002:a1f:19ce:: with SMTP id 197mr5741250vkz.60.1562605026537; Mon, 08 Jul 2019 09:57:06 -0700 (PDT) MIME-Version: 1.0 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: From: David Farmer Date: Mon, 8 Jul 2019 11:57:01 -0500 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: "Manfredi (US), Albert E" , IPv6 Operations , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000880540058d2e55e7" Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 16:58:13 -0000 --000000000000880540058d2e55e7 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) wrote: > > -----Original Message----- > > From: Manfredi (US), Albert E > > > > -----Original Message----- > > From: ipv6 On Behalf Of Mudric, Dusan (Dusan) > > > > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and > vice > > versa? > > > > IPv6 to IPv4 should be straightforward, because it's a one-to-one > > relationship. The other way around would normally not work, > [Dusan] There is no solution for IPv4only client to reach IPv6only client? > I mostly say, so what! It is an unfortunate reality of today's Internet, because of NAT44 and/or stateful firewall default deny inbound policy, many times clients can't speak to other clients, be they IPv4 only, IPv6 only, or even dual stack. Sometimes firewall traversal technologies can work around this, also depending on the firewall traversal solution used sometimes IPv4 only and IPv6 only clients will be able to talk to each other. My guess is that IPv4 only to IPv6 only firewall traversal would be less effective than NAT44 client to NAT44 client firewall traversal, but it is should still be possible in some cases. > > but everyone > > has been accustomed to that with IPv4 NAPT already. > [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be > accustomed not to be able to call IPv6only users (like Apple IPv6 only > phones)? > They may not be able to talk peer to peer. However, through a dual-stack SIP or other proxies/session border controller, they could probably complete a call. > >The client behind the > > NAPT initiates. > > > > > Is DNS64 server returning IPv4ony client address to IPv6only client, > using > > the A RR? > > > > The DNS synthesizes the IPv6 address, which has the IPv4 address > > embedded in it. > > > > > - How can IPv4only client get the address of IPv6only client (or, it is > > impossible for IPv4only client to get IPv6 address of IPv6only client)? > > > > That's clearly more difficult, which is why the normal course of action > is for > > the IPv6 client to initiate the session. > [Dusan] What if IPv4only client needs to initiate the session to IPv6only > client? What is the solution for that use case? > Many firewall traversal solutions should work in this case, but IPv4 only client to client isn't guaranteed to work in all cases either. > > > > > - Do these IPv4 and IPv6 client addresses need to be pre-configured on > the > > translator and/or DNS64? > > > > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the > session, you'd > > have to have preconfigure something. > [Dusan] Where and how is this configuration done? > > > > > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --000000000000880540058d2e55e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 8, 2019 at 10:49 AM Mudri= c, Dusan (Dusan) <dmudric@avaya.com= > wrote:
= > -----Original Message-----
> From: Manfredi (US), Albert E <albert.e.manfredi@boeing.com>
>
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Mudric, Dusan (Dusan)
>
> > - How can DNS64 tell IPv6 only client the IP of IPv4 only client,= and vice
> versa?
>
> IPv6 to IPv4 should be straightforward, because it's a one-to-one<= br> > relationship. The other way around would normally not work,
[Dusan] There is no solution for IPv4only client to reach IPv6only client? =

I mostly say, so what! It is an unfort= unate reality of today's Internet, because of NAT44 and/or stateful fir= ewall default deny inbound policy, many times clients can't speak to ot= her clients, be they IPv4 only, IPv6 only, or even dual stack. Sometimes fi= rewall traversal technologies can work around this, also depending on the f= irewall traversal solution used sometimes IPv4 only and IPv6 only clients w= ill be able to talk to each other.=C2=A0 My guess is that IPv4 only to IPv6= only firewall traversal would be less effective than NAT44 client to NAT44= client firewall traversal, but it is should still be possible in some case= s.=C2=A0
=C2=A0
> but everyone
> has been accustomed to that with IPv4 NAPT already.
[Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed= not to be able to call IPv6only users (like Apple IPv6 only phones)?

They may not be able to talk peer to peer. H= owever, through a dual-stack SIP or other proxies/session border controller= , they could probably complete a call.=C2=A0
=C2=A0
>The client behind the
> NAPT initiates.
>
> > Is DNS64 server returning IPv4ony client address to IPv6only clie= nt, using
> the A RR?
>
> The DNS synthesizes the IPv6 address, which has the IPv4 address
> embedded in it.
>
> > - How can IPv4only client get the address of IPv6only client (or,= it is
> impossible for IPv4only client to get IPv6 address of IPv6only client)= ?
>
> That's clearly more difficult, which is why the normal course of a= ction is for
> the IPv6 client to initiate the session.
[Dusan] What if IPv4only client needs to initiate the session to IPv6only c= lient? What is the solution for that use case?

Many firewall traversal solutions should work in this case, but IPv= 4 only client to client isn't guaranteed to work in all cases either.= =C2=A0
=C2=A0
>
> > - Do these IPv4 and IPv6 client addresses need to be pre-configur= ed on the
> translator and/or DNS64?
>
> For IPv4 to IPv6, if you must allow the IPv4 client to initiate the se= ssion, you'd
> have to have preconfigure something.
[Dusan] Where and how is this configuration done?

>
> Bert

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


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0=C2=A0 E= mail:farmer@umn.edu
Networking & Telecommunication Services
O= ffice of Information Technology
University of Minnesota=C2=A0=C2=A0
= 2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Mi= nneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--000000000000880540058d2e55e7-- From nobody Mon Jul 8 10:05:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D553D120288; Mon, 8 Jul 2019 10:05:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 QN8GguAy-F-w; Mon, 8 Jul 2019 10:05:45 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 CE46212029B; Mon, 8 Jul 2019 10:05:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ENAAA1dyNd/wUHmMZlGwEBAQEDAQEBB?= =?us-ascii?q?wMBAQGBUwYBAQELAYFDUG1yAwQzCoQSg0cDhFKJeYJbl0aBLhSBEAMYPAkBAQE?= =?us-ascii?q?NASMKAgEBAoECgzwCF4IiIzQJDgEDAQEBBAEBAQEEAQICaYo3DIJ4TS8KAi8BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQIPJAUeAQEYAQE?= =?us-ascii?q?BAQMSEREMAQEsCwELBAIBCA0EBAEBAwImAgICMBUFAwgCBAENBQgRAgeDAYFqA?= =?us-ascii?q?x0BAgIKnzECgQgwiF8BAXCBMhoCgl0BAQV1hAgYghIJCQGBAigBhHGCfFSBf4E?= =?us-ascii?q?eF4FBPiZrRoJMPoJhBBiBCwkBEgEJGIMIMoImi3kIARwvgiOaeQZnCQKCF4ZWg?= =?us-ascii?q?UGHfoE8gk6CLG2GNAWDdAOKNYMliguHQIwVg2gCAgICBAUCDgEBBYFQOWdxcBU?= =?us-ascii?q?aIYJsCYI4N4FqgVCKU3KBKYsFgSIBgRULAQE?= X-IPAS-Result: =?us-ascii?q?A2ENAAA1dyNd/wUHmMZlGwEBAQEDAQEBBwMBAQGBUwYBAQE?= =?us-ascii?q?LAYFDUG1yAwQzCoQSg0cDhFKJeYJbl0aBLhSBEAMYPAkBAQENASMKAgEBAoECg?= =?us-ascii?q?zwCF4IiIzQJDgEDAQEBBAEBAQEEAQICaYo3DIJ4TS8KAi8BAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQIPJAUeAQEYAQEBAQMSEREMAQEsC?= =?us-ascii?q?wELBAIBCA0EBAEBAwImAgICMBUFAwgCBAENBQgRAgeDAYFqAx0BAgIKnzECgQg?= =?us-ascii?q?wiF8BAXCBMhoCgl0BAQV1hAgYghIJCQGBAigBhHGCfFSBf4EeF4FBPiZrRoJMP?= =?us-ascii?q?oJhBBiBCwkBEgEJGIMIMoImi3kIARwvgiOaeQZnCQKCF4ZWgUGHfoE8gk6CLG2?= =?us-ascii?q?GNAWDdAOKNYMliguHQIwVg2gCAgICBAUCDgEBBYFQOWdxcBUaIYJsCYI4N4Fqg?= =?us-ascii?q?VCKU3KBKYsFgSIBgRULAQE?= X-IronPort-AV: E=Sophos;i="5.63,466,1557201600"; d="scan'208";a="354786397" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Jul 2019 13:05:25 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2019 13:05:26 -0400 Received: from PWEXCVMAP02.global.avaya.com (135.11.85.81) by AZ-US1EXHC02.global.avaya.com (135.11.85.13) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 8 Jul 2019 13:05:24 -0400 Received: from PWEXCVMAP01.global.avaya.com (135.11.85.80) by PWEXCVMAP02.global.avaya.com (135.11.85.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Mon, 8 Jul 2019 13:05:24 -0400 Received: from PW365VMAP01.avaya.com (135.11.29.21) by PWEXCVMAP01.global.avaya.com (135.11.85.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1531.3 via Frontend Transport; Mon, 8 Jul 2019 13:05:24 -0400 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (104.47.50.54) by PW365VMAP01.avaya.com (135.11.29.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Mon, 8 Jul 2019 12:05:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qWZBVMXmKdAqewZLwGlRQcoG18MUbUPcITG6yY6fpGw=; b=Q72BmmY1yoBCI9XDuWXxdKXy5WYGSNMAsAf1n6v+eUrZPiDko7rZAm0IpePh0IcNk3icTI+aQhiZCh/Kkhitl//mtR4tyJFnJb/3mHfEjAfuOif0MgUVBv9dzcceMH3Pld1PXqfhJYqcDtOZ+jGNFiCESxnlstMTwZ2C6mqYXzQ= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2218.namprd15.prod.outlook.com (20.176.66.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.16; Mon, 8 Jul 2019 17:05:22 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 17:05:22 +0000 From: "Mudric, Dusan (Dusan)" To: JORDI PALET MARTINEZ , =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: =?utf-8?B?W3Y2b3BzXSAgw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0?= =?utf-8?Q?-ietf-v6ops-nat64-deployment-06:_(with_COMMENT)?= Thread-Index: AQHVNQqR9AuYKo+zy0GlsxLQOHlx1KbA88Uw Date: Mon, 8 Jul 2019 17:05:21 +0000 Message-ID: References: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com> <75A5EB61-3879-4F83-83BB-D65EE8799AF3@consulintel.es> In-Reply-To: <75A5EB61-3879-4F83-83BB-D65EE8799AF3@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93003c28-52a7-46ba-bbdc-08d703c67671 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2218; x-ms-traffictypediagnostic: DM6PR15MB2218: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(39860400002)(396003)(376002)(199004)(189003)(51444003)(13464003)(52536014)(53936002)(71200400001)(3846002)(71190400001)(186003)(110136005)(6116002)(76176011)(25786009)(55016002)(86362001)(7696005)(5024004)(30864003)(76116006)(53546011)(66476007)(102836004)(224303003)(6506007)(54906003)(256004)(99286004)(316002)(9686003)(14444005)(6306002)(966005)(446003)(26005)(8936002)(66574012)(305945005)(66066001)(4326008)(81166006)(7736002)(14454004)(55236004)(66946007)(68736007)(5660300002)(81156014)(6246003)(486006)(2906002)(73956011)(74316002)(33656002)(19627235002)(476003)(66446008)(11346002)(229853002)(66556008)(64756008)(478600001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2218; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jtZFxV+a+WWsbfHjgP2RTg8y8C/eo76JyPCQXwg7mLuT4YqN+whpPI6TPk/GKDsJhalDqjGcoNpvG6ZZpcbMmm6SDNTMcgWBkmdn3PV5ifulRVAk2X19T2w+RZ48qw2VPEcNl3H+94xmamVhb/5j5Zj+OgGi2C2E9IACh3mR1xnS2CApLobRwBFWrvN4Wx3K9E6q6rdMcecQyQkM2dHpZFtKjE+FRFZQ7abDGvrKLg0i7Jny3+NUlsXviHyjERysHFz+80xoszk90mF+NhBMKk/VN1fqK7a3csYzu3N35Tb+MsCyKU8I/CNeV3/qTxQcz+0BmyhdBKanZcoJrnOBjdckPkXThEOwtdb8U//uob4BkGvmSpkuKmgSgI44K9NrQbzMQ9w4y7pa8DpeNmdAo+h7o+zmNKcAAMNYx4CFjsw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 93003c28-52a7-46ba-bbdc-08d703c67671 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 17:05:21.9978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2218 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-nat64-deployment-06=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:05:56 -0000 U2VjdGlvbiAzLjM6DQoNCiJpZiB0aGUgbmV0d29yayBtdXN0DQogICBzdXBwb3J0IGFwcGxpY2F0 aW9ucyB1c2luZyBhbnkgb2YgdGhlIGZvbGxvd2luZzoNCg0KICAgbyAgSVB2NC1vbmx5IGhvc3Rz IG9yIGFwcGxpY2F0aW9ucw0KDQogICBUaGVuLCBvbmx5IHRoZSBzY2VuYXJpb3Mgd2l0aCA0NjRY TEFULCBhIENMQVQgZnVuY3Rpb24sIG9yIGVxdWl2YWxlbnQNCiAgIGJ1aWx0LWluIGxvY2FsIGFk ZHJlc3Mgc3ludGhlc2lzIGZlYXR1cmVzLCB3aWxsIHByb3ZpZGUgYSB2YWxpZA0KICAgc29sdXRp b24uIg0KDQpXaGljaCBkb2N1bWVudCBleHBsYWlucyBob3cgNDY0WExBVCBhbmQgYSBDTEFUIGZ1 bmN0aW9uIHByb3ZpZGUgY29ubmVjdGl2aXR5IGZyb20gSVB2NG9ubHktaG9zdCB0byBJUHY2b25s eS1ob3N0Pw0KDQpUaGFua3MsDQpEdXNhbi4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg Sk9SREkgUEFMRVQNCj4gTUFSVElORVoNCj4gU2VudDogU3VuZGF5LCBKdWx5IDcsIDIwMTkgNToy NCBQTQ0KPiBUbzogw4lyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT47IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPg0KPiBDYzogdjZvcHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdjZvcHMtbmF0 NjQtZGVwbG95bWVudEBpZXRmLm9yZzsgdjZvcHMtDQo+IGNoYWlyc0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3Y2b3BzXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0 Zi12Nm9wcy1uYXQ2NC0NCj4gZGVwbG95bWVudC0wNjogKHdpdGggQ09NTUVOVCkNCj4gDQo+IEhp IEVyaWMsDQo+IA0KPiBUaGFua3MgYSBsb3QgZm9yIHlvdXIgcmV2aWV3IQ0KPiANCj4gQ29tbWVu dHMgaW4tbGluZSBiZWxvdy4gTW9zdCBvZiB0aGVtIEkgd2lsbCByZXdvcmQgc29tZSB0ZXh0IG9y IGNvcnJlY3QNCj4gbml0cywgYnV0IHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBxdWVzdGlvbnMgZm9y IHlvdSB0byBjbGFyaWZ5Lg0KPiANCj4gUmVnYXJkcywNCj4gSm9yZGkNCj4gQGpvcmRpcGFsZXQN Cj4gDQo+IA0KPiANCj4g77u/RWwgNy83LzE5IDE0OjU5LCAidjZvcHMgZW4gbm9tYnJlIGRlIMOJ cmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIiIDx2Nm9wcy0NCj4gYm91bmNlc0BpZXRmLm9yZyBl biBub21icmUgZGUgbm9yZXBseUBpZXRmLm9yZz4gZXNjcmliacOzOg0KPiANCj4gICAgIMOJcmlj IFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4g ICAgIGRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZGVwbG95bWVudC0wNjogTm8gT2JqZWN0aW9uDQo+ IA0KPiAgICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ICAgICBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiAgICAgaW50cm9k dWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gICAgIFBsZWFzZSByZWZlciB0 byBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNB X193d3cuaWV0Zi5vcmdfaWVzZ19zdGF0ZW1lbnRfZGlzY3Vzcy0NCj4gMkRjcml0ZXJpYS5odG1s JmQ9RHdJR2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSg0KPiB4aGYz aUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09X0U5WnVmUUFJYzV3bFZMRFdLUEEyRHZXMHQN Cj4gcnZad1NEaDVTblQ4TE96ZGcmcz1Md1JYS1QxZC04U1M1UWlVYkhOcnAzM28zVEJBZUxxZ3M5 Uk4tDQo+IFV3QzBZZyZlPQ0KPiAgICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiAgICAgVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K PiAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0K PiAzQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRHY2b3BzLTJEbmF0 NjQtDQo+IDJEZGVwbG95bWVudF8mZD1Ed0lHYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9 VVQzQms5Y2JMZQ0KPiBhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1fRTladWZR QUljNXdsVkxEV0tQQTJEdlcNCj4gMHRydlp3U0RoNVNuVDhMT3pkZyZzPVBIVy0NCj4gYTg0N0Rn NjcwU3JsZnQ1NGV1SDg2bWZocHdjYU5pcXpjQlBTOHY0JmU9DQo+IA0KPiANCj4gDQo+ICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ICAgICBDT01NRU5UOg0KPiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4g ICAgIEhlbGxvIEpvcmRpLA0KPiANCj4gICAgIFRoYW5rIHlvdSAgZm9yIHRoZSB3b3JrIHB1dCBp bnRvIHRoaXMgY2xlYXIgYW5kIHdlbGwtd3JpdHRlbiBkb2N1bWVudC4NCj4gDQo+ICAgICBJIG9u bHkgd29uZGVyIHdoZXRoZXIgc2VjdGlvbiAzIGFuZCBzZWN0aW9uIDQgc2hvdWxkIGJlIHN3YXBw ZWQgZm9yIGENCj4gbW9yZQ0KPiAgICAgbG9naWNhbCBmbG93OiBleHBsYWluIHRoZSBpc3N1ZXMs IHRoZW4gZGVzY3JpYmUgd29ya2luZyBzb2x1dGlvbnMuIFByb2JhYmx5DQo+IHRvbw0KPiAgICAg bGF0ZSBpbiB0aGUgcHVibGljYXRpb24gdG8gY2hhbmdlIHRob3VnaC4NCj4gDQo+IEkgdGhpbmsg dGhhdCB3aWxsIGJlIGEgbWFqb3IgY2hhbmdlLCBiZWNhdXNlIEkndmUgYSBsb3Qgb2YgcmVmZXJl bmNlcyB0byB0aGUNCj4gInBvc3NpYmxlIiBkZXBsb3ltZW50IHNjZW5hcmlvcyB0byBleHBsYWlu IHRoZSBkaWZmZXJlbnQgaXNzdWVzLiBNeSAiZmxvdyINCj4gd2FzIHRoaW5raW5nIGluIGhvdyB5 b3UgY2FuIGRlcGxveSBpdCwgYW5kIHRoZW4gd2hhdCBhcmUgdGhlIGlzc3VlcyB0aGF0IHlvdQ0K PiBuZWVkIHRvIGNvbnNpZGVyLg0KPiANCj4gICAgIFRoZSB1bmRlcmx5aW5nIG1lc3NhZ2Ugb2Yg IjQ2NFhMQVQgc29sdmVzIGV2ZXJ5dGhpbmciIGlzIGFubm95aW5nIGJ1dCBJDQo+IG11c3QNCj4g ICAgIGFkbWl0IHRoYXQgdGhpcyBpcyB0cnVlIDstKQ0KPiANCj4gVGhpcyBkb2N1bWVudCBzdGFy dGVkIGFzIDQ2NFhMQVQgZGVwbG95bWVudCBndWlkZWxpbmVzLCBhbmQgdGhlIFdHIGFza2VkDQo+ IG1lIHRvIHR1cm4gaXQgYWxzbyB0byAiTkFUNjQiLiBJIHRoaW5rIHRoYXQgZXhwbGFpbnMgaXQs IGJ1dCBpbiBhbnkgY2FzZSwgYXMgeW91DQo+IHdlbGwgc2F5LCBpdCBpcyB0cnVlIC4uLiBhbmQg dGhlcmUgaXMgZXhwbGljaXQgdGV4dCB0byBpbmRpY2F0ZSB0aGF0IGlmIHlvdSdyZSBzdXJlDQo+ IHRoYXQgZXZlcnl0aGluZyBpbnNpZGUgdGhlIG5ldHdvcmsgaXMgc3VwcG9ydGluZyBJUHY2LCBu byBsaXRlcmFscywgZXRjLiwgdGhlbiBpdA0KPiBtYXkgYmUgZmluZSB3aXRoIGp1c3QgTkFUNjQu IEhvd2V2ZXIgd2UgYWxsIGtub3cgdGhhdCB0aGlzIGlzIGEgbm9uLXJlYWxpc3RpYw0KPiBzY2Vu YXJpby4NCj4gDQo+ICAgICBQbGVhc2UgZmluZCBiZWxvdyBtYW55IENPTU1FTlRzIGluIHRoZSBo b3BlIG9mIGltcHJvdmluZyB0aGUNCj4gcmVhZGFiaWxpdHkgYW5kDQo+ICAgICBmYWN0dWFsIGRh dGEgcG9pbnRzIGluIHRoZSBkb2N1bWVudC4NCj4gDQo+ICAgICAtw6lyaWMNCj4gDQo+ICAgICA9 PSBDT01NRU5UUyA9PQ0KPiANCj4gICAgIElzIHRoZXJlIGEgZGVzY3JpcHRpb24gb2YgdGhlIHVz ZSBvZiBETlM2NCBpbiB0aGUgaG9zdCBhcyBpdCBmaXhlcyB0aGUgRE5TU0VDDQo+ICAgICBpc3N1 ZXMgPyAoZXhjZXB0IGluIHNlY3Rpb24gMy4yLjIuKQ0KPiANCj4gTm90IHN1cmUgdG8gY29tcGxl dGVseSB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gaGVyZSwganVzdCB0cnlpbmcgLi4uIFRoaXMg aXMNCj4gbm90IHNvbWV0aGluZyB0aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGNhbiBzb2x2ZSwg YXMgaXQgaXMgdXAgdG8gdGhlIE9TIChmb3IgYWxsDQo+IHRoZSBkZXZpY2VzIGluIHRoYXQgbmV0 d29yaykuIFRoYXQncyB3aHkgSSB0aGluayBpcyBub3Qgc29tZXRoaW5nIGZvciB0aGlzDQo+IGRv Y3VtZW50LiBIb3dldmVyLCBJIGp1c3QgcmVhbGl6ZWQgdGhhdCB0aGlzIGlzIGRlc2NyaWJlZCBp biBzZWN0aW9uIDcuMiBvZg0KPiBSRkM2MTQ3LiBJIGNhbiBhZGQgYSByZWZlcmVuY2UgdG8gdGhh dCBpbiBzZWN0aW9uIDMuMi4yLg0KPiANCj4gICAgIC0tIFNlY3Rpb24gMy4xIC0tDQo+IA0KPiAg ICAgImtub3duIHRvIHdvcmsiOiBjYW4geW91IGFkZCByZWZlcmVuY2VzIG9yIGRhdGEgYmFja2lu ZyB0aGlzIHN0YXRlbWVudCA/DQo+IA0KPiBXZWxsLCB0aG9zZSBhcmUgdGhlIG1vZGVscyBiZWlu ZyB1c2VkIHRvZGF5IGluIGNlbGx1bGFyIGFuZCBicm9hZGJhbmQNCj4gbmV0d29ya3MuIFNvIEkg Y2FuIGp1c3Qgc2F5IHRoYXQ/DQo+IA0KPiAgICAgLS0gU2VjdGlvbiAzLjEuMSAtLQ0KPiANCj4g ICAgIFdoZW4gZGlzY3Vzc2luZyBzY2VuYXJpaSwgcGxlYXNlIHJlZmVyIHRvIHRoZSBmaWd1cmUg SUQgaW4gdGhlIHRleHQgZm9yIGNsYXJpdHkuDQo+IA0KPiBEb25lIChJJ20gYWxyZWFkeSBlZGl0 aW5nIGEgbmV3IHZlcnNpb24gd2hpbGUgd3JpdGluZyB0aGlzLCBwZW5kaW5nIG9uIHNvbWUNCj4g dGhhdCB5b3UgY2FuIHByb3ZpZGUgdG8gbXkgY29tbWVudHMpLg0KPiANCj4gICAgIC0tIFNlY3Rp b24gMy4xLjIgLS0NCj4gDQo+ICAgICBJdCBpcyB1bmNsZWFyIHRvIG1lIHdoZXRoZXIgIlRoZSBz dXBwb3J0IG9mIHRoaXMgc2NlbmFyaW8iIHJlZmVycyB0byB0aGUNCj4gICAgIFVFLW9ubHkgb3Ig dGhlIENQRSBkZXBsb3ltZW50Lg0KPiANCj4gSXQgaXMgcmVmZXJyaW5nIHRvIHRoZSAic2Vydmlj ZSBwcm92aWRlciBuZXR3b3JrIHN1cHBvcnQiLiBXaWxsIGNsYXJpZnkgaXQuDQo+IA0KPiAgICAg U2FtZSBkZW1hbmQgYXMgYWJvdmU6IHBsZWFzZSByZWZlciB0byB0aGUgZmlndXJlIElEIGluIHRo ZSB0ZXh0IGZvciBjbGFyaXR5Lg0KPiANCj4gRG9uZSENCj4gDQo+ICAgICAtLSBTZWN0aW8gMy4y LjEgLS0NCj4gDQo+ICAgICBJIHJlYWxseSB3b25kZXIgd2hldGhlciBpdCBpcyB1c2VmdWwgdG8g ZGVzY3JpYmUgdGhpcyBzY2VuYXJpbyBhcyAnd29ya2luZw0KPiAgICAgdW5kZXIgc3BlY2lhbCBj b25kaXRpb25zJy4uLiB0aG9zZSAnc3BlY2lhbCBjb25kaXRpb25zJyB3aWxsIHByb2JhYmx5IG5l dmVyDQo+IG1ldA0KPiAgICAgaW4gcmVhbCBsaWZlLg0KPiANCj4gICAgIE1vcmUgZ2VuZXJhbGx5 LCBJIGFtIHVuc3VyZSBhYm91dCB0aGUgdmFsdWUgb2YgdGhlIHdob2xlIHNlY3Rpb24gMy4yIChp dCBpcw0KPiAgICAgbW9yZSBsaWtlIGFuIGFjYWRlbWljIHRoaW5nKS4NCj4gDQo+IEkgdGhpbmsg c29tZSBvZiB0aG9zZSBzY2VuYXJpb3MgYXJlIHBvc3NpYmxlIGluIHNvbWUgbmV0d29ya3MsIG1h eSBiZSBub3QNCj4gY29ubmVjdGluZyB0byBJbnRlcm5ldCwgb3IgZm9yIGV4YW1wbGUsIHlvdSBt YXkgd2FudCB0byBjb25maWd1cmUgZXhwbGljaXQNCj4gbWFwcGluZ3MsIHdoaWNoIGNhbiBiZSBk b25lIHdpdGggRUFNLiBJIGp1c3QgcmVhbGl6ZWQgdGhhdCBJJ3ZlIG5vdCBjaXRlZA0KPiB0aGF0 LiBJIHdpbGwgZG8uDQo+IA0KPiAgICAgLS0gU2VjdGlvbiA0LjEuMS4gLS0NCj4gDQo+ICAgICBD YW4geW91IGFkZCByZWZlcmVuY2UgYW5kL29yIGRhdGEgZm9yICJtb25pdG9yZWQgYnkgc29tZSBn b3Zlcm5tZW50YWwNCj4gYm9kaWVzDQo+ICAgICBhbmQgb3RoZXIgaW5zdGl0dXRpb25zIi4NCj4g DQo+IEkgYmVsaWV2ZSB0aGF0IHdhcyBwb2ludGVkIG91dCBieSBzb21lYm9keSBpbiB0aGUgV0cs IGJ1dCBpdCBpcyB0cnVlIHRoYXQNCj4gc29tZSByZWd1bGF0b3JzIGRvIHRoYXQuIEkgcmVjYWxs IGhhdmluZyBzZWVuIHNvbWV0aGluZyBhYm91dCB0aGF0IGluIEZyYW5jZSwNCj4gYnV0IEknbSBu b3QgMTAwJSBzdXJlIHJpZ2h0IG5vdy4NCj4gDQo+ICAgICBQbGVhc2UgYWRkIGEgcmVmZXJlbmNl IGZvciB0aGUgdXNlIG9mICJpcHY0b25seS5hcnBhIi4gQUZBSUsNCj4gDQo+IFJpZ2h0LCB0aGlz IGlzIGRlZmluZWQgYnkgUkZDNzA1MCwgZG9uZSENCj4gDQo+ICAgICBkcmFmdC1jaGVzaGlyZS1z dWRuLWlwdjRvbmx5LWRvdC1hcnBhIGFwcGVhcnMgdG8gYmUgZG9ybWFudC9kZWFkLg0KPiANCj4g VGhpcyBpcyBvbmUgb2YgdGhlIGlzc3VlcyB0aGF0IEkndmUgY29tbWVudGVkIHdpdGggV2FycmVu LCByZXNwb25kaW5nIHRvDQo+IElBTkEuIEkgdW5kZXJzdGFuZCBoZSBpcyBzcG9uc29yaW5nIHRo YXQgZG9jdW1lbnQuDQo+IA0KPiANCj4gICAgIC0tIFNlY3Rpb24gNC4xLjIgLS0NCj4gDQo+ICAg ICBUaGUgbGVhZGluZyBwYXJhZ3JhcGggaXMgYSBsaXR0bGUgY29uZnVzaW5nIGFzIGl0IGFzc3Vt ZWQgdGhhdCBDTEFUIGV4aXN0cw0KPiAgICAgKHN0YXRlZCBpbiB0aGUgdGV4dCBidXQgbm90IGlu IHRoZSBzZWN0aW9uIHRpdGxlKS4NCj4gDQo+IFdpbGwgY2xhcmlmeSBpdC4NCj4gDQo+ICAgICAt LSBTZWN0aW9uIDQuMS41IC0tDQo+IA0KPiAgICAgVGhlIHNlY3Rpb24gdGl0bGUgaXMgcmF0aGVy IG1pc2xlYWRpbmcgIkFDTCBvZiBjbGllbnRzIiBhbmQgSSB3b25kZXIgd2h5IGENCj4gICAgIGR1 YWwtc3RhY2sgY2xpZW50IHdvdWxkIHVzZSBhIEROUzY0IHNlcnZlciBhcyBpdHMgcmVjdXJzaXZl IEROUyBzZXJ2ZXIuIElzbid0DQo+ICAgICBpdCBhbiBvYnZpb3VzIGNvbmZpZ3VyYXRpb24gbWlz dGFrZT8NCj4gDQo+IE5vLCBJIHRoaW5rIHRoYXQgdGV4dCBpcyBjb3JyZWN0LCBidXQgSSB3aWxs IHRyeSB0byByZXdvcmQgaXQgdG8gbWFrZSBpdCBjbGVhcmVyLiBZb3UNCj4gbWF5IGhhdmUgYSBz aXR1YXRpb24gd2l0aCBJUHY0LW9ubHkgc2VydmVycywgd2hpY2ggYXJlIGxvY2F0ZWQsIGluIHRo ZSBwYXRoDQo+IGJldHdlZW4gdGhlIGR1YWwtc3RhY2sgaG9zdHMgYW5kIHRoZSBOQVQ2NC4gU28s IGlmIHRoZSBETlM2NCBpcyBub3QNCj4gY29uZmlndXJlZCB0byBleGNsdWRlIHRob3NlIHNlcnZl cnMsIGl0IHdpbGwgc3ludGhldGl6ZSB0aGUgQUFBQSByZWNvcmRzIGFuZA0KPiB0aGV5IHdpbGwg YmVjb21lIHVucmVhY2hhYmxlLiBTbyB0aGF0J3Mgd2h5IGJpbmQgYW5kIG90aGVyIEROUzY0IHNl cnZlcnMNCj4gcHJvdmlkZSB0aGlzIEFDTCBmdW5jdGlvbi4NCj4gDQo+ICAgICAtLSBTZWN0aW9u IDQuNC4xIC0tDQo+IA0KPiAgICAgU29tZSBleHBsYW5hdGlvbnMgb2YgdGhlIGNvbnNlcXVlbmNl cyBvZiBhIGZvcmVpZ24gRE5TIHdvdWxkIGJlDQo+IHdlbGNvbWUuDQo+IA0KPiBEb25lIQ0KPiAN Cj4gICAgIC0tIFNlY3Rpb24gNC40LjIgLS0NCj4gDQo+ICAgICBSYXRoZXIgdGhhbiB1c2luZyAi RE5TIHByaXZhY3kiIHBsZWFzZSB1c2UgIkROUyByZXF1ZXN0IGNvbmZpZGVudGlhbGl0eSINCj4g YXMgdGhlDQo+ICAgICBETlM2NCB3aWxsIGxlYXJuL2dsZWFuIGFib3V0IHRoZSBjbGllbnQgYWN0 aXZpdGllcy4NCj4gDQo+IEkgdXNlZCB0aGlzIHRlcm1pbm9sb2d5IGFzIGl0IHdhcyBzdWdnZXN0 ZWQgYXMgdGhlIGNvbW1vbiBvbmUgZm9yIHRoZQ0KPiBkaWZmZXJlbnQgcHJvdG9jb2xzIGluIHRo aXMgY2F0ZWdvcnkuIEkgd2lsbCB0cnkgdG8gY29uZmlybSBpZiBpcyB0aGUgcmlnaHQgb25lIGp1 c3QNCj4gaW4gY2FzZS4gTWF5IGJlIHJld29yZGluZyB0aGUgdGl0bGUgYXMgIkROUyBQcml2YWN5 L0VuY3J5cHRpb24gTWVjaGFuaXNtcyINCj4gPw0KPiANCj4gDQo+IA0KPiAgICAgLS0gU2VjdGlv biA0LjYgLS0NCj4gDQo+ICAgICBQbGVhc2UgZXhwbGFpbiB3aHkgb2xkZXIgQVBJIGlzIGEgcHJv YmxlbSAob3IgcmF0aGVyIHJlcGhyYXNlIGl0IGludG8NCj4gICAgIGFwcGxpY2F0aW9ucyB1c2lu ZyBJUHY0LW9ubHkgQVBJKS4NCj4gDQo+IERvbmUhDQo+IA0KPiAgICAgLS0gU2VjdGlvbiA0LjEw IC0tDQo+IA0KPiAgICAgZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMgaXMgYWxzbyBhYmxlIHRvIHN1 cHBvcnQgSVB2Ni1vbmx5IGNsaWVudC4gSXQgaXMNCj4gICAgIGN1cnJlbnRseSBpbiB0aGUgc2Ft ZSBJRVNHIHN0YXR1cyBhcyB0aGlzIGRvY3VtZW50Lg0KPiANCj4gRGVmaW5pdGl2ZWx5LCB3aWxs IGFkZCBhIHJlZmVyZW5jZSB0byBpdCENCj4gDQo+ICAgICAtLSBTZWN0aW9uIDUgLS0NCj4gDQo+ ICAgICBQbGVhc2UgYWRkIGRhdGEvcmVmZXJlbmNlcyBmb3IgIndpdGggaHVuZHJlZHMgb2YgbWls bGlvbnMgb2YgdXNlcnMiDQo+IA0KPiBJIGNhbiBjaXRlIHNldmVyYWwgY2VsbHVsYXIgbmV0d29y a3MsIGJ1dCBJIHdpbGwgZG8gaW4gYSBnZW5lcmljIHdheSwgSSBkb24ndCB0aGluaw0KPiB3ZSBz aG91bGQgbWVudGlvbiBleHBsaWNpdCBwcm92aWRlcnMsIHJpZ2h0Py4NCj4gDQo+ICAgICAtLSBT ZWN0aW9uIDcgLS0NCj4gDQo+ICAgICBOb3Qgc28gbXVjaCBhYm91dCBzZWN1cml0eSBidXQgYWJv dXQgcHJpdmFjeS4gSSB3b3VsZCBhcHByZWNpYXRlIHRvIGhhdmUNCj4gc29tZQ0KPiAgICAgdGV4 dCBhcm91bmQgdGhlIGxhY2sgb2YgcHJpdmFjeSB3aGVuIHVzaW5nIGFuIGV4dGVybmFsIEROUzY0 IGFzIHRoaXMgc2VydmVyDQo+ICAgICB3aWxsIGxlYXJuIGFib3V0IGFsbCBjbGllbnRzIGFjdGl2 aXRpZXMuDQo+IA0KPiBHb29kIHBvaW50LCB0aGFua3MuIFdpbGwgZG8hDQo+IA0KPiAgICAgPT0g TklUUyA9PQ0KPiANCj4gICAgIEdlbmVyYWxseSwgcGxlYXNlIHJlZnJhaW4gZnJvbSB1c2luZyAi SEV2MiIgaW4gcGxhY2Ugb2YgIkhhcHB5IEV5ZWJhbGwNCj4gdmVyc2lvbg0KPiAgICAgMiIuDQo+ IA0KPiBEb25lIQ0KPiANCj4gICAgIC0tIFNlY3Rpb24gMy4xLjEuIC0tDQo+IA0KPiAgICAgRmln dXJlIDEgc2hvd3MgYSBib3ggY29udGFpbmluZyBib3RoIE5BVDY0IGFuZCBETlM2NCB3aGlsZSB0 aG9zZQ0KPiBmdW5jdGlvbnMNCj4gICAgIGNvdWxkIHJlc2lkZSBpbiBkaWZmZXJlbnQgZGV2aWNl cy4NCj4gDQo+IFdpbGwgY2xhcmlmeSBpdC4NCj4gDQo+ICAgICBzL09uZSBtb3JlIGVxdWl2YWxl bnQgc2NlbmFyaW8vT25lIGFkZGl0aW9uYWwgZXF1aXZhbGVudCBzY2VuYXJpby8gPw0KPiANCj4g RG9uZSENCj4gDQo+ICAgICAtLSBTZWN0aW9uIDQuMSAtLQ0KPiANCj4gICAgIHMvdG8gYW4gSVB2 Ni1vbmx5IFdBTi90byBhbiBJUHY2LW9ubHkgYWNjZXNzIG5ldHdvcmsvDQo+IA0KPiBEb25lIQ0K PiANCj4gDQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+ICAgICB2Nm9wc0BpZXRmLm9yZw0KPiAg ICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAz QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lHYVEmYz1CRnBXUXc4 YnN1S3ANCj4gbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5 c01RR1Eya1kmbT1fRTkNCj4gWnVmUUFJYzV3bFZMRFdLUEEyRHZXMHRydlp3U0RoNVNuVDhMT3pk ZyZzPXdPUFd6bElqbm9xWVhSME9NDQo+IGJsNWRKc3dybm5NbW1UWDJ5bU9tbUowUmZvJmU9DQo+ IA0KPiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVy bmV0ID8NCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt DQo+IDNBX193d3cudGhlaXB2NmNvbXBhbnkuY29tJmQ9RHdJR2FRJmM9QkZwV1F3OGJzdUtwbDFT Z2laSDY0DQo+IFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZ Jm09X0U5WnVmUUFJYzUNCj4gd2xWTERXS1BBMkR2VzB0cnZad1NEaDVTblQ4TE96ZGcmcz1ESnB4 c2M1MTQtDQo+IHpjZkJBRlM0a3NVTzFBel9MekxLbzFEYTgwdUlnNjBKQSZlPQ0KPiBUaGUgSVB2 NiBDb21wYW55DQo+IA0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1h dGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvcg0KPiBjb25maWRlbnRpYWwuIFRoZSBpbmZv cm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQo+ IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0 aG9yaXplZCBkaXNjbG9zdXJlLA0KPiBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRo ZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmDQo+IHBhcnRpYWxseSwgaW5j bHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJl IGNvbnNpZGVyZWQgYQ0KPiBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55DQo+IGRpc2Nsb3N1cmUsIGNvcHlpbmcs IGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24s DQo+IGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQsIHdpbGwgYmUNCj4gY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2Us IHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8NCj4gaW5mb3JtIGFi b3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiANCj4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWls aW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fdjZvcHMmZD1Ed0lHYVEmYz1CRnBXUXc4YnN1S3ANCj4gbDFTZ2laSDY0USZyPVVUM0JrOWNi TGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1fRTkNCj4gWnVmUUFJYzV3bFZM RFdLUEEyRHZXMHRydlp3U0RoNVNuVDhMT3pkZyZzPXdPUFd6bElqbm9xWVhSME9NDQo+IGJsNWRK c3dybm5NbW1UWDJ5bU9tbUowUmZvJmU9DQo= From nobody Mon Jul 8 10:25:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AF71203EB; Mon, 8 Jul 2019 10:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 oXZQ8Us7aQTX; Mon, 8 Jul 2019 10:24:48 -0700 (PDT) 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 CF18F1203C5; Mon, 8 Jul 2019 10:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562606646; x=1563211446; 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=Nt6XV1qyB9XzXg0dCfPrmJgvU+p+WS2K9ljYS+9JQJE=; b=I0uvUnAwmVXWr Xy+rDeD5Ki9jZdZKtYWyPtRNEWftHGJeNOne1CYsj4irEkQerajlZOUpo7qskihG Dymg57G5tZs1j2uBS3OpUDA9m/MvPqwY+S3dRGy3ECBVYVHfm470bHKqZL4ZpEz+ Xi1t3ZqtGjTBPNvSiPTaWzFstj90z0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 08 Jul 2019 19:24:06 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 08 Jul 2019 19:24:05 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006319363.msg; Mon, 08 Jul 2019 19:24:03 +0200 X-MDRemoteIP: 2001:470:1f09:495:6c21:37a5:3c84:e5e9 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Mon, 08 Jul 2019 19:24:03 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1092a35ad6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Mon, 08 Jul 2019 19:24:00 +0200 From: JORDI PALET MARTINEZ To: "Mudric, Dusan (Dusan)" , JORDI PALET MARTINEZ , =?UTF-8?B?w4lyaWM=?= Vyncke , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Message-ID: Thread-Topic: [v6ops] =?UTF-8?B?w4lyaWM=?= Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT) References: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com> <75A5EB61-3879-4F83-83BB-D65EE8799AF3@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-nat64-deployment-06=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:25:00 -0000 Hi Dusan, I think you're reading it wrong. This document is about guidelines for deployment of an existing transition = mechanism: NAT64 (and a derivate of it, 464XLAT). NAT64 was designed as a solution for IPv6-only hosts, connected to an IPv6-= only access network, to access IPv4-only services (as well as dual-stack on= es). 464XLAT also provides a solution for IPv4-only hosts, connected to an IPv6-= only access network, to access IPv4-only services (as well as dual-stack on= es). So, the *actual* implementation of 464XLAT/NAT64 doesn't allow IPv4-only ho= sts to connect to IPv6-only hosts. *However*, you may be interested in reading this optimization that may solv= e the problem: https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?= include_text=3D1 Note that this is work-in-progress, and if you wait to the end of the day, = you will get a *much better* version of this document. This will solve the = problem that you mention if 464XLAT is used. I will send a notification in the list when I submit the next version, it i= s taking many more hours than I expected ... Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 8/7/19 19:08, "v6ops en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: Section 3.3: =20 "if the network must support applications using any of the following: =20 o IPv4-only hosts or applications =20 Then, only the scenarios with 464XLAT, a CLAT function, or equivalen= t built-in local address synthesis features, will provide a valid solution." =20 Which document explains how 464XLAT and a CLAT function provide connect= ivity from IPv4only-host to IPv6only-host? =20 Thanks, Dusan. =20 =20 > -----Original Message----- > From: v6ops On Behalf Of JORDI PALET > MARTINEZ > Sent: Sunday, July 7, 2019 5:24 PM > To: =C3=89ric Vyncke ; The IESG > Cc: v6ops@ietf.org; draft-ietf-v6ops-nat64-deployment@ietf.org; v6ops= - > chairs@ietf.org > Subject: Re: [v6ops] =C3=89ric Vyncke's No Objection on draft-ietf-v6= ops-nat64- > deployment-06: (with COMMENT) >=20 > Hi Eric, >=20 > Thanks a lot for your review! >=20 > Comments in-line below. Most of them I will reword some text or corre= ct > nits, but there are a couple of questions for you to clarify. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 > =EF=BB=BFEl 7/7/19 14:59, "v6ops en nombre de =C3=89ric Vyncke via Da= tatracker" bounces@ietf.org en nombre de noreply@ietf.org> escribi=C3=B3: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-v6ops-nat64-deployment-06: No Objection >=20 > When responding, please keep the subject line intact and reply to= all > email addresses included in the To and CC lines. (Feel free to cu= t this > introductory paragraph, however.) >=20 >=20 > Please refer to https://urldefense.proofpoint.com/v2/url?u=3Dhttp= s- > 3A__www.ietf.org_iesg_statement_discuss- > 2Dcriteria.html&d=3DDwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLea= J > xhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E9ZufQAIc5wlVLDWKPA2DvW0t > rvZwSDh5SnT8LOzdg&s=3DLwRXKT1d-8SS5QiUbHNrp33o3TBAeLqgs9RN- > UwC0Yg&e=3D > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found her= e: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnat64- > 2Ddeployment_&d=3DDwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLe > aJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E9ZufQAIc5wlVLDWKPA2DvW > 0trvZwSDh5SnT8LOzdg&s=3DPHW- > a847Dg670Srlft54euH86mfhpwcaNiqzcBPS8v4&e=3D >=20 >=20 >=20 > -----------------------------------------------------------------= ----- > COMMENT: > -----------------------------------------------------------------= ----- >=20 > Hello Jordi, >=20 > Thank you for the work put into this clear and well-written docu= ment. >=20 > I only wonder whether section 3 and section 4 should be swapped f= or a > more > logical flow: explain the issues, then describe working solutions= . Probably > too > late in the publication to change though. >=20 > I think that will be a major change, because I've a lot of references= to the > "possible" deployment scenarios to explain the different issues. My "= flow" > was thinking in how you can deploy it, and then what are the issues t= hat you > need to consider. >=20 > The underlying message of "464XLAT solves everything" is annoying= but I > must > admit that this is true ;-) >=20 > This document started as 464XLAT deployment guidelines, and the WG as= ked > me to turn it also to "NAT64". I think that explains it, but in any c= ase, as you > well say, it is true ... and there is explicit text to indicate that = if you're sure > that everything inside the network is supporting IPv6, no literals, e= tc., then it > may be fine with just NAT64. However we all know that this is a non-r= ealistic > scenario. >=20 > Please find below many COMMENTs in the hope of improving the > readability and > factual data points in the document. >=20 > -=C3=A9ric >=20 > =3D=3D COMMENTS =3D=3D >=20 > Is there a description of the use of DNS64 in the host as it fixe= s the DNSSEC > issues ? (except in section 3.2.2.) >=20 > Not sure to completely understand what you mean here, just trying ...= This is > not something that the service provider can solve, as it is up to the= OS (for all > the devices in that network). That's why I think is not something for= this > document. However, I just realized that this is described in section = 7.2 of > RFC6147. I can add a reference to that in section 3.2.2. >=20 > -- Section 3.1 -- >=20 > "known to work": can you add references or data backing this stat= ement ? >=20 > Well, those are the models being used today in cellular and broadband > networks. So I can just say that? >=20 > -- Section 3.1.1 -- >=20 > When discussing scenarii, please refer to the figure ID in the te= xt for clarity. >=20 > Done (I'm already editing a new version while writing this, pending o= n some > that you can provide to my comments). >=20 > -- Section 3.1.2 -- >=20 > It is unclear to me whether "The support of this scenario" refers= to the > UE-only or the CPE deployment. >=20 > It is referring to the "service provider network support". Will clari= fy it. >=20 > Same demand as above: please refer to the figure ID in the text f= or clarity. >=20 > Done! >=20 > -- Sectio 3.2.1 -- >=20 > I really wonder whether it is useful to describe this scenario as= 'working > under special conditions'... those 'special conditions' will prob= ably never > met > in real life. >=20 > More generally, I am unsure about the value of the whole section = 3.2 (it is > more like an academic thing). >=20 > I think some of those scenarios are possible in some networks, may be= not > connecting to Internet, or for example, you may want to configure exp= licit > mappings, which can be done with EAM. I just realized that I've not c= ited > that. I will do. >=20 > -- Section 4.1.1. -- >=20 > Can you add reference and/or data for "monitored by some governme= ntal > bodies > and other institutions". >=20 > I believe that was pointed out by somebody in the WG, but it is true = that > some regulators do that. I recall having seen something about that in= France, > but I'm not 100% sure right now. >=20 > Please add a reference for the use of "ipv4only.arpa". AFAIK >=20 > Right, this is defined by RFC7050, done! >=20 > draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead. >=20 > This is one of the issues that I've commented with Warren, responding= to > IANA. I understand he is sponsoring that document. >=20 >=20 > -- Section 4.1.2 -- >=20 > The leading paragraph is a little confusing as it assumed that CL= AT exists > (stated in the text but not in the section title). >=20 > Will clarify it. >=20 > -- Section 4.1.5 -- >=20 > The section title is rather misleading "ACL of clients" and I won= der why a > dual-stack client would use a DNS64 server as its recursive DNS s= erver. Isn't > it an obvious configuration mistake? >=20 > No, I think that text is correct, but I will try to reword it to make= it clearer. You > may have a situation with IPv4-only servers, which are located, in th= e path > between the dual-stack hosts and the NAT64. So, if the DNS64 is not > configured to exclude those servers, it will synthetize the AAAA reco= rds and > they will become unreachable. So that's why bind and other DNS64 serv= ers > provide this ACL function. >=20 > -- Section 4.4.1 -- >=20 > Some explanations of the consequences of a foreign DNS would be > welcome. >=20 > Done! >=20 > -- Section 4.4.2 -- >=20 > Rather than using "DNS privacy" please use "DNS request confident= iality" > as the > DNS64 will learn/glean about the client activities. >=20 > I used this terminology as it was suggested as the common one for the > different protocols in this category. I will try to confirm if is the= right one just > in case. May be rewording the title as "DNS Privacy/Encryption Mechan= isms" > ? >=20 >=20 >=20 > -- Section 4.6 -- >=20 > Please explain why older API is a problem (or rather rephrase it = into > applications using IPv4-only API). >=20 > Done! >=20 > -- Section 4.10 -- >=20 > draft-ietf-tram-turnbis is also able to support IPv6-only client.= It is > currently in the same IESG status as this document. >=20 > Definitively, will add a reference to it! >=20 > -- Section 5 -- >=20 > Please add data/references for "with hundreds of millions of user= s" >=20 > I can cite several cellular networks, but I will do in a generic way,= I don't think > we should mention explicit providers, right?. >=20 > -- Section 7 -- >=20 > Not so much about security but about privacy. I would appreciate = to have > some > text around the lack of privacy when using an external DNS64 as t= his server > will learn about all clients activities. >=20 > Good point, thanks. Will do! >=20 > =3D=3D NITS =3D=3D >=20 > Generally, please refrain from using "HEv2" in place of "Happy Ey= eball > version > 2". >=20 > Done! >=20 > -- Section 3.1.1. -- >=20 > Figure 1 shows a box containing both NAT64 and DNS64 while those > functions > could reside in different devices. >=20 > Will clarify it. >=20 > s/One more equivalent scenario/One additional equivalent scenario= / ? >=20 > Done! >=20 > -- Section 4.1 -- >=20 > s/to an IPv6-only WAN/to an IPv6-only access network/ >=20 > Done! >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DBFpWQw8bsuKp > l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E9 > ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=3DwOPWzlIjnoqYXR0OM > bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=3D >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.theipv6company.com&d=3DDwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64 > Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E9ZufQAIc5 > wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=3DDJpxsc514- > zcfBAFS4ksUO1Az_LzLKo1Da80uIg60JA&e=3D > The IPv6 Company >=20 > 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 discl= osure, > copying, distribution or use of the contents of this information, eve= n 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 info= rmation, > even if partially, including attached files, is strictly prohibited, = will be > considered a criminal offense, so you must reply to the original send= er to > inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DBFpWQw8bsuKp > l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E9 > ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=3DwOPWzlIjnoqYXR0OM > bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=3D _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Jul 8 10:32:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB08C12006B; Mon, 8 Jul 2019 10:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 IMMP3-W6wrM1; Mon, 8 Jul 2019 10:32:18 -0700 (PDT) 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 A41FF1203DB; Mon, 8 Jul 2019 10:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562607135; x=1563211935; 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=zs+KaNEyHSv3AUh4kPcxBez3BM5yVKPDUpd86bec9tg=; b=mlYiniXWbfX01 UrODOgjY5K2j4sQkg5Hg1tMG9A7bmA8KKkY52hFndbxkwQAgSKYoEerEfbe3D7wz S1E+GIlXS/4EWIYSzBNbLN3vvEqpksVlppyWuhZCvr+SkffPwTQjWLm/KqLVbPXQ KijABzke9jN394KSfq++eiwhqIkqmo= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 08 Jul 2019 19:32:15 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 08 Jul 2019 19:32:14 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006319377.msg; Mon, 08 Jul 2019 19:32:13 +0200 X-MDRemoteIP: 2001:470:1f09:495:6c21:37a5:3c84:e5e9 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Mon, 08 Jul 2019 19:32:13 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1092a35ad6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Mon, 08 Jul 2019 19:32:09 +0200 From: JORDI PALET MARTINEZ To: "Mudric, Dusan (Dusan)" , JORDI PALET MARTINEZ , =?UTF-8?B?w4lyaWM=?= Vyncke , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Message-ID: <0E1C5A74-986C-4F4B-8F52-C0FEE69D6C3E@consulintel.es> Thread-Topic: [v6ops] =?UTF-8?B?w4lyaWM=?= Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT) References: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com> <75A5EB61-3879-4F83-83BB-D65EE8799AF3@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-nat64-deployment-06=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:32:30 -0000 By the way, when you read this: As a general conclusion, we should note that, if the network must support applications using any of the following: o IPv4 literals o non-IPv6-compliant APIs o IPv4-only hosts or applications You can't take it out of the context of the document. I think this is where= you are getting confused. "if the network", because the context of the com= plete document, is referring to the user LANs in and operator or enterprise= IPv6-only access network, supporting 464XLAT (NAT64 doesn't solve all thos= e problems), but again, in the context of destinations which are IPv4-only = or dual-stack, but not "IPv6-only". We will come to that when we reactivate sunset4 WG, and we decide to recomm= end that IPv4 is historic, and must be disabled in all the networks ... but= that's another history! Meanwhile, if you want a "service" to be reachable= by everyone, you need to support some form of dual-stack (for example a DC= may be IPv6-only but use SIIT-DC to appear as dual-stack in the public fac= ing interfaces). Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 8/7/19 19:24, "JORDI PALET MARTINEZ" escribi=C3=B3: Hi Dusan, =20 I think you're reading it wrong. =20 This document is about guidelines for deployment of an existing transit= ion mechanism: NAT64 (and a derivate of it, 464XLAT). =20 NAT64 was designed as a solution for IPv6-only hosts, connected to an I= Pv6-only access network, to access IPv4-only services (as well as dual-stac= k ones). =20 464XLAT also provides a solution for IPv4-only hosts, connected to an I= Pv6-only access network, to access IPv4-only services (as well as dual-stac= k ones). =20 So, the *actual* implementation of 464XLAT/NAT64 doesn't allow IPv4-onl= y hosts to connect to IPv6-only hosts. =20 *However*, you may be interested in reading this optimization that may = solve the problem: https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-cach= es/?include_text=3D1 =20 Note that this is work-in-progress, and if you wait to the end of the d= ay, you will get a *much better* version of this document. This will solve = the problem that you mention if 464XLAT is used. =20 I will send a notification in the list when I submit the next version, = it is taking many more hours than I expected ... =20 Regards, Jordi @jordipalet =20 =20 =20 =EF=BB=BFEl 8/7/19 19:08, "v6ops en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: =20 Section 3.3: =20 "if the network must support applications using any of the following: =20 o IPv4-only hosts or applications =20 Then, only the scenarios with 464XLAT, a CLAT function, or equiv= alent built-in local address synthesis features, will provide a valid solution." =20 Which document explains how 464XLAT and a CLAT function provide con= nectivity from IPv4only-host to IPv6only-host? =20 Thanks, Dusan. =20 =20 > -----Original Message----- > From: v6ops On Behalf Of JORDI PALET > MARTINEZ > Sent: Sunday, July 7, 2019 5:24 PM > To: =C3=89ric Vyncke ; The IESG > Cc: v6ops@ietf.org; draft-ietf-v6ops-nat64-deployment@ietf.org; v= 6ops- > chairs@ietf.org > Subject: Re: [v6ops] =C3=89ric Vyncke's No Objection on draft-iet= f-v6ops-nat64- > deployment-06: (with COMMENT) >=20 > Hi Eric, >=20 > Thanks a lot for your review! >=20 > Comments in-line below. Most of them I will reword some text or c= orrect > nits, but there are a couple of questions for you to clarify. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 > =EF=BB=BFEl 7/7/19 14:59, "v6ops en nombre de =C3=89ric Vyncke vi= a Datatracker" bounces@ietf.org en nombre de noreply@ietf.org> escribi=C3=B3: >=20 > =C3=89ric Vyncke has entered the following ballot position fo= r > draft-ietf-v6ops-nat64-deployment-06: No Objection >=20 > When responding, please keep the subject line intact and repl= y to all > email addresses included in the To and CC lines. (Feel free t= o cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://urldefense.proofpoint.com/v2/url?u=3D= https- > 3A__www.ietf.org_iesg_statement_discuss- > 2Dcriteria.html&d=3DDwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9c= bLeaJ > xhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E9ZufQAIc5wlVLDWKPA2DvW0t > rvZwSDh5SnT8LOzdg&s=3DLwRXKT1d-8SS5QiUbHNrp33o3TBAeLqgs9RN- > UwC0Yg&e=3D > for more information about IESG DISCUSS and COMMENT positions= . >=20 >=20 > The document, along with other ballot positions, can be found= here: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnat64- > 2Ddeployment_&d=3DDwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbL= e > aJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E9ZufQAIc5wlVLDWKPA2DvW > 0trvZwSDh5SnT8LOzdg&s=3DPHW- > a847Dg670Srlft54euH86mfhpwcaNiqzcBPS8v4&e=3D >=20 >=20 >=20 > -------------------------------------------------------------= --------- > COMMENT: > -------------------------------------------------------------= --------- >=20 > Hello Jordi, >=20 > Thank you for the work put into this clear and well-written = document. >=20 > I only wonder whether section 3 and section 4 should be swapp= ed for a > more > logical flow: explain the issues, then describe working solut= ions. Probably > too > late in the publication to change though. >=20 > I think that will be a major change, because I've a lot of refere= nces to the > "possible" deployment scenarios to explain the different issues. = My "flow" > was thinking in how you can deploy it, and then what are the issu= es that you > need to consider. >=20 > The underlying message of "464XLAT solves everything" is anno= ying but I > must > admit that this is true ;-) >=20 > This document started as 464XLAT deployment guidelines, and the W= G asked > me to turn it also to "NAT64". I think that explains it, but in a= ny case, as you > well say, it is true ... and there is explicit text to indicate t= hat if you're sure > that everything inside the network is supporting IPv6, no literal= s, etc., then it > may be fine with just NAT64. However we all know that this is a n= on-realistic > scenario. >=20 > Please find below many COMMENTs in the hope of improving the > readability and > factual data points in the document. >=20 > -=C3=A9ric >=20 > =3D=3D COMMENTS =3D=3D >=20 > Is there a description of the use of DNS64 in the host as it = fixes the DNSSEC > issues ? (except in section 3.2.2.) >=20 > Not sure to completely understand what you mean here, just trying= ... This is > not something that the service provider can solve, as it is up to= the OS (for all > the devices in that network). That's why I think is not something= for this > document. However, I just realized that this is described in sect= ion 7.2 of > RFC6147. I can add a reference to that in section 3.2.2. >=20 > -- Section 3.1 -- >=20 > "known to work": can you add references or data backing this = statement ? >=20 > Well, those are the models being used today in cellular and broad= band > networks. So I can just say that? >=20 > -- Section 3.1.1 -- >=20 > When discussing scenarii, please refer to the figure ID in th= e text for clarity. >=20 > Done (I'm already editing a new version while writing this, pendi= ng on some > that you can provide to my comments). >=20 > -- Section 3.1.2 -- >=20 > It is unclear to me whether "The support of this scenario" re= fers to the > UE-only or the CPE deployment. >=20 > It is referring to the "service provider network support". Will c= larify it. >=20 > Same demand as above: please refer to the figure ID in the te= xt for clarity. >=20 > Done! >=20 > -- Sectio 3.2.1 -- >=20 > I really wonder whether it is useful to describe this scenari= o as 'working > under special conditions'... those 'special conditions' will = probably never > met > in real life. >=20 > More generally, I am unsure about the value of the whole sect= ion 3.2 (it is > more like an academic thing). >=20 > I think some of those scenarios are possible in some networks, ma= y be not > connecting to Internet, or for example, you may want to configure= explicit > mappings, which can be done with EAM. I just realized that I've n= ot cited > that. I will do. >=20 > -- Section 4.1.1. -- >=20 > Can you add reference and/or data for "monitored by some gove= rnmental > bodies > and other institutions". >=20 > I believe that was pointed out by somebody in the WG, but it is t= rue that > some regulators do that. I recall having seen something about tha= t in France, > but I'm not 100% sure right now. >=20 > Please add a reference for the use of "ipv4only.arpa". AFAIK >=20 > Right, this is defined by RFC7050, done! >=20 > draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/d= ead. >=20 > This is one of the issues that I've commented with Warren, respon= ding to > IANA. I understand he is sponsoring that document. >=20 >=20 > -- Section 4.1.2 -- >=20 > The leading paragraph is a little confusing as it assumed tha= t CLAT exists > (stated in the text but not in the section title). >=20 > Will clarify it. >=20 > -- Section 4.1.5 -- >=20 > The section title is rather misleading "ACL of clients" and I= wonder why a > dual-stack client would use a DNS64 server as its recursive D= NS server. Isn't > it an obvious configuration mistake? >=20 > No, I think that text is correct, but I will try to reword it to = make it clearer. You > may have a situation with IPv4-only servers, which are located, i= n the path > between the dual-stack hosts and the NAT64. So, if the DNS64 is n= ot > configured to exclude those servers, it will synthetize the AAAA = records and > they will become unreachable. So that's why bind and other DNS64 = servers > provide this ACL function. >=20 > -- Section 4.4.1 -- >=20 > Some explanations of the consequences of a foreign DNS would = be > welcome. >=20 > Done! >=20 > -- Section 4.4.2 -- >=20 > Rather than using "DNS privacy" please use "DNS request confi= dentiality" > as the > DNS64 will learn/glean about the client activities. >=20 > I used this terminology as it was suggested as the common one for= the > different protocols in this category. I will try to confirm if is= the right one just > in case. May be rewording the title as "DNS Privacy/Encryption Me= chanisms" > ? >=20 >=20 >=20 > -- Section 4.6 -- >=20 > Please explain why older API is a problem (or rather rephrase= it into > applications using IPv4-only API). >=20 > Done! >=20 > -- Section 4.10 -- >=20 > draft-ietf-tram-turnbis is also able to support IPv6-only cli= ent. It is > currently in the same IESG status as this document. >=20 > Definitively, will add a reference to it! >=20 > -- Section 5 -- >=20 > Please add data/references for "with hundreds of millions of = users" >=20 > I can cite several cellular networks, but I will do in a generic = way, I don't think > we should mention explicit providers, right?. >=20 > -- Section 7 -- >=20 > Not so much about security but about privacy. I would appreci= ate to have > some > text around the lack of privacy when using an external DNS64 = as this server > will learn about all clients activities. >=20 > Good point, thanks. Will do! >=20 > =3D=3D NITS =3D=3D >=20 > Generally, please refrain from using "HEv2" in place of "Happ= y Eyeball > version > 2". >=20 > Done! >=20 > -- Section 3.1.1. -- >=20 > Figure 1 shows a box containing both NAT64 and DNS64 while th= ose > functions > could reside in different devices. >=20 > Will clarify it. >=20 > s/One more equivalent scenario/One additional equivalent scen= ario/ ? >=20 > Done! >=20 > -- Section 4.1 -- >=20 > s/to an IPv6-only WAN/to an IPv6-only access network/ >=20 > Done! >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DBFpWQw8bsu= Kp > l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E= 9 > ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=3DwOPWzlIjnoqYXR0OM > bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=3D >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.theipv6company.com&d=3DDwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64 > Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E9ZufQAIc5 > wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=3DDJpxsc514- > zcfBAFS4ksUO1Az_LzLKo1Da80uIg60JA&e=3D > The IPv6 Company >=20 > This electronic message contains information which may be privile= ged or > confidential. The information is intended to be for the exclusive= use of the > individual(s) named above and further non-explicilty authorized d= isclosure, > copying, distribution or use of the contents of this information,= even if > partially, including attached files, is strictly prohibited and w= ill 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 prohibit= ed, will be > considered a criminal offense, so you must reply to the original = sender to > inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DBFpWQw8bsu= Kp > l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_E= 9 > ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=3DwOPWzlIjnoqYXR0OM > bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=3D _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Mon Jul 8 14:40:23 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0763612030A; Mon, 8 Jul 2019 14:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=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=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 xwZjZE_Sbv8Q; Mon, 8 Jul 2019 14:40:03 -0700 (PDT) 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 AD5E612030D; Mon, 8 Jul 2019 14:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562622000; x=1563226800; 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; bh=o5mTtc7GFztiu7H3ujiEIr MtFmMPlA+9bemOLSkfd94=; b=QYEW5xkQbl7nTodQ2AZ0aUas1cu9N6SzQ2pqAR mJX6vvMx3Q/Rhp4LLgHGnXu0QX8VhUTFJUWd/DfYQttCmhNnGV2ywbBY8P74SIVV yh8aSwlw2Fmrw2pyWEnEvnSWDH4i9b4yyCDoHJ35MtEFEdRQtye5XvvnCaSo3VuQ xE6Lc= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 08 Jul 2019 23:40:00 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 08 Jul 2019 23:39:59 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006319620.msg; Mon, 08 Jul 2019 23:39:59 +0200 X-MDRemoteIP: 2001:470:1f09:495:61d7:174e:4fa1:2845 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Mon, 08 Jul 2019 23:39:59 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1092a35ad6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Mon, 08 Jul 2019 23:39:58 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations CC: 6man <6man@ietf.org> Message-ID: <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> Thread-Topic: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3645473998_1710516189" Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 21:40:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3645473998_1710516189 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I think there are several possible solutions, but the simpler one seems to = be the dual-stack SIP proxies. Another one is draft-ietf-tram-turnbis, whic= h I didn=E2=80=99t knew, until today, is already in the IESG for approval t= his Thrusday. Also it can be done with EAM and also as I mention in a previous email via = the optimization for 464XLAT. Just uploaded the new version: =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?= include_text=3D1 =20 =20 =20 =20 =20 El 8/7/19 19:01, "v6ops en nombre de David Farmer" escribi=C3=B3: =20 =20 =20 On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) w= rote: > -----Original Message----- > From: Manfredi (US), Albert E >=20 > -----Original Message----- > From: ipv6 On Behalf Of Mudric, Dusan (Dusan) >=20 > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and v= ice > versa? >=20 > IPv6 to IPv4 should be straightforward, because it's a one-to-one > relationship. The other way around would normally not work,=20 [Dusan] There is no solution for IPv4only client to reach IPv6only client?= =20 =20 I mostly say, so what! It is an unfortunate reality of today's Internet, be= cause of NAT44 and/or stateful firewall default deny inbound policy, many t= imes clients can't speak to other clients, be they IPv4 only, IPv6 only, or= even dual stack. Sometimes firewall traversal technologies can work around= this, also depending on the firewall traversal solution used sometimes IPv= 4 only and IPv6 only clients will be able to talk to each other. My guess = is that IPv4 only to IPv6 only firewall traversal would be less effective t= han NAT44 client to NAT44 client firewall traversal, but it is should still= be possible in some cases.=20 =20 > but everyone > has been accustomed to that with IPv4 NAPT already.=20 [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed= not to be able to call IPv6only users (like Apple IPv6 only phones)? =20 They may not be able to talk peer to peer. However, through a dual-stack SI= P or other proxies/session border controller, they could probably complete = a call.=20 =20 >The client behind the > NAPT initiates. >=20 > > Is DNS64 server returning IPv4ony client address to IPv6only client, us= ing > the A RR? >=20 > The DNS synthesizes the IPv6 address, which has the IPv4 address > embedded in it. >=20 > > - How can IPv4only client get the address of IPv6only client (or, it is > impossible for IPv4only client to get IPv6 address of IPv6only client)? >=20 > That's clearly more difficult, which is why the normal course of action i= s for > the IPv6 client to initiate the session. [Dusan] What if IPv4only client needs to initiate the session to IPv6only c= lient? What is the solution for that use case? =20 Many firewall traversal solutions should work in this case, but IPv4 only c= lient to client isn't guaranteed to work in all cases either.=20 =20 >=20 > > - Do these IPv4 and IPv6 client addresses need to be pre-configured on = the > translator and/or DNS64? >=20 > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the sessi= on, you'd > have to have preconfigure something. [Dusan] Where and how is this configuration done? >=20 > Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. --B_3645473998_1710516189 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I think ther= e are several possible solutions, but the simpler one seems to be the dual-= stack SIP proxies. Another one is draft-ietf-tram-turnbis, which I didn=E2= =80=99t knew, until today, is already in the IESG for approval this Thrusda= y.

Also it can be done with EAM and also as I mention in a previous= email via the optimization for 464XLAT. Just uploaded the new version:

 

https://datatracker.ietf.org/doc/draft-palet-v6o= ps-464xlat-opt-cdn-caches/?include_text=3D1

 

 

 

 

 =

El 8= /7/19 19:01, "v6ops en nombre de David Farmer" <v6ops-bounces@ietf.org en nombre de farmer@umn.edu> escribi=C3=B3:=

 

 

 

On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) <<= a href=3D"mailto:dmudric@avaya.com">dmudric@avaya.com> wrote:

> -----Original Message-----> From: Manfredi (US), Albert E <albert.e.manfredi@boeing.com>
>= ;
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> = On Behalf Of Mudric, Dusan (Dusan)
>
> > - How can DNS64 te= ll IPv6 only client the IP of IPv4 only client, and vice
> versa?
= >
> IPv6 to IPv4 should be straightforward, because it's a one-to= -one
> relationship. The other way around would normally not work, [Dusan] There is no solution for IPv4only client to reach IPv6only client= ?

 

I mostly say, so what! It is an unfortunate reality of tod= ay's Internet, because of NAT44 and/or stateful firewall default deny inbou= nd policy, many times clients can't speak to other clients, be they IPv4 on= ly, IPv6 only, or even dual stack. Sometimes firewall traversal technologie= s can work around this, also depending on the firewall traversal solution u= sed sometimes IPv4 only and IPv6 only clients will be able to talk to each = other.  My guess is that IPv4 only to IPv6 only firewall traversal would be less effective than NAT44 cl= ient to NAT44 client firewall traversal, but it is should still be possible= in some cases. 

 

> but everyone
> has been accustomed to that with IPv4 NAPT alr= eady.
[Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be = accustomed not to be able to call IPv6only users (like Apple IPv6 only phon= es)?

 

They may not be able to talk peer to peer. However, thro= ugh a dual-stack SIP or other proxies/session border controller, they could= probably complete a call. 

 

>The client behind the
> NAPT initiates.
>
&= gt; > Is DNS64 server returning IPv4ony client address to IPv6only clien= t, using
> the A RR?
>
> The DNS synthesizes the IPv6 ad= dress, which has the IPv4 address
> embedded in it.
>
> = > - How can IPv4only client get the address of IPv6only client (or, it i= s
> impossible for IPv4only client to get IPv6 address of IPv6only cl= ient)?
>
> That's clearly more difficult, which is why the nor= mal course of action is for
> the IPv6 client to initiate the session= .
[Dusan] What if IPv4only client needs to initiate the session to IPv6o= nly client? What is the solution for that use case?

 

Many fire= wall traversal solutions should work in this case, but IPv4 only client to = client isn't guaranteed to work in all cases either. 

 

>
> > - Do these IPv4 an= d IPv6 client addresses need to be pre-configured on the
> translator= and/or DNS64?
>
> For IPv4 to IPv6, if you must allow the IPv= 4 client to initiate the session, you'd
> have to have preconfigure s= omething.
[Dusan] Where and how is this configuration done?

> =
> Bert

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

<= /div>


&nbs= p;

--

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer&n= bsp;              Email:farmer@umn.edu
Networkin= g & Telecommunication Services
Office of Information Technology
U= niversity of Minnesota  
2218 University Ave SE    =     Phone: 612-626-0815
Minneapolis, MN 55414-3029  = Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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


**********************************************
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.

--B_3645473998_1710516189-- From nobody Mon Jul 8 14:43:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3138E1202E9 for ; Mon, 8 Jul 2019 14:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=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=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 PJhWBeLAuRHb for ; Mon, 8 Jul 2019 14:43:13 -0700 (PDT) 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 BB2DC120278 for ; Mon, 8 Jul 2019 14:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562622191; x=1563226991; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=yjE4hQqTTjrxi2wN98pNOq8ynzyx02oPyJ YvuJ0TJnk=; b=L65VejqSEWTYF5X10mEGUBc59dw7hjegrBxIWIZB6v7MH6pQfF B4KbWxCkuUVJYsLP/gEFMnaRbAnEOlepzYEDHwBgj8jxtAOY5SFNZZkoywpWBujR OSjl3jKtDa5VrqpwIzJYY2JW81PrRJNUTh+kVQQylUqw7IxshPMcuho9M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 08 Jul 2019 23:43:11 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 08 Jul 2019 23:43:10 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006319625.msg for ; Mon, 08 Jul 2019 23:43:09 +0200 X-MDRemoteIP: 2001:470:1f09:495:61d7:174e:4fa1:2845 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Mon, 08 Jul 2019 23:43:09 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1092a35ad6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Mon, 08 Jul 2019 23:43:09 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <3E423587-A00A-4918-966E-C8BEAE0298FD@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches References: <291EE30B-D299-4EA1-8C8B-53F4BE6A9B07@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3645474189_200027141" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 21:43:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3645474189_200027141 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fred, all, =20 I just submitted a new version for this document. =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?= include_text=3D1 =20 I=E2=80=99ve updated the issues from your inputs, as well as the issue that= Martin raised. It has required a much complex approach than the one initia= lly drafted when responding to him, but I think it resolves the problem. =20 Hopefully we can get inputs, specially from CDN/Cache providers, but also f= rom hosting providers if they are using this reverse-proxy often =E2=80=A6 =20 Regards, Jordi @jordipalet =20 =20 =20 El 28/6/19 17:10, "v6ops en nombre de JORDI PALET MARTINEZ" escrib= i=C3=B3: =20 Hi Fred, =20 Thanks for your inputs. =20 Responses, below, in-line. =20 Regards, Jordi @jordipalet =20 =20 =20 El 28/6/19 15:55, "v6ops en nombre de Fred Baker" escribi=C3=B3: =20 I=E2=80=99m reading through this draft, and feel some comments are in order= on the issues marked =E2=80=9CTBD=E2=80=9D. In this case, I=E2=80=99m writ= ing as an individual. =20 Sometimes I use the TBD, not necessarily because that need to be completed,= but to make sure that I double think on that for the next version. =20 In the general problem and proposed solutions, I agree that the problem sta= tement makes sense (it is comparable to the problem statement in SIIT-DC), = and section 4.2 (also comparable to SIIT-DC) seems to present the solution = with the least impact on the network and its surrounding devices. =20 A few thoughts: The information in the EAMT MUST be kept timely-synchronized with the AAAA records TTL's. In order to achieve that, each EAMT entry MUST update with each A query, the TTL of the relevant AAAA record. Update of RFC7757 ? TBD. =20 I don=E2=80=99t view this as changing 6145/7915=E2=80=99s algorithm. I need= to understand how this changes 7757 to agree that it updates it. =20 Section 6 of RFC7915 has a SHOULD for EAM. I think this is right, but I see= that RFC6877 (464XLAT), should get it as a MUST. =20 Similarly, my question about RFC7757, is if it is useful that each entry in= the EAMT also needs to have a TTL, or this is exclusive for our optimizati= on case (this ID) ? =20 SIIT already has a SHOULD for EAM support. TBD. 464XLAT may be updated by this document so the CLAT has a MUST for EAM support. =20 THe fact that you want it for this use case doesn=E2=80=99t mean that it is= required by all use cases. I=E2=80=99d want to hear that argument before a= greeing to =E2=80=9CMUST=E2=80=9D. =20 I think it makes sense that 464XLAT is *always* optimized, so that=E2=80=99= s why I think it requires to be updated by this document.. =20 And in any event, what is the argument for 2119 language in an informationa= l document? This is beginning to sound more like a Proposed Standard... =20 Actually we have got this request already many times when having the IESG r= eview. I=E2=80=99ve used RFC7084 =E2=80=9Cspecial=E2=80=9D language in the = recent RFC8585, and I was asked to just use the RFC2119 one. =20 However, I also believe that this document, if we agree that 464XLAT must b= e always optimized, then this ID is an opportunity for killing two birds wi= th a stone: 1) Updating RFC6877 to include the optimization always. 2) It doesn=E2=80=99t make senses (we talked already some time ago about t= his), that MAP-E/T, DS-Lite and lw4o6 are standards, and 464XLAT which is t= he mechanism that have =E2=80=9Cmore=E2=80=9D users in the world (even comp= ared to all the others together), is just informational. So this ID may be = a proposed standard covering both aspects. =20 TBD. Should we recommend having A "null" records for IPv6-only services in Internet? A web page IPv4-only hosted by IETF(?) showing "sorry this web page/service is only available from IPv6 enabled operators"? =20 I=E2=80=99m very concerned about requiring something that is not going to b= e DNSSEC-compatible, which=20 =20 =E2=80=9Cnull=E2=80=9D maybe not the best wording here, so may not break DN= SSEC. I mean using an IPv4 address that is not actually configured in the s= erver that the has the AAAA. I think it makes sense that this address is a = public one defined by the IETF, which we may use for a special page (or not= use at all, but still a special one). =20 it seems such a =E2=80=9Cnull=E2=80=9D record has to be. I=E2=80=99m also c= oncerned about something that forces a change to DNS implementations, as a = change to the interpretation of an A resource record seems likely to do. An= A resource record advertises an IPv4 address that one can expect to work u= nder some set of conditions, and a =E2=80=9Cnull=E2=80=9D record seems to a= dvertise an address whose set of conditions for=20 =20 Clearly, I confused using the =E2=80=9Cnull=E2=80=9D wording. Is a real add= ress (so no change at all in DNS implementations), but this address is not = actually configured in the interface of the server (because it is IPv6-only= ). =20 validity would be null. So this is something I would be concerned to find, = and would expect to require dnsop support for before I was willing to accep= t it. TBD. Other risks to consider ? If a CE is misconfigured, even a small percentage of broken CEs may bring the content providers to switch back to IPv4-only. So possible failure cases need to be carefully considered for every possible solution approach. TBD. Should a way to manually exclude EAMT entries be considered? May be a manual config in the CPE and by means of operator config. This is way-out to ensure nothing is broken by surprise and is not solvable. =20 I=E2=80=99m not an operator. I would expect any operator reading this to sa= y =E2=80=9Cheavens no, no manual or specific configurations. Make this just= fall out of normal operations.=E2=80=9D=20 =20 I think again is a matter of wording. Many CEs have lots of options that us= ually operators don=E2=80=99t use. But if they need to use they can configu= re them remotely, or because they get from the vendor a default =E2=80=9Cfa= ctory=E2=80=9D config. However, in some cases, those configs are also manag= ed by =E2=80=9Cexpert=E2=80=9D users (and today a gamer, just an example, i= s most of the time an expert user). =20 Operators, please feel free to agree or disagree, and say why. This document does not have any new specific security considerations. =20 The question about =E2=80=9Cbroken CEs=E2=80=9D seems to point to a securit= y consideration. In what way might they be misconfigured, and what would th= e effect be? =20 Again, I need to change the wording here. The CE is not actually broken. Th= e complete paragraph =E2=80=9CTBD. Other risks to consider ? =E2=80=A6=E2= =80=9D was more a way to remind muself to work on that. The point is that i= f we have this optimization, we need to make sure to double-check with CDNs= that it doesn=E2=80=99t create a trouble for them, because in those cases = they see the =E2=80=9CCE as broken for IPv6=E2=80=9D and they prefer to dis= able IPv6 for the entire ISP that has the =E2=80=9Cbroken CEs=E2=80=9D. =20 Is that clearer now? =20 I will definitively improve the wording for the next version, so those poin= ts don=E2=80=99t create confusion. =20 =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. --B_3645474189_200027141 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Fred, all,

 

I just submitted = a new version for this document.

=  

https://datatracker.ietf.org/doc/draft-palet-v6ops-464x= lat-opt-cdn-caches/?include_text=3D1

 

I=E2=80=99ve updated the issues from your inputs, as well as the issue = that Martin raised. It has required a much complex approach than the one in= itially drafted when responding to him, but I think it resolves the problem= .

 

Hopefully we can get inputs, specially from CDN/Cache provide= rs, but also from hosting providers if they are using this reverse-proxy of= ten =E2=80=A6

 

Regards,

Jordi

@jordipalet

&nb= sp;

 

 

El 28/6/19 17:10, "v6ops en nombre de JO= RDI PALET MARTINEZ" <v6op= s-bounces@ietf.org en nombre de jordi.palet=3D40consulintel.es@dmarc.ietf.org= > escribi=C3=B3:

 

Hi Fred,

 

Thanks for your inputs.

 

Responses, below, in-line.<= /o:p>

 

Regards,

<= span lang=3DEN-US style=3D'font-size:12.0pt;color:black;mso-fareast-languag= e:EN-US'>Jordi

@jordipalet

 

 

 

El 28/6/19 15:55, "v6ops en nombre de = Fred Baker" <v6ops-bounce= s@ietf.org en nombre de fre= dbaker.ietf@gmail.com> escribi=C3=B3:

 

I=E2=80=99m reading th= rough this draft, and feel some comments are in order on the issues marked = =E2=80=9CTBD=E2=80=9D. In this case, I=E2=80=99m writing as an individual.<= o:p>

 

Some= times I use the TBD, not necessarily because that need to be completed, but= to make sure that I double think on that for the next version.=

 

In the general problem and proposed solutions, I ag= ree that the problem statement makes sense (it is comparable to the problem= statement in SIIT-DC), and section 4.2 (also comparable to SIIT-DC) seems = to present the solution with the least impact on the network and its surrou= nding devices.

 

A few thoughts:
  The information in the EAMT MUST = be kept timely-synchronized with the

  AAAA records TTL's.  In order to a= chieve that, each EAMT entry MUST
  update with each A query, = the TTL of the relevant AAAA record.
  Update of RFC7757 ? TBD= .

 

I don=E2=80=99t view this as changing 6145/7915=E2= =80=99s algorithm. I need to understand how this changes 7757 to agree that= it updates it.

 

Section 6 of RFC7915 h= as a SHOULD for EAM. I think this is right, but I see that RFC6877 (464XLAT= ), should get it as a MUST.

 = ;

Similarly, my question about RF= C7757, is if it is useful that each entry in the EAMT also needs to have a = TTL, or this is exclusive for our optimization case (this ID) ?=

 

  SIIT already has a SHOUL= D for EAM support.  TBD. 464XLAT may be

  updated by this document so the CLAT has a=
 MUST for EAM support.
 
THe fact that you want it for this u=
se case doesn=E2=80=99t mean that it is required by all use cases. I=E2=80=
=99d want to hear that argument before agreeing to =E2=80=9CMUST=E2=80=9D.<=
o:p>
 =

I think it makes sen=
se that 464XLAT is *always* optimized, so that=E2=80=99s why I think=
 it requires to be updated by this document..
 
And in any event, what is the argum=
ent for 2119 language in an informational document? This is beginning to so=
und more like a Proposed Standard...
 
Actually we have got this request already many times when =
having the IESG review. I=E2=80=99ve used RFC7084 =E2=80=9Cspecial=E2=80=9D=
 language in the recent RFC8585, and I was asked to just use the RFC2119 on=
e.
 
However, I also be=
lieve that this document, if we agree that 464XLAT must be always optimized=
, then this ID is an opportunity for killing two birds with a stone:=

1)=
  Updating RFC6877 to include the optimization always.=

2)  It doe=
sn=E2=80=99t make senses (we talked already some time ago about this), that=
 MAP-E/T, DS-Lite and lw4o6 are standards, and 464XLAT which is the mechani=
sm that have =E2=80=9Cmore=E2=80=9D users in the world (even compared to al=
l the others together), is just informational. So this ID may be a proposed=
 standard covering both aspects.
 

  TBD.  Should we rec= ommend having A "null" records for IPv6-only
  servi= ces in Internet?  A web page IPv4-only hosted by IETF(?) showing
&n= bsp; "sorry this web page/service is only available from IPv6 ena= bled
  operators"?

=

 

I=E2=80=99m very c= oncerned about requiring something that is not going to be DNSSEC-compatibl= e, which

 

=E2=80=9Cnull=E2=80=9D maybe not the best wo= rding here, so may not break DNSSEC. I mean using an IPv4 address that is n= ot actually configured in the server that the has the AAAA. I think it make= s sense that this address is a public one defined by the IETF, which we may= use for a special page (or not use at all, but still a special one).

 

it seems such a =E2=80=9Cnull=E2=80=9D reco= rd has to be. I=E2=80=99m also concerned about something that forces= a change to DNS implementations, as a change to the interpretation of an A= resource record seems likely to do. An A resource record advertises an IPv= 4 address that one can expect to work under some set of conditions, and a = =E2=80=9Cnull=E2=80=9D record seems to advertise an address whose set of co= nditions for

 

Clearly, I confused using the =E2=80=9Cnull=E2=80=9D wording. Is = a real address (so no change at all in DNS implementations), but this addre= ss is not actually configured in the interface of the server (because it is= IPv6-only).

 

validity would be null. So this is something I would be concerned = to find, and would expect to require dnsop support for before I was willing= to accept it.




  TBD.  Other risks to consider ? If a CE is misconfigured,= even a
  small percentage of broken CEs may bring the content= providers to
  switch back to IPv4-only.  So possible fa= ilure cases need to be
  carefully considered for every possib= le solution approach.

  TBD.  Should a way to manuall= y exclude EAMT entries be considered?
  May be a manual config= in the CPE and by means of operator config.
  This is way-out= to ensure nothing is broken by surprise and is not
  solvable= .

 

I=E2=80=99m not an operator. I would expect any ope= rator reading this to say =E2=80=9Cheavens no, no manual or specific config= urations. Make this just fall out of normal operations.=E2=80=9D =

 

I think = again is a matter of wording. Many CEs have lots of options that usually op= erators don=E2=80=99t use. But if they need to use they can configure them = remotely, or because they get from the vendor a default =E2=80=9Cfactory=E2= =80=9D config. However, in some cases, those configs are also managed by = =E2=80=9Cexpert=E2=80=9D users (and today a gamer, just an example, is most= of the time an expert user).

 <= /o:p>

Opera= tors, please feel free to agree or disagree, and say why.




  This document does = not have any new specific security considerations.

 

The question about =E2=80=9Cbrok= en CEs=E2=80=9D seems to point to a security consideration. In what way mig= ht they be misconfigured, and what would the effect be?

 

Again, I need to change= the wording here. The CE is not actually broken. The complete paragraph = =E2=80=9CTBD.  Other risks to consider ? =E2= =80=A6=E2=80=9D was more a way to remind muself to work on that. The point = is that if we have this optimization, we need to make sure to double-check = with CDNs that it doesn=E2=80=99t create a trouble for them, because in tho= se cases they see the =E2=80=9CCE as broken for IPv6=E2=80=9D and they pref= er to disable IPv6 for the entire ISP that has the =E2=80=9Cbroken CEs=E2= =80=9D.

 <= /p>

Is that clearer now?

 

I will defini= tively improve the wording for the next version, so those points don=E2=80= =99t create confusion.

 

 

________= _______________________________________ v6ops mailing list v6ops@ietf.org h= ttps://www.ietf.org/mailman/listinfo/v6ops


*****************************= *****************
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 i= nformation is intended to be for the exclusive use of the individual(s) nam= ed above and further non-explicilty authorized disclosure, copying, distrib= ution or use of the contents of this information, even if partially, includ= ing attached files, is strictly prohibited and will be considered a crimina= l offense. If you are not the intended recipient be aware that any disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited, will be con= sidered a criminal offense, so you must reply to the original sender to inf= orm about this communication and delete it.

________________________= _______________________ v6ops mailing list v6ops@ietf.org https://www.ietf.= org/mailman/listinfo/v6ops


***********************= ***********************
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.

--B_3645474189_200027141-- From nobody Mon Jul 8 16:21:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1417112037D; Mon, 8 Jul 2019 16:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 lpphrVOj2La4; Mon, 8 Jul 2019 16:20:32 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720108.outbound.protection.outlook.com [40.107.72.108]) (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 44639120364; Mon, 8 Jul 2019 16:20:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S/nQ5dKmaDkECn1orNWMDJfrqE1RCIpFjB8XVprMs2kFF2WiAE1BmUxumhG6wxD8lkonECmwvqmwWB6i+q4mlUmzvTl2r+kIVHZJJ8EwcvxmHW7wltKr9M2aqN2xuNNPYTDqNAA4SZTkgUyObavlGnWneWkEVxRaawOb7yoLk331/IoBSR6sFolq3SRhFngWO5GeShWXdirwY5uplW5POC488OSR3lNsu9pdBRuOtOnAnBzOEzy8TzxUQmtWoPLgPtLA8+YdPFyzDmd99RBy8uvsQoEjEayngYO99pgbSClu+/3JEyAPqNK0LK6bj23IqlfeZXRILmz+Qz314+TO4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i2NdUXxZw2XWVuprZS6ALt6drrTg38h+r0BT6++aS8A=; b=a1b8Ow4NXxSMSNWm7KWrj6FBRXJ99+j1lQoo6jJietr961vmTAssoCs4YjX0UKXXZ0Vhny1znWxt5DUxUBl57WgKHyengGxSL5i0DPAq9fc3duzZ+zeDZHi0+BoTVfC76soBZ1Z64Gso2hUGqyHGzYhLFNm9nViP9kEDOYfW7RTvEAg35SA6vNW2Gtkw3LG2OKJ+PwfjA9/NFS6ceEFOagHziu/E/ji0OzkiT4BTVOz29j1AtRq+RJ3nblTvq5iAVJwFYOthwcooXUIfXx5zwAk908YASw7X94UluBKr0prCSYNU557ebPOPxeE/VP+d52OqI2wrYONu2DI2vatKXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i2NdUXxZw2XWVuprZS6ALt6drrTg38h+r0BT6++aS8A=; b=G2EYyPWDL6ZEGLSKSPNq6mLf/zVT658NvWxzu9RNlO+FQD//irCg+/eABEdX9OSWIZSWsDEtyaFX7sMw+vBAjPd4croF3RvBs3fH85wAKKaw4nK75y1mr+agrrtFeTjKvfIEvx9PpcRJCFr/DF9zEDVLjGA3V5PZN/eZB6vDk9k= Received: from MWHPR21MB0784.namprd21.prod.outlook.com (10.173.51.150) by MWHPR21MB0144.namprd21.prod.outlook.com (10.173.52.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.2; Mon, 8 Jul 2019 23:20:30 +0000 Received: from MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::69c0:8cb:908c:f221]) by MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::69c0:8cb:908c:f221%8]) with mapi id 15.20.2094.001; Mon, 8 Jul 2019 23:20:30 +0000 From: Dave Thaler To: Dave Thaler , Suresh Krishnan , int-area , 6man , dhcwg , V6 Ops List , "opsawg@ietf.org" , "softwires@ietf.org" Thread-Topic: [Int-area] AD sponsoring draft-thaler-iftype-reg-02 Thread-Index: AQHVIUvM9WEXtmDvEkCRovcCdcQgcKa8iIaAgAT7kjA= Date: Mon, 8 Jul 2019 23:20:30 +0000 Message-ID: References: <75825363-B4BA-4F94-A935-B87F474F06C9@kaloom.com> <019801d522ce$34bff3a0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-05T19:17:02.2121879Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a3b4b581-53d2-45cd-a339-063f355f76bd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:8:10d2:dc8f:6397:1757] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7bcb5bd5-81e4-4863-2f26-08d703fade84 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MWHPR21MB0144; x-ms-traffictypediagnostic: MWHPR21MB0144: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(396003)(346002)(366004)(39860400002)(199004)(189003)(53754006)(13464003)(45074003)(54094003)(51444003)(43544003)(99286004)(22452003)(186003)(110136005)(316002)(446003)(6506007)(7696005)(11346002)(8990500004)(2906002)(256004)(476003)(53936002)(71190400001)(102836004)(53546011)(486006)(6246003)(236005)(68736007)(54896002)(9686003)(33656002)(74316002)(55016002)(6306002)(966005)(478600001)(81166006)(73956011)(8936002)(81156014)(8676002)(7736002)(10290500003)(76176011)(64756008)(46003)(66556008)(2501003)(66946007)(229853002)(66446008)(6436002)(76116006)(10090500001)(66476007)(25786009)(5660300002)(606006)(52536014)(790700001)(6116002)(2201001)(86362001)(71200400001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0144; H:MWHPR21MB0784.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EaoibYoKgI7IWv9vKCJlFsz8LjbxP3DtPz/KoyG6c2mS5IxrPAS2o+qZns6nor3q8dXgVpUfIJM2iXdV4Z5pXPob7MkVePxTOEMQqOtceEjou4jMcJOJi2psKNgzP0Nb5rH+ygKtETPEgxOUx2J6IIGc/FqOal5afVGx9ewXXRgKISFIyN8upMEO3HE1ELV6w/SSZ2BFp9aPrFShz8Q5tg6Lw5UvFQ1DStmY6QSrVs4QOZJ762mpWU2aYFuXlsYA1JECJe9dG+qyMxXuqY/LT4NQNKLlTiix+pl4FG7UDEbfagDJG7WJvr4s3n42cIydyY0OvnGQSafQmnyYk5iuMbjehAPV6adKTAguMKlb/1qUuXNa2FzMK9kcBaM19GPl+dzJ7VzxrBSAW0ghzR2LDfYf5ulAZTMvXymmE102S0s= Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0784475D021E1337D2600232A3F60MWHPR21MB0784namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7bcb5bd5-81e4-4863-2f26-08d703fade84 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 23:20:30.4957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dthaler@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0144 Archived-At: Subject: Re: [v6ops] [Int-area] AD sponsoring draft-thaler-iftype-reg-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 23:20:50 -0000 --_000_MWHPR21MB0784475D021E1337D2600232A3F60MWHPR21MB0784namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, draft-thaler-iftype-reg-04 is now posted and incorporates changes base= d on feedback from Med, Tom, Suresh, and others. Diffs from -02 can be seen at https://tools.ietf.org/rfcdiff?url1=3Ddraft-thaler-iftype-reg-02.txt&url2= =3Ddraft-thaler-iftype-reg-04.txt Dave From: Softwires On Behalf Of Dave Thaler Sent: Friday, July 5, 2019 12:17 PM To: tom petch ; Suresh Krishnan ; i= nt-area ; 6man ; dhcwg ; = V6 Ops List ; opsawg@ietf.org; softwires@ietf.org Subject: Re: [Softwires] [Int-area] AD sponsoring draft-thaler-iftype-reg-0= 2 -----Original Message----- From: dhcwg > On Beha= lf Of tom petch Sent: Friday, June 14, 2019 9:28 AM To: Suresh Krishnan >; int-area= >; 6man >; dhcwg >; V6 Ops List= >; opsawg@ietf.org; softwires@ietf.org Subject: Re: [dhcwg] [Int-area] AD sponsoring draft-thaler-iftype-reg-02 Suresh The concern I have is that it muddies the waters further on the standing of= tunnels so while I think that its proposals for ifType per se are fine, I = would like it to make explicit that tunnels are out-of-scope at this time. Tunnels are certainly not out-of-scope. There's two existing registries (i= nterface types and tunnel types), and this draft documents existing registr= ation process, and some process clarifications to address points of process= confusion and ease process friction today. I have been trying to reconcile the workings of softwire, in creating a tun= nel YANG module, with the existing IANA structure and failing. I believe t= hat is because the current status of tunnels is unclear. Thus the softwire= I-D refers to a registry that does not exist Yes it does. The software I-D does not create any new registry. It only= creates another format for retrieving the contents of an existing registry= . Many registries are retrievable in multiple formats (XML, excel, txt, et= c.). This registry is no different. What I can do is add a paragraph explaining the use of multiple formats for= the interface type and tunnel type registries, to make it clear that each = format is not a separate registry, just like getting the TCP port registry = in XML vs excel is not two different registries. Dave (as such) although the URL that the softwire I-D does. I think the timing u= nfortunate in that IMHO the softwires I-D will get pressed ahead before thi= s work can complete, so quite what this I-D then says about tunnels will be= coloured by what then exists for tunnels. So this I-D should make clear what a tunnel is, when it is not an interface= , but otherwise declaring tunnels out-of-scope, for a future I-D to do a co= mparable job for tunnels, setting up a tunnel registry from which MIB modul= es, YANG modules and anything else can be derived (as long as the relevant = data is supplied - SMI needs integers, YANG does not, which I-Ds do not alw= ays recognise although the Designated Experts can take care of that). Finally, when I first encountered this I-D I asked on NETCONF and NETMOD WG= lists if anyone knew of it, where it was being worked on and got no reply = - which surprised me. I note that you have not copied them although they w= ere involved in making the interface type registry what it currently is whe= n creating the YANG module for interface types. I wonder if other WG have = an interest, CCAMP or TEAS perhaps. I agree that int-area is the WG best e= quipped to work on it and that it needs working on. Tom Petch ----- Original Message ----- From: "Suresh Krishnan" > To: "int-area" >; "6man" >; "dhcwg" >; "V6 Ops List" >; >; > Sent: Wednesday, June 12, 2019 7:22 PM Hi all, I would like to AD sponsor the following draft that provides guidelines f= or definition of new interface types in the IANA IfType registries https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-thaler-iftype-reg-02&data=3D02%7C01%7Cdthaler%40= microsoft.com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636961265202763707&sdata=3DHM5asXOFnSuzPaCR4k4kopqsI= HLLdnqZ7PDuu8hPJM4%3D&reserved=3D0 If you have any concerns either with the contents of the draft, or about me= AD sponsoring it please let me know before 2019/06/26. Thanks Suresh NOTE: I have CCed: all the working groups that I thought could be potential= ly interested in this work. If you think I have missed out some WG(s) pleas= e let me know. ------------------------------------------------------------------------ -------- > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=3D02%7C01%7Cdthaler%40 > microsoft.com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91a > b2d7cd011db47%7C1%7C0%7C636961265202763707&sdata=3Dznz7EZ1q%2FwIQUJC > gYZTWfY2H4C7tN6qFhJubCVWxWzc%3D&reserved=3D0 > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fdhcwg&data=3D02%7C01%7Cdthaler%40microsoft= .com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C636961265202763707&sdata=3DOJvbRDz%2FCIlVF3hWR30KCs0cRgi9Kmtn= YLHKbHSeJzc%3D&reserved=3D0 --_000_MWHPR21MB0784475D021E1337D2600232A3F60MWHPR21MB0784namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, draft-thaler-ifty= pe-reg-04 is now posted and incorporates changes based on=

feedback from Med, Tom= , Suresh, and others.

 

Diffs from -02 can be = seen at

https://tools.ietf.org/rfcdiff?url1=3Ddraft-thale= r-iftype-reg-02.txt&url2=3Ddraft-thaler-iftype-reg-04.txt

 

Dave=

 

From: Softwires <softwires-bounces@ietf.or= g> On Behalf Of Dave Thaler
Sent: Friday, July 5, 2019 12:17 PM
To: tom petch <ietfc@btconnect.com>; Suresh Krishnan <Sures= h@kaloom.com>; int-area <int-area@ietf.org>; 6man <ipv6@ietf.or= g>; dhcwg <dhcwg@ietf.org>; V6 Ops List <v6ops@ietf.org>; op= sawg@ietf.org; softwires@ietf.org
Subject: Re: [Softwires] [Int-area] AD sponsoring draft-thaler-iftyp= e-reg-02

 

 

-----Original Message-= ----
From: dhcwg <dhcwg-bounces@iet= f.org> On Behalf Of tom petch
Sent: Friday, June 14, 2019 9:28 AM
To: Suresh Krishnan <Suresh@kaloom.= com>; int-area <int-area@iet= f.org>; 6man <ipv6@ietf.org&= gt;; dhcwg <dhcwg@ietf.org>; V6 Ops List <v6ops@ietf.org>; = opsawg@ietf.org; softwires@ietf.o= rg
Subject: Re: [dhcwg] [Int-area] AD sponsoring draft-thaler-iftype-reg-02

 

Suresh

 

The concern I have is = that it muddies the waters further on the standing of tunnels so while I th= ink that its proposals for ifType per se are fine, I would like it to make = explicit that tunnels are out-of-scope at this time.

 

Tunnels are certainly= not out-of-scope.  There’s two existing registries (interface t= ypes and tunnel types), and this draft documents existing registration proc= ess, and some process clarifications to address points of process confusion and ease process friction today.

 

 

I have been trying to = reconcile the workings of softwire, in creating a tunnel YANG module, with = the existing IANA structure and failing.  I believe that is because th= e current status of tunnels is unclear.  Thus the softwire I-D refers to a registry that does not exist<= /p>

 

Yes it does.   The software I-D does no= t create any new registry.   It only creates another format for r= etrieving the contents of an existing registry.  Many registries are r= etrievable in multiple formats (XML, excel, txt, etc.).   This registry is no different.

 

What I can do is add a paragraph explaining the u= se of multiple formats for the interface type and tunnel type registries, t= o make it clear that each format is not a separate registry, just like gett= ing the TCP port registry in XML vs excel is not two different registries.

 

Dave

 

(as such) although the= URL that the softwire I-D does. I think the timing unfortunate in that IMH= O the softwires I-D will get pressed ahead before this work can complete, s= o quite what this I-D then says about tunnels will be coloured by what then exists for tunnels.

 

So this I-D should mak= e clear what a tunnel is, when it is not an interface, but otherwise declar= ing tunnels out-of-scope, for a future I-D to do a comparable job for tunne= ls, setting up a tunnel registry from which MIB modules, YANG modules and anything else can be derived (as long = as the relevant data is supplied - SMI needs integers, YANG does not, which= I-Ds do not always recognise although the Designated Experts can take care= of that).

 

Finally, when I first = encountered this I-D I asked on NETCONF and NETMOD WG lists if anyone knew = of it, where it was being worked on and got no reply - which surprised me.&= nbsp; I note that you have not copied them although they were involved in making the interface type registry what it = currently is when creating the YANG module for interface types.  I won= der if other WG have an interest, CCAMP or TEAS perhaps.  I agree that= int-area is the WG best equipped to work on it and that it needs working on.

 

Tom Petch

 

----- Original Message -----

From: "Suresh Krishnan" <Suresh@kaloom.com>

To: "int-area" <int-= area@ietf.org>; "6man" <ipv6@ietf.or= g>; "dhcwg"

<dhcwg@ietf.org>; &= quot;V6 Ops List" <v6ops@ietf.org>; <opsawg@ietf.org>; <sof= twires@ietf.org>

Sent: Wednesday, June 12, 2019 7:22 PM=

 

Hi all,

  I would like to AD sponsor the following d= raft that provides guidelines for definition of new interface types in the = IANA IfType registries

 

https://nam06.s= afelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%= 2Fdraft-thaler-iftype-reg-02&amp;data=3D02%7C01%7Cdthaler%40microsoft.c= om%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636961265202763707&amp;sdata=3DHM5asXOFnSuzPaCR4k4kopqsIHLLdnqZ= 7PDuu8hPJM4%3D&amp;reserved=3D0

 

If you have any concerns either with the contents= of the draft, or about me AD sponsoring it please let me know before 2019/= 06/26.

 

Thanks

Suresh

 

NOTE: I have CCed: all the working groups that I = thought could be potentially interested in this work. If you think I have m= issed out some WG(s) please let me know.

 

 

 

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

--------

 

 

> ____________________________________________= ___

> Int-area mailing list

> Int-area@ietf.org=

> https://nam06.safelinks.protection.outloo= k.com/?url=3Dhttps%3A%2F%2Fwww.

> ietf.org%2Fmailman%2Flistinfo%2Fint-area&= ;amp;data=3D02%7C01%7Cdthaler%40

> microsoft.com%7Cbd9080f665064f564d3608d6f0e5= 5a88%7C72f988bf86f141af91a

> b2d7cd011db47%7C1%7C0%7C636961265202763707&a= mp;amp;sdata=3Dznz7EZ1q%2FwIQUJC

> gYZTWfY2H4C7tN6qFhJubCVWxWzc%3D&amp;rese= rved=3D0

> 

 

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org=

https://nam06.safelinks.pr= otection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo= %2Fdhcwg&amp;data=3D02%7C01%7Cdthaler%40microsoft.com%7Cbd9080f665064f5= 64d3608d6f0e55a88%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636961265202= 763707&amp;sdata=3DOJvbRDz%2FCIlVF3hWR30KCs0cRgi9KmtnYLHKbHSeJzc%3D&= ;amp;reserved=3D0

--_000_MWHPR21MB0784475D021E1337D2600232A3F60MWHPR21MB0784namp_-- From nobody Mon Jul 8 18:34:15 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492E71203CE; Mon, 8 Jul 2019 18:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 yyPvVt8OEYtM; Mon, 8 Jul 2019 18:34:08 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 7CDD312030F; Mon, 8 Jul 2019 18:34:08 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id h18so12633139qtm.9; Mon, 08 Jul 2019 18:34:08 -0700 (PDT) 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=IWLOcMYgLdYzJFpA6aiNMUlE224uHjnnzUJKO+MdkpY=; b=bNYo6EgR+3H6Tzy60EytwN+V/Q23t1p2IEMEkNa+aVTrulBu9bMWYmngBiadSRDjrY vsEVddh72kku4UlxxoD0Jr1dugUsqCjIKF+wNbjjqYfT0RzrFqliOuSJwz/F367Ys1CU 6C7W5cisU2TlBiKlN5y32nNmU/BQ/OPI64qt1FrvW8i9vSEV4LYJFCp6qTrMKYuG2HqT RM9cFRdfWW8qF4X1fcIPpeW/kHmJ0PFbq80pVgJN2LAAnxSjSRF6o+zM4D2szAW1kt+O MrDQ5qAuofBjrSmJpdWNN+Y36EApRdh+5GA2C6pObRa6lErAuv63kAA2056ilTU209sM FfBg== 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=IWLOcMYgLdYzJFpA6aiNMUlE224uHjnnzUJKO+MdkpY=; b=QI3QkxTv3S7gN0RHbSGwxGa6wpOD1ujFczPSZcSxp6SZqnN71d/WA8TxybCc3RHyif Kif+wsSy8E66yjWynpn3qH4jUTQxl4/BV5uqgWsTf0ab3EIAUi4BHCEXiOjwyldJleor 9D2GukJY6kYxsNgcgKOHKLqCvveLd+2BRgh8LHrJP5WKmktFPSwYCu8IaCzVsTsr/z5S k0RtXAJZTobksH2ynMB1BnCtRI+waSl1BFlT4nBtqvaVyiDQN1qy/LoUcJ1Wdd5wuukr FTCiUc3UTFECnInXb02YQ7y/Bx0kdLAb5NOoyt9hwwu4qL9kByev2ZP5oKMzE4UmWWv3 qSFg== X-Gm-Message-State: APjAAAWlGFU6+33yWPH2+ai506HcXjxlYNlccy7LXmMIMnBCz8NWcjAN KoPmXlJ3F38Zg3PHNbZ7bdJZ40yhrEQjVzMcjvw= X-Google-Smtp-Source: APXvYqzXKDjPPaboyRFDGFDJ+cd3SQliAZEISSJ/gmUuAk+y87CwHp1tijLECwAtqUbVZaFypXMSiAT4PnyYbIXb75k= X-Received: by 2002:ac8:2b90:: with SMTP id m16mr16093450qtm.384.1562636047273; Mon, 08 Jul 2019 18:34:07 -0700 (PDT) MIME-Version: 1.0 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: From: Jen Linkova Date: Tue, 9 Jul 2019 11:33:55 +1000 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: "Manfredi (US), Albert E" , IPv6 Operations , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 01:34:14 -0000 On Tue, Jul 9, 2019 at 1:50 AM Mudric, Dusan (Dusan) wrote: > [Dusan] What if IPv4only client needs to initiate the session to IPv6only client? What is the solution for that use case? https://tools.ietf.org/html/rfc7755 mentioned before. IPv4-only client -- IPv4-enabled network--- SIIT translator ---- IPv6-only LAN --- IPv6-only server. Let's say your IPv4-only client needs to talk to the Ipv6-only server, ipv6-only.example.net. For this to happen the owner of the Ipv6-only server needs to configure the translator (SIIT box in the diagram above). The owner would create a DNS A RR for ipv6-only.example.net. - let's say, 192.0.2.2 Ipv6-only server would have an IPv6 address which has that IPv4 address encoded - for example, 2001:db8:1::192.0.2.2 That IPv4 address (or the prefix most likely) will be routed to the translator. So your Ipv4-only client sends a DNS request to resolve ipv6-only.example.net, gets 192.0.2.2 back, sends a packet to 192.0.2.2. The packet reaches the translator. The translator translates IPv4 packet to IPv6 packet and sends it to the server (note that the destination IPv6 address can be easily constructed as the translator knows the prefix and just adds the IPv4 address - 192.0.2.2 - to that prefix to get the destination IPv6 address. IPv6 source address is synthesised in the same way from the client IPv4 address). Here is a nice talk Tore Anderson gave at RIPE 7 years ago: https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf > > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the session, you'd > > have to have preconfigure something. > [Dusan] Where and how is this configuration done? On the translator which connects IPv6-only network to dual-stack/IPv4-only one. In general, when you need to let one protocol talk to another, you'd have a point (or the edge) where those two networks meet each other. Usually you'd have a box (or boxes) interconnecting them - quite often it's exactly the box you'd need to configure ;) -- SY, Jen Linkova aka Furry From nobody Mon Jul 8 19:01:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F5F12015A; Mon, 8 Jul 2019 19:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 idzcfiE7E0ZY; Mon, 8 Jul 2019 19:01:04 -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 108E0120091; Mon, 8 Jul 2019 19:01:04 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 641BA24B6DEFC1A68F52; Tue, 9 Jul 2019 03:01:02 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 9 Jul 2019 03:01:01 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.66]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Tue, 9 Jul 2019 10:00:57 +0800 From: Qin Wu To: Dave Thaler , Suresh Krishnan , int-area , 6man , dhcwg , V6 Ops List , "opsawg@ietf.org" , "softwires@ietf.org" Thread-Topic: [Int-area] AD sponsoring draft-thaler-iftype-reg-02 Thread-Index: AdU1923NF0Cl7DNmT0CLXrWIo6ASHg== Date: Tue, 9 Jul 2019 02:00:57 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA49CD81Enkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] [Int-area] AD sponsoring draft-thaler-iftype-reg-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 02:01:09 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA49CD81Enkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGF2ZToNCkdvb2Qgd29yayBmb3IgY2xlYW5pbmcgdXAgdGhlIG1lc3MgaW4gdGhlIElBTkEgcmVn aXN0cnksIHN1cHBvcnQgZm9yIHB1YmxpY2F0aW9uLg0KDQpPbmUgdGhpbmcgcHV6emxpbmcgbWUg YSBsb3QgaXMgd2hhdCBpcyB0aGUga2V5IGRpZmZlcmVuY2UgYmV0d2VlbiBpZlR5cGUgYW5kIFR1 bm5lbFR5cGUsIHN1cHBvc2UgSSB3YW50IHRvIHJlZ2lzdGVyIGEgbmV3IGVuY2Fwc3VsYXRpb24g aW50ZXJmYWNlLCBzaG91bGQgSSByZWdpc3RlciBpdCBhcyBJQU5BaWZUeXBlDQpPciBJQU5BdHVu bmVsdHlwZT8NClNlZSB0aGUgZm9sbG93aW5nIHR3byByZWdpc3RyaWVzOg0KaHR0cHM6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvaWFuYWlmdHlwZS1taWIvaWFuYWlmdHlwZS1taWINCmh0dHBz Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NtaS1udW1iZXJzL3NtaS1udW1iZXJzLnhodG1s DQpUaGUgcmVsYXRpb25zaGlwIGJld2VlbiBJQU5BaWZUeXBlIGFuZCBJQU5BdHVubmVsdHlwZSBp cyBub3QgY2xlYXIgdG8gbWUuDQpTZWUgdGhlIGZvbGxvd2luZyBxdW90ZWQgdGV4dCBpbiB0aGUg c2Vjb25kIHJlZ2lzdHJ5Og0KobANCkludGVybmV0LXN0YW5kYXJkIE1JQiAtIG1pYi0yLmludGVy ZmFjZS5pZlRhYmxlLmlmRW50cnkuaWZUeXBlLnR1bm5lbFR5cGUNCqGwDQpJcyB0dW5uZWx0eXBl IHN1YnR5cGUgb2YgaWZUeXBlPw0KQWxzbyBzZWUgWUFORyBtb2R1bGVzIHJlZ2lzdHJ5IGFuZCBZ QU5HIHBhcmFtZXRlciByZWdpc3RyeSBpbiBodHRwczovL3d3dy5pYW5hLm9yZy9wcm90b2NvbHMN CllBTkcgTW9kdWxlcw0KDQppYW5hLWJmZC10eXBlcyBZQU5HIE1vZHVsZTxodHRwczovL3d3dy5p YW5hLm9yZy9hc3NpZ25tZW50cy9pYW5hLWJmZC10eXBlcy9pYW5hLWJmZC10eXBlcy54aHRtbD4N Cg0KSW50ZXJuZXQgRHJhZnQgZHJhZnQtaWV0Zi1iZmQteWFuZy0xNzxodHRwczovL3d3dy5pYW5h Lm9yZy9nby90cmFja2VkLWRyYWZ0LWlldGYtYmZkLXlhbmctMTc+LCBSRkMgNTg4MDxodHRwczov L3d3dy5pYW5hLm9yZy9nby9yZmM1ODgwPg0KU2VlIEJGRCBEaWFnbm9zdGljIENvZGVzIGFuZCBC RkQgQXV0aGVudGljYXRpb24gVHlwZXMgcmVnaXN0cmllcy4NCg0KaWFuYS1jcnlwdC1oYXNoIFlB TkcgTW9kdWxlPGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2lhbmEtY3J5cHQtaGFz aC9pYW5hLWNyeXB0LWhhc2gueGh0bWw+DQoNClJGQyA3MzE3PGh0dHBzOi8vd3d3LmlhbmEub3Jn L2dvL3JmYzczMTc+DQpFeHBlcnQgUmV2aWV3IChFeHBlcnQ6IFVuYXNzaWduZWQpDQoNCmlhbmEt aGFyZHdhcmUgWUFORyBNb2R1bGU8aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaWFu YS1oYXJkd2FyZS9pYW5hLWhhcmR3YXJlLnhodG1sPg0KDQpSRkMgODM0ODxodHRwczovL3d3dy5p YW5hLm9yZy9nby9yZmM4MzQ4Pg0KU2VlIElBTkEtRU5USVRZLU1JQiBNSUIgbW9kdWxlLg0KDQpp YW5hLWlmLXR5cGUgWUFORyBNb2R1bGU8aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMv aWFuYS1pZi10eXBlL2lhbmEtaWYtdHlwZS54aHRtbD4NCg0KUkZDIDEyMTM8aHR0cHM6Ly93d3cu aWFuYS5vcmcvZ28vcmZjMTIxMz4sIFJGQyAyODYzPGh0dHBzOi8vd3d3LmlhbmEub3JnL2dvL3Jm YzI4NjM+LCBSRkMgNzIyNDxodHRwczovL3d3dy5pYW5hLm9yZy9nby9yZmM3MjI0Pg0KU2VlIGlm VHlwZSBkZWZpbml0aW9ucyByZWdpc3RyeS4NCg0KaWFuYS1yb3V0aW5nLXR5cGVzIFlBTkcgTW9k dWxlPGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2lhbmEtcm91dGluZy10eXBlcy9p YW5hLXJvdXRpbmctdHlwZXMueGh0bWw+DQoNClJGQyA4Mjk0PGh0dHBzOi8vd3d3LmlhbmEub3Jn L2dvL3JmYzgyOTQ+LCBSRkMgMjQ1MzxodHRwczovL3d3dy5pYW5hLm9yZy9nby9yZmMyNDUzPiwg UkZDIDI2Nzc8aHR0cHM6Ly93d3cuaWFuYS5vcmcvZ28vcmZjMjY3Nz4sIFJGQyAyODU4PGh0dHBz Oi8vd3d3LmlhbmEub3JnL2dvL3JmYzI4NTg+LCBSRkMgNDc2MDxodHRwczovL3d3dy5pYW5hLm9y Zy9nby9yZmM0NzYwPg0KU2VlIEFkZHJlc3MgRmFtaWx5IE51bWJlcnMgYW5kIFN1YnNlcXVlbnQg QWRkcmVzcyBGYW1pbHkgSWRlbnRpZmllcnMgKFNBRkkpIFZhbHVlcyByZWdpc3RyaWVzLg0KDQpp YW5hLXR1bm5lbC10eXBlIFlBTkcgTW9kdWxlPGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL2lhbmEtdHVubmVsLXR5cGUvaWFuYS10dW5uZWwtdHlwZS54aHRtbD4NCg0KUkZDIDQwODc8 aHR0cHM6Ly93d3cuaWFuYS5vcmcvZ28vcmZjNDA4Nz4sIEludGVybmV0IERyYWZ0IGRyYWZ0LWll dGYtc29mdHdpcmUtaWZ0dW5uZWwtMDc8aHR0cHM6Ly93d3cuaWFuYS5vcmcvZ28vdHJhY2tlZC1k cmFmdC1pZXRmLXNvZnR3aXJlLWlmdHVubmVsLTA3Pg0KU2VlIHR1bm5lbFR5cGUgcmVnaXN0cnkg KG1pYi0yLmludGVyZmFjZS5pZlRhYmxlLmlmRW50cnkuaWZUeXBlLnR1bm5lbFR5cGUpLg0KDQpZ QU5HIFBhcmFtZXRlcnMNCg0KWUFORyBNb2R1bGUgTmFtZXM8aHR0cHM6Ly93d3cuaWFuYS5vcmcv YXNzaWdubWVudHMveWFuZy1wYXJhbWV0ZXJzL3lhbmctcGFyYW1ldGVycy54aHRtbCN5YW5nLXBh cmFtZXRlcnMtMT4NCg0KUkZDIDYwMjA8aHR0cHM6Ly93d3cuaWFuYS5vcmcvZ28vcmZjNjAyMD4s IFJGQyA4NDA3PGh0dHBzOi8vd3d3LmlhbmEub3JnL2dvL3JmYzg0MDc+DQpSRkMgUmVxdWlyZWQN Cg0KV2h5IFlBTkcgcGFyYW1ldGVyIHJlZ2lzdHJ5IGlzIG5vdCBzdWZmaWNpZW50IHNpbmNlIFlB TkcgcGFyYW1ldGVyIHJlZ2lzdHJ5IHNlZW1zIHRvIGhhdmUgYWxyZWFkeSBpbmNsdWRlIFlBTkcg bW9kdWxlLg0KV2h5IG5vdCBjb25zb2xpZGF0ZSB0aGVzZSB0d28gaW50byBvbmU/DQoNCi1RaW4N CreivP7IyzogT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGF2 ZSBUaGFsZXINCreiy83KsbzkOiAyMDE5xOo31MI5yNUgNzoyMQ0KytW8/sjLOiBEYXZlIFRoYWxl ciA8ZHRoYWxlcj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+OyBTdXJlc2ggS3Jpc2hu YW4gPFN1cmVzaEBrYWxvb20uY29tPjsgaW50LWFyZWEgPGludC1hcmVhQGlldGYub3JnPjsgNm1h biA8aXB2NkBpZXRmLm9yZz47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IFY2IE9wcyBMaXN0IDx2 Nm9wc0BpZXRmLm9yZz47IG9wc2F3Z0BpZXRmLm9yZzsgc29mdHdpcmVzQGlldGYub3JnDQrW98zi OiBSZTogW09QU0FXR10gW0ludC1hcmVhXSBBRCBzcG9uc29yaW5nIGRyYWZ0LXRoYWxlci1pZnR5 cGUtcmVnLTAyDQoNCkZZSSwgZHJhZnQtdGhhbGVyLWlmdHlwZS1yZWctMDQgaXMgbm93IHBvc3Rl ZCBhbmQgaW5jb3Jwb3JhdGVzIGNoYW5nZXMgYmFzZWQgb24NCmZlZWRiYWNrIGZyb20gTWVkLCBU b20sIFN1cmVzaCwgYW5kIG90aGVycy4NCg0KRGlmZnMgZnJvbSAtMDIgY2FuIGJlIHNlZW4gYXQN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LXRoYWxlci1pZnR5cGUt cmVnLTAyLnR4dCZ1cmwyPWRyYWZ0LXRoYWxlci1pZnR5cGUtcmVnLTA0LnR4dA0KDQpEYXZlDQoN CkZyb206IFNvZnR3aXJlcyA8c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3 aXJlcy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIERhdmUgVGhhbGVyDQpTZW50OiBG cmlkYXksIEp1bHkgNSwgMjAxOSAxMjoxNyBQTQ0KVG86IHRvbSBwZXRjaCA8aWV0ZmNAYnRjb25u ZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+OyBTdXJlc2ggS3Jpc2huYW4gPFN1 cmVzaEBrYWxvb20uY29tPG1haWx0bzpTdXJlc2hAa2Fsb29tLmNvbT4+OyBpbnQtYXJlYSA8aW50 LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOmludC1hcmVhQGlldGYub3JnPj47IDZtYW4gPGlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+PjsgZGhjd2cgPGRoY3dnQGlldGYub3JnPG1haWx0 bzpkaGN3Z0BpZXRmLm9yZz4+OyBWNiBPcHMgTGlzdCA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2 b3BzQGlldGYub3JnPj47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsg c29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW1NvZnR3aXJlc10gW0ludC1hcmVhXSBBRCBzcG9uc29yaW5nIGRyYWZ0LXRoYWxlci1pZnR5 cGUtcmVnLTAyDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkaGN3 ZyA8ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZz4+ IE9uIEJlaGFsZiBPZiB0b20gcGV0Y2gNClNlbnQ6IEZyaWRheSwgSnVuZSAxNCwgMjAxOSA5OjI4 IEFNDQpUbzogU3VyZXNoIEtyaXNobmFuIDxTdXJlc2hAa2Fsb29tLmNvbTxtYWlsdG86U3VyZXNo QGthbG9vbS5jb20+PjsgaW50LWFyZWEgPGludC1hcmVhQGlldGYub3JnPG1haWx0bzppbnQtYXJl YUBpZXRmLm9yZz4+OyA2bWFuIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPj47 IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+PjsgVjYgT3BzIExp c3QgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+OyBvcHNhd2dAaWV0Zi5v cmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47IHNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86c29m dHdpcmVzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkaGN3Z10gW0ludC1hcmVhXSBBRCBzcG9u c29yaW5nIGRyYWZ0LXRoYWxlci1pZnR5cGUtcmVnLTAyDQoNCg0KDQpTdXJlc2gNCg0KDQoNClRo ZSBjb25jZXJuIEkgaGF2ZSBpcyB0aGF0IGl0IG11ZGRpZXMgdGhlIHdhdGVycyBmdXJ0aGVyIG9u IHRoZSBzdGFuZGluZyBvZiB0dW5uZWxzIHNvIHdoaWxlIEkgdGhpbmsgdGhhdCBpdHMgcHJvcG9z YWxzIGZvciBpZlR5cGUgcGVyIHNlIGFyZSBmaW5lLCBJIHdvdWxkIGxpa2UgaXQgdG8gbWFrZSBl eHBsaWNpdCB0aGF0IHR1bm5lbHMgYXJlIG91dC1vZi1zY29wZSBhdCB0aGlzIHRpbWUuDQoNCg0K DQpUdW5uZWxzIGFyZSBjZXJ0YWlubHkgbm90IG91dC1vZi1zY29wZS4gIFRoZXJloa9zIHR3byBl eGlzdGluZyByZWdpc3RyaWVzIChpbnRlcmZhY2UgdHlwZXMgYW5kIHR1bm5lbCB0eXBlcyksIGFu ZCB0aGlzIGRyYWZ0IGRvY3VtZW50cyBleGlzdGluZyByZWdpc3RyYXRpb24gcHJvY2VzcywgYW5k IHNvbWUgcHJvY2VzcyBjbGFyaWZpY2F0aW9ucyB0byBhZGRyZXNzIHBvaW50cyBvZiBwcm9jZXNz IGNvbmZ1c2lvbiBhbmQgZWFzZSBwcm9jZXNzIGZyaWN0aW9uIHRvZGF5Lg0KDQoNCg0KDQoNCkkg aGF2ZSBiZWVuIHRyeWluZyB0byByZWNvbmNpbGUgdGhlIHdvcmtpbmdzIG9mIHNvZnR3aXJlLCBp biBjcmVhdGluZyBhIHR1bm5lbCBZQU5HIG1vZHVsZSwgd2l0aCB0aGUgZXhpc3RpbmcgSUFOQSBz dHJ1Y3R1cmUgYW5kIGZhaWxpbmcuICBJIGJlbGlldmUgdGhhdCBpcyBiZWNhdXNlIHRoZSBjdXJy ZW50IHN0YXR1cyBvZiB0dW5uZWxzIGlzIHVuY2xlYXIuICBUaHVzIHRoZSBzb2Z0d2lyZSBJLUQg cmVmZXJzIHRvIGEgcmVnaXN0cnkgdGhhdCBkb2VzIG5vdCBleGlzdA0KDQoNCg0KWWVzIGl0IGRv ZXMuICAgVGhlIHNvZnR3YXJlIEktRCBkb2VzIG5vdCBjcmVhdGUgYW55IG5ldyByZWdpc3RyeS4g ICBJdCBvbmx5IGNyZWF0ZXMgYW5vdGhlciBmb3JtYXQgZm9yIHJldHJpZXZpbmcgdGhlIGNvbnRl bnRzIG9mIGFuIGV4aXN0aW5nIHJlZ2lzdHJ5LiAgTWFueSByZWdpc3RyaWVzIGFyZSByZXRyaWV2 YWJsZSBpbiBtdWx0aXBsZSBmb3JtYXRzIChYTUwsIGV4Y2VsLCB0eHQsIGV0Yy4pLiAgIFRoaXMg cmVnaXN0cnkgaXMgbm8gZGlmZmVyZW50Lg0KDQoNCg0KV2hhdCBJIGNhbiBkbyBpcyBhZGQgYSBw YXJhZ3JhcGggZXhwbGFpbmluZyB0aGUgdXNlIG9mIG11bHRpcGxlIGZvcm1hdHMgZm9yIHRoZSBp bnRlcmZhY2UgdHlwZSBhbmQgdHVubmVsIHR5cGUgcmVnaXN0cmllcywgdG8gbWFrZSBpdCBjbGVh ciB0aGF0IGVhY2ggZm9ybWF0IGlzIG5vdCBhIHNlcGFyYXRlIHJlZ2lzdHJ5LCBqdXN0IGxpa2Ug Z2V0dGluZyB0aGUgVENQIHBvcnQgcmVnaXN0cnkgaW4gWE1MIHZzIGV4Y2VsIGlzIG5vdCB0d28g ZGlmZmVyZW50IHJlZ2lzdHJpZXMuDQoNCg0KDQpEYXZlDQoNCg0KDQooYXMgc3VjaCkgYWx0aG91 Z2ggdGhlIFVSTCB0aGF0IHRoZSBzb2Z0d2lyZSBJLUQgZG9lcy4gSSB0aGluayB0aGUgdGltaW5n IHVuZm9ydHVuYXRlIGluIHRoYXQgSU1ITyB0aGUgc29mdHdpcmVzIEktRCB3aWxsIGdldCBwcmVz c2VkIGFoZWFkIGJlZm9yZSB0aGlzIHdvcmsgY2FuIGNvbXBsZXRlLCBzbyBxdWl0ZSB3aGF0IHRo aXMgSS1EIHRoZW4gc2F5cyBhYm91dCB0dW5uZWxzIHdpbGwgYmUgY29sb3VyZWQgYnkgd2hhdCB0 aGVuIGV4aXN0cyBmb3IgdHVubmVscy4NCg0KDQoNClNvIHRoaXMgSS1EIHNob3VsZCBtYWtlIGNs ZWFyIHdoYXQgYSB0dW5uZWwgaXMsIHdoZW4gaXQgaXMgbm90IGFuIGludGVyZmFjZSwgYnV0IG90 aGVyd2lzZSBkZWNsYXJpbmcgdHVubmVscyBvdXQtb2Ytc2NvcGUsIGZvciBhIGZ1dHVyZSBJLUQg dG8gZG8gYSBjb21wYXJhYmxlIGpvYiBmb3IgdHVubmVscywgc2V0dGluZyB1cCBhIHR1bm5lbCBy ZWdpc3RyeSBmcm9tIHdoaWNoIE1JQiBtb2R1bGVzLCBZQU5HIG1vZHVsZXMgYW5kIGFueXRoaW5n IGVsc2UgY2FuIGJlIGRlcml2ZWQgKGFzIGxvbmcgYXMgdGhlIHJlbGV2YW50IGRhdGEgaXMgc3Vw cGxpZWQgLSBTTUkgbmVlZHMgaW50ZWdlcnMsIFlBTkcgZG9lcyBub3QsIHdoaWNoIEktRHMgZG8g bm90IGFsd2F5cyByZWNvZ25pc2UgYWx0aG91Z2ggdGhlIERlc2lnbmF0ZWQgRXhwZXJ0cyBjYW4g dGFrZSBjYXJlIG9mIHRoYXQpLg0KDQoNCg0KRmluYWxseSwgd2hlbiBJIGZpcnN0IGVuY291bnRl cmVkIHRoaXMgSS1EIEkgYXNrZWQgb24gTkVUQ09ORiBhbmQgTkVUTU9EIFdHIGxpc3RzIGlmIGFu eW9uZSBrbmV3IG9mIGl0LCB3aGVyZSBpdCB3YXMgYmVpbmcgd29ya2VkIG9uIGFuZCBnb3Qgbm8g cmVwbHkgLSB3aGljaCBzdXJwcmlzZWQgbWUuICBJIG5vdGUgdGhhdCB5b3UgaGF2ZSBub3QgY29w aWVkIHRoZW0gYWx0aG91Z2ggdGhleSB3ZXJlIGludm9sdmVkIGluIG1ha2luZyB0aGUgaW50ZXJm YWNlIHR5cGUgcmVnaXN0cnkgd2hhdCBpdCBjdXJyZW50bHkgaXMgd2hlbiBjcmVhdGluZyB0aGUg WUFORyBtb2R1bGUgZm9yIGludGVyZmFjZSB0eXBlcy4gIEkgd29uZGVyIGlmIG90aGVyIFdHIGhh dmUgYW4gaW50ZXJlc3QsIENDQU1QIG9yIFRFQVMgcGVyaGFwcy4gIEkgYWdyZWUgdGhhdCBpbnQt YXJlYSBpcyB0aGUgV0cgYmVzdCBlcXVpcHBlZCB0byB3b3JrIG9uIGl0IGFuZCB0aGF0IGl0IG5l ZWRzIHdvcmtpbmcgb24uDQoNCg0KDQpUb20gUGV0Y2gNCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCg0KRnJvbTogIlN1cmVzaCBLcmlzaG5hbiIgPFN1cmVzaEBrYWxvb20uY29t PG1haWx0bzpTdXJlc2hAa2Fsb29tLmNvbT4+DQoNClRvOiAiaW50LWFyZWEiIDxpbnQtYXJlYUBp ZXRmLm9yZzxtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmc+PjsgIjZtYW4iIDxpcHY2QGlldGYub3Jn PG1haWx0bzppcHY2QGlldGYub3JnPj47ICJkaGN3ZyINCg0KPGRoY3dnQGlldGYub3JnPG1haWx0 bzpkaGN3Z0BpZXRmLm9yZz4+OyAiVjYgT3BzIExpc3QiIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86 djZvcHNAaWV0Zi5vcmc+PjsgPG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3Jn Pj47IDxzb2Z0d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZz4+DQoNClNl bnQ6IFdlZG5lc2RheSwgSnVuZSAxMiwgMjAxOSA3OjIyIFBNDQoNCg0KDQpIaSBhbGwsDQoNCiAg SSB3b3VsZCBsaWtlIHRvIEFEIHNwb25zb3IgdGhlIGZvbGxvd2luZyBkcmFmdCB0aGF0IHByb3Zp ZGVzIGd1aWRlbGluZXMgZm9yIGRlZmluaXRpb24gb2YgbmV3IGludGVyZmFjZSB0eXBlcyBpbiB0 aGUgSUFOQSBJZlR5cGUgcmVnaXN0cmllcw0KDQoNCg0KaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGZHJhZnQtdGhhbGVyLWlmdHlwZS1yZWctMDImYW1wO2RhdGE9MDIlN0MwMSU3Q2R0 aGFsZXIlNDBtaWNyb3NvZnQuY29tJTdDYmQ5MDgwZjY2NTA2NGY1NjRkMzYwOGQ2ZjBlNTVhODgl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTYxMjY1MjAy NzYzNzA3JmFtcDtzZGF0YT1ITTVhc1hPRm5TdXpQYUNSNGs0a29wcXNJSExMZG5xWjdQRHV1OGhQ Sk00JTNEJmFtcDtyZXNlcnZlZD0wPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRy YWZ0LXRoYWxlci1pZnR5cGUtcmVnLTAyJmRhdGE9MDIlN0MwMSU3Q2R0aGFsZXIlNDBtaWNyb3Nv ZnQuY29tJTdDN2YwYmIwZTEzYWQ0NDRmZmJmZTIwOGQ3MDE3ZGQ0Y2QlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTc5NTEyMjg4OTEwMDA4JnNkYXRhPU9p dTNCTG9QdmtiY05RTjRYQTVpaDdZbm5XZWI5YnpuN1dMUDRuSiUyRlNDTSUzRCZyZXNlcnZlZD0w Pg0KDQoNCg0KSWYgeW91IGhhdmUgYW55IGNvbmNlcm5zIGVpdGhlciB3aXRoIHRoZSBjb250ZW50 cyBvZiB0aGUgZHJhZnQsIG9yIGFib3V0IG1lIEFEIHNwb25zb3JpbmcgaXQgcGxlYXNlIGxldCBt ZSBrbm93IGJlZm9yZSAyMDE5LzA2LzI2Lg0KDQoNCg0KVGhhbmtzDQoNClN1cmVzaA0KDQoNCg0K Tk9URTogSSBoYXZlIENDZWQ6IGFsbCB0aGUgd29ya2luZyBncm91cHMgdGhhdCBJIHRob3VnaHQg Y291bGQgYmUgcG90ZW50aWFsbHkgaW50ZXJlc3RlZCBpbiB0aGlzIHdvcmsuIElmIHlvdSB0aGlu ayBJIGhhdmUgbWlzc2VkIG91dCBzb21lIFdHKHMpIHBsZWFzZSBsZXQgbWUga25vdy4NCg0KDQoN Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tLS0tLS0tDQoNCg0KDQoNCg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IEludC1hcmVhIG1h aWxpbmcgbGlzdA0KDQo+IEludC1hcmVhQGlldGYub3JnPG1haWx0bzpJbnQtYXJlYUBpZXRmLm9y Zz4NCg0KPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ3d3c8aHR0cHM6Ly93d3c+Lg0KDQo+IGlldGYub3JnJTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGaW50LWFyZWEmYW1wO2RhdGE9MDIlN0MwMSU3Q2R0aGFsZXIlNDANCg0K PiBtaWNyb3NvZnQuY29tJTdDYmQ5MDgwZjY2NTA2NGY1NjRkMzYwOGQ2ZjBlNTVhODglN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhDQoNCj4gYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTYxMjY1MjAy NzYzNzA3JmFtcDtzZGF0YT16bno3RVoxcSUyRndJUVVKQw0KDQo+IGdZWlRXZlkySDRDN3RONnFG aEp1YkNWV3hXemMlM0QmYW1wO3Jlc2VydmVkPTANCg0KPg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KZGhjd2cgbWFpbGluZyBsaXN0DQoN CmRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGZGhjd2cmYW1wO2RhdGE9MDIlN0MwMSU3Q2R0 aGFsZXIlNDBtaWNyb3NvZnQuY29tJTdDYmQ5MDgwZjY2NTA2NGY1NjRkMzYwOGQ2ZjBlNTVhODgl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTYxMjY1MjAy NzYzNzA3JmFtcDtzZGF0YT1PSnZiUkR6JTJGQ0lsVkYzaFdSMzBLQ3MwY1JnaTlLbXRuWUxIS2JI U2VKemMlM0QmYW1wO3Jlc2VydmVkPTA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUy Rmxpc3RpbmZvJTJGZGhjd2cmZGF0YT0wMiU3QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20l N0M3ZjBiYjBlMTNhZDQ0NGZmYmZlMjA4ZDcwMTdkZDRjZCU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY5Nzk1MTIyODg5MTk5OTgmc2RhdGE9JTJGSVhPalhM S1E5Q2lxMmRRTmQ1ekY2OWJWcXB2SG9nSk82QjlHZnJsTnRnJTNEJnJlc2VydmVkPTA+DQo= --_000_B8F9A780D330094D99AF023C5877DABAA49CD81Enkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dave:

Good work for cleaning up the mess in the IANA registry, support = for publication.

One thing puzzling me a lot is what is t=
he key difference between ifType and TunnelType, suppose I want to register=
 a new encapsulation interface, should I register it as IANAifType

Or IANAtunneltype?

See the following two registries:

https://www.iana.org/assignments/iana= iftype-mib/ianaiftype-mib

https://www.iana.org/assignment= s/smi-numbers/smi-numbers.xhtml

The relationship beween IANAifType and IANAtunneltype is not clea= r to me.

See the following quot= ed text in the second registry:

=A1=B0

Internet-standard MIB = - mib-2.interface.ifTable.ifEntry.ifType.tunnelType

=A1=B0

Is tunneltype subtype of ifType?

Also see YANG modules registry and YANG parameter registry in http= s://www.iana.org/protocols

YANG Modules

iana= -bfd-types YANG Module

Internet Draft draft-ietf-bfd-yang-17, RFC 5880 
See BFD Diagnostic Codes and BFD Authentication Types r= egistries.

ia= na-crypt-hash YANG Module

RFC 7317 
Expert Review (Expert: Unassigned)

iana-h= ardware YANG Module

RFC 8348 
See IANA-ENTITY-MIB MIB module.

iana-if-= type YANG Module

RFC 1213, RFC 2863, RFC 7224 
See ifType definitions registry.

iana-routing-types YANG Module

RFC 8294, RFC 2453, RFC 2677, RFC 2858, RFC 4760 
See Address Family Numbers and Subsequent Address Famil= y Identifiers (SAFI) Values registries.

= iana-tunnel-type YANG Module

RFC 4087, Internet Draft draft-ietf-softwire-iftunnel-07 
See tunnelType registry (mib-2.interface.ifTable.ifEntr= y.ifType.tunnelType).

YANG Parameters

<= span style=3D"color:#0069D6;border:none windowtext 1.0pt;padding:0cm;text-d= ecoration:none">YANG Module Names

RFC 6020, RFC 8407 
RFC Required

Why YANG parameter registry is not sufficient since YANG paramete= r registry seems to have already include YANG module.

Why not consolidate these two into one?

 

-Qin

=B7=A2=BC=FE=C8=CB:= OPSAWG [mailto:opsawg-bounces@ietf.org] =B4=FA=B1=ED Dave Thaler
=B7=A2=CB=CD=CA=B1=BC=E4:= 2019=C4=EA7=D4=C29=C8=D5 7:21
=CA=D5=BC=FE=C8=CB: Dave Thaler <dthaler=3D40microsoft.com@dmarc.ietf.org>; Sures= h Krishnan <Suresh@kaloom.com>; int-area <int-area@ietf.org>; 6= man <ipv6@ietf.org>; dhcwg <dhcwg@ietf.org>; V6 Ops List <v6= ops@ietf.org>; opsawg@ietf.org; softwires@ietf.org
=D6=F7=CC=E2: Re: [OPSAWG] [Int-area] AD sponsoring draft-thaler-iftype-reg-02

 

FYI, dr= aft-thaler-iftype-reg-04 is now posted and incorporates changes based on

feedbac= k from Med, Tom, Suresh, and others.

&n= bsp;

Diffs f= rom -02 can be seen at

https://tools.ietf.org/rfcdiff?url= 1=3Ddraft-thaler-iftype-reg-02.txt&url2=3Ddraft-thaler-iftype-reg-04.tx= t

&n= bsp;

Dave

&n= bsp;

From: Softwires <sof= twires-bounces@ietf.org> On Behalf Of Dave Thaler
Sent: Friday, July 5, 2019 12:17 PM
To: tom petch <ietfc@btcon= nect.com>; Suresh Krishnan <= Suresh@kaloom.com>; int-area <int-area@ietf.org>; 6man <ipv6= @ietf.org>; dhcwg <dhcwg@ietf.org>; V6 Ops= List <v6ops@ietf.org>; opsawg@ietf.org; softwires@ietf.org
Subject: Re: [Softwires] [Int-area] AD sponsoring draft-thaler-iftyp= e-reg-02

 

 

-----Original Message-----
From: dhcwg <dhcwg-bounces@iet= f.org> On Behalf Of tom petch
Sent: Friday, June 14, 2019 9:28 AM
To: Suresh Krishnan <Suresh@kaloom.= com>; int-area <int-area@iet= f.org>; 6man <ipv6@ietf.org&= gt;; dhcwg <dhcwg@ietf.org>; V6 Ops List <v6ops@ietf.org>; = opsawg@ietf.org; softwires@ietf.o= rg
Subject: Re: [dhcwg] [Int-area] AD sponsoring draft-thaler-iftype-reg-02

 

Suresh

 

The concern I have is that it muddies the waters further on the standing o= f tunnels so while I think that its proposals for ifType per se are fine, I= would like it to make explicit that tunnels are out-of-scope at this time.

&= nbsp;

Tunnel= s are certainly not out-of-scope.  There=A1=AFs two existing registrie= s (interface types and tunnel types), and this draft documents existing reg= istration process, and some process clarifications to address points of process confusion and ease process friction today.

&= nbsp;

 

I have been trying to reconcile the workings of softwire, in creating a tu= nnel YANG module, with the existing IANA structure and failing.  I bel= ieve that is because the current status of tunnels is unclear.  Thus the softwire I-D refers to a registry that = does not exist

 

Yes it does.   The= software I-D does not create any new registry.   It only creates= another format for retrieving the contents of an existing registry.  = Many registries are retrievable in multiple formats (XML, excel, txt, etc.).   This registry is no different.

 

What I can do is add a parag= raph explaining the use of multiple formats for the interface type and tunn= el type registries, to make it clear that each format is not a separate reg= istry, just like getting the TCP port registry in XML vs excel is not two different registries.

 

Dave

 

(as such) although the URL that the softwire I-D does. I think the timing = unfortunate in that IMHO the softwires I-D will get pressed ahead before th= is work can complete, so quite what this I-D then says about tunnels will be coloured by what then exists for tunne= ls.

 

So this I-D should make clear what a tunnel is, when it is not an interfac= e, but otherwise declaring tunnels out-of-scope, for a future I-D to do a c= omparable job for tunnels, setting up a tunnel registry from which MIB modules, YANG modules and anything else c= an be derived (as long as the relevant data is supplied - SMI needs integer= s, YANG does not, which I-Ds do not always recognise although the Designate= d Experts can take care of that).

 

Finally, when I first encountered this I-D I asked on NETCONF and NETMOD W= G lists if anyone knew of it, where it was being worked on and got no reply= - which surprised me.  I note that you have not copied them although they were involved in making the interface t= ype registry what it currently is when creating the YANG module for interfa= ce types.  I wonder if other WG have an interest, CCAMP or TEAS perhap= s.  I agree that int-area is the WG best equipped to work on it and that it needs working on.

 

Tom Petch

 

----- Original Message -----=

From: "Suresh Krishnan&= quot; <Suresh@kaloom.com>

To: "int-area" <= ;int-area@ietf.org>; "6man" <ipv6@ietf.org>; "dhcwg"

<dhcwg@ietf.= org>; "V6 Ops List" <v6ops@ietf.org= >; <opsawg@ietf.org>; <sof= twires@ietf.org>

Sent: Wednesday, June 12, 20= 19 7:22 PM

 

Hi all,

  I would like to AD sp= onsor the following draft that provides guidelines for definition of new in= terface types in the IANA IfType registries

 

https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftoo= ls.ietf.org%2Fhtml%2Fdraft-thaler-iftype-reg-02&amp;data=3D02%7C01%7Cdt= haler%40microsoft.com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af= 91ab2d7cd011db47%7C1%7C0%7C636961265202763707&amp;sdata=3DHM5asXOFnSuzP= aCR4k4kopqsIHLLdnqZ7PDuu8hPJM4%3D&amp;reserved=3D0

 

If you have any concerns eit= her with the contents of the draft, or about me AD sponsoring it please let= me know before 2019/06/26.

 

Thanks

Suresh

 

NOTE: I have CCed: all the w= orking groups that I thought could be potentially interested in this work. = If you think I have missed out some WG(s) please let me know.

 

 

 

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

--------

 

 

> _______________________= ________________________

> Int-area mailing list

> Int-are= a@ietf.org

> https://nam06.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.<= /span>

> ietf.org%2Fmailman%2Fli= stinfo%2Fint-area&amp;data=3D02%7C01%7Cdthaler%40

> microsoft.com%7Cbd9080f= 665064f564d3608d6f0e55a88%7C72f988bf86f141af91a

> b2d7cd011db47%7C1%7C0%7= C636961265202763707&amp;sdata=3Dznz7EZ1q%2FwIQUJC

> gYZTWfY2H4C7tN6qFhJubCV= WxWzc%3D&amp;reserved=3D0

> =

 

____________________________= ___________________

dhcwg mailing list

dhcwg@ietf.org<= /span>

https= ://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org= %2Fmailman%2Flistinfo%2Fdhcwg&amp;data=3D02%7C01%7Cdthaler%40microsoft.= com%7Cbd9080f665064f564d3608d6f0e55a88%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C636961265202763707&amp;sdata=3DOJvbRDz%2FCIlVF3hWR30KCs0cRgi9K= mtnYLHKbHSeJzc%3D&amp;reserved=3D0

--_000_B8F9A780D330094D99AF023C5877DABAA49CD81Enkgeml513mbxchi_-- From nobody Tue Jul 9 13:03:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE4212001A; Tue, 9 Jul 2019 13:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=avaya365.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 B64cEpsWlSB9; Tue, 9 Jul 2019 13:03:32 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 19CB512001B; Tue, 9 Jul 2019 13:03:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EHAABi8iRd/wUHmMZjAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQEBgVUCAQEBAQELAYEUL1BtdQQzCoQSgV+BaAOOSoJbmHQUgRA?= =?us-ascii?q?DGBchBAkBAQENARgBCQcEAgEBAoECgzwCF4ItIzYHDgEDAQEBBAEBAQEEAQICa?= =?us-ascii?q?YUDOQyCeE0vCgIvAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQUCDQIkBQwSAQEYAQEBAQIBAQEQEQQGEwEBLAQHAQQHAgICAQgNBAQBAQEgA?= =?us-ascii?q?QYDAgICGQwLFAkIAgQBDQUIBg0HgwGBagMODwECAgqhPQKBCDCIXwEBcH8zGgK?= =?us-ascii?q?CXQEBBXU9ARNBgnkYggsHCQUEAYEqAYhBgX+BHheBQT4ma0aCTD6CYQEBAgEBF?= =?us-ascii?q?oELCQESAQkYBBEKCwEJCAmCQzKCJot5CAEcL4IjhH2BCoddjRVtCQKCF4Mrgyu?= =?us-ascii?q?BQok6gk6CLG2KLQOKN40wh0GMFYNoAgICAgQFAg4BAQWBVwkpZ3FwFTuCbAmCO?= =?us-ascii?q?AwXg06EWTuFP3IBARMdd4tsgSIBgRULAQE?= X-IPAS-Result: =?us-ascii?q?A2EHAABi8iRd/wUHmMZjAxkBAQEBAQEBAQEBAQEHAQEBAQE?= =?us-ascii?q?BgVUCAQEBAQELAYEUL1BtdQQzCoQSgV+BaAOOSoJbmHQUgRADGBchBAkBAQENA?= =?us-ascii?q?RgBCQcEAgEBAoECgzwCF4ItIzYHDgEDAQEBBAEBAQEEAQICaYUDOQyCeE0vCgI?= =?us-ascii?q?vAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDQIkBQwSA?= =?us-ascii?q?QEYAQEBAQIBAQEQEQQGEwEBLAQHAQQHAgICAQgNBAQBAQEgAQYDAgICGQwLFAk?= =?us-ascii?q?IAgQBDQUIBg0HgwGBagMODwECAgqhPQKBCDCIXwEBcH8zGgKCXQEBBXU9ARNBg?= =?us-ascii?q?nkYggsHCQUEAYEqAYhBgX+BHheBQT4ma0aCTD6CYQEBAgEBFoELCQESAQkYBBE?= =?us-ascii?q?KCwEJCAmCQzKCJot5CAEcL4IjhH2BCoddjRVtCQKCF4MrgyuBQok6gk6CLG2KL?= =?us-ascii?q?QOKN40wh0GMFYNoAgICAgQFAg4BAQWBVwkpZ3FwFTuCbAmCOAwXg06EWTuFP3I?= =?us-ascii?q?BARMdd4tsgSIBgRULAQE?= X-IronPort-AV: E=Sophos;i="5.63,471,1557201600"; d="scan'208,217";a="355775122" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Jul 2019 16:03:29 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 16:03:29 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by AZ-US1EXHC03.global.avaya.com (135.11.85.14) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 9 Jul 2019 16:03:28 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (104.47.33.57) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Tue, 9 Jul 2019 15:03:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gGZF21cO+MX2jbLbnRQXgi4XtNuAvW62GZTYQ/dfous=; b=j9SiSqJLu3J+HkUeVb65kAhP/IW+OssTJW+lrWKFoWM2Rb6j5dJvtW0WY9DdSF5YTzsBbhzE7MxFQYl94s+CxSPL/Z0U9vb8cVeiXpLg6fcPOB2hz9tcXNDT1YSXYwDHsqLx0OE6GGji89Ap5uBybWMOzjTNYF6R3c9n88YHa7A= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2316.namprd15.prod.outlook.com (20.176.70.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Tue, 9 Jul 2019 20:03:26 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2052.020; Tue, 9 Jul 2019 20:03:26 +0000 From: "Mudric, Dusan (Dusan)" To: JORDI PALET MARTINEZ , "IPv6 Operations" CC: 6man <6man@ietf.org> Thread-Topic: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AQHVNdY0X+iUuSrLm0aGNbcL2H6B/qbCsnEA Date: Tue, 9 Jul 2019 20:03:26 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> In-Reply-To: <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19a16975-d1cb-48e0-021d-08d704a88109 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DM6PR15MB2316; x-ms-traffictypediagnostic: DM6PR15MB2316: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(136003)(39860400002)(396003)(199004)(189003)(13464003)(99286004)(256004)(66574012)(66556008)(26005)(606006)(33656002)(7736002)(66946007)(64756008)(966005)(76116006)(66446008)(66616009)(52536014)(66476007)(9326002)(76176011)(5024004)(5660300002)(14444005)(6506007)(53546011)(102836004)(55236004)(71200400001)(66066001)(71190400001)(53936002)(476003)(8936002)(14454004)(186003)(478600001)(7696005)(81156014)(8676002)(11346002)(55016002)(81166006)(6246003)(486006)(9686003)(236005)(25786009)(2906002)(54896002)(446003)(6306002)(4326008)(6436002)(68736007)(74316002)(790700001)(229853002)(3846002)(6116002)(53386004)(99936001)(316002)(86362001)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2316; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kULoPpWpAMcyYBuPCUWY5rKKBhfiXQgQc/JGlmVzZNeGJVaecUSjgiKhm8VUo1U+S/mqZSgSUaBW9Qe9qqvceumzspVidFSjSzI6HUoWM2LlOwphgVzQBWQH81P7Mo1iT7g4sAE3aypGZ/8lLf1CqE944x7L5xS7FelL17WgKCgOn1B8XiPdWUkasd2GBn9rbFG141FDfoRAhaOCoShK6N+mHhaTL/hPhc/eknfi1TuacZoFA/ed5tFEAIOeV+GnNO6OavXFo4IvMDFQKU7jwpEFRUkXXtGSASDBZoSBAb3yvNaTE2By4tZctPOweMifc2mN0ewrdJ3N7LZPMsENkQuTah4uWV6fwJBRkXOwJyCdSBwctHvkzC97lD119efSpyCfUl4ID9SHLoB45j5tLBvNOhCFM3VHQ1hHBMyqsLg= Content-Type: multipart/mixed; boundary="_004_DM6PR15MB2506C6CC4E3853915F6AD1DEBBF10DM6PR15MB2506namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 19a16975-d1cb-48e0-021d-08d704a88109 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 20:03:26.1033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2316 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 20:03:37 -0000 --_004_DM6PR15MB2506C6CC4E3853915F6AD1DEBBF10DM6PR15MB2506namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR15MB2506C6CC4E3853915F6AD1DEBBF10DM6PR15MB2506namp_" --_000_DM6PR15MB2506C6CC4E3853915F6AD1DEBBF10DM6PR15MB2506namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQoNCkFyZSB5b3Ugc2F5aW5nIHlvdXIgZHJhZnQgIOKAnDQ2NFhMQVQgT3B0aW1p emF0aW9u4oCdIHdpbGwgcHJvdmlkZSBJUHY0b25seSBhcHAgdG8gSVB2Nm9ubHkgYXBwIGNvbW11 bmljYXRpb24gbGlrZSB0aGlzPw0KDQoNCiAgICAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAg Li0tLS0tLg0KICAgICAgICAgICAgICAgICAgfCBJUHY2ICB8ICAgIC8gICAgICAgXA0KICAgICAg Li0tLS0tLiAgICAgfCAgQ0UgICB8ICAgLyAgSVB2Ni0gIFwgICAgIC4tLS0tLS4NCiAgICAgLyBJ UHY0LSBcICAgIHwgIG9yICAgKy0tKCAgIG9ubHkgICAgKS0tLSggTkFUNjQgKQ0KICAgIC8gIG9u bHkgICBcICAgfCAgVUUgICB8ICAgXCAgQWNjZXNzIC9cICAgIGAtLS0tLScNCiAgICggIFNtYXJ0 VFYgICktLSsgICAgICAgfCAgICBcICAgICAgIC8gIFwNCiAgICBcICAgU1RCICAgLyAgIHwgd2l0 aCAgfCAgICAgYC0tKy0tJyAgICBcICAgLi0tLS0tLg0KICAgICBcIFZvSVAgIC8gICAgfCBOQVQ0 NiB8ICAgICAgICB8ICAgICAgICBcIC8gICAgICAgXA0KICAgICAgYC0tLS0tJyAgICAgfCBDTEFU ICB8ICAgICstLS0rLS0tLSsgICAgLyAgSVB2NiAgIFwgICAgICAuLS0rLS0uDQogICAgICAgICAg ICAgICAgICB8ICAgICAgIHwgICAgfCAgRE5TLyAgfCAgICggIEludGVybmV0IClJUHY2LyBJUHY2 LSBcDQogICAgICAgICAgICAgICAgICArLS0tLS0tLSsgICAgfCAgRE5TNjQgfCAgICBcICAgICAg ICAgLy0tLS0vICBvbmx5ICAgXA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLSsgICAgIFwgICAgICAgLyAgICAoICAgICAgICAgICApDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGAtLS0tLScgICAgICBcICBBUFAgICAgLw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFwgICAgICAgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBgLS0tLS0nDQogICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIElQ djQgdG8gSVB2NiBmbG93IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCg0KV2hhdCBkaWQgbm90 IHdvcmsgc28gZmFyIGFuZCB3aGF0IGhhZCB0byBiZSBhZGRlZCBpbiB5b3VyIGRyYWZ0IHRvIG1h a2UgdGhpcyBmbG93IHdvcms/DQoNCkhvdyBjYW4gSVB2Ni1vbmx5IEFQUCBnZXQgdGhlIElQVjQg cHVibGljIGFkZHJlc3MsIHVzZWQgYnkgTkFUX3RyYW5zbGF0b3IsIHdoZW4gc2VuZGluZyBhIHBh Y2tldCBmcm9tIElQdjYtb255IEFQUCB0byBJUHY0LW9ubHkgQVBQPyBUaGlzIElQdjQgYWRkcmVz cyBpcyB0aGUgc2FtZSBkZXN0aW5hdGlvbiBJUHY0IGFkZHJlc3MgdG8gd2hpY2ggSVB2NC1vbmx5 IEFQUCBzZW5kcyBhIHBhY2tldCB0b3dhcmRzIElQdjYtb25seSBBUFAgKCAxOTIuMC4yLjIuIGFk ZHJlc3MgaW4gSmVu4oCZcyBleGFtcGxlKS4NCg0KVGhhbmtzLA0KRHVzYW4uDQoNCkZyb206IHY2 b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSk9SREkgUEFMRVQgTUFS VElORVoNClNlbnQ6IE1vbmRheSwgSnVseSA4LCAyMDE5IDU6NDAgUE0NClRvOiBJUHY2IE9wZXJh dGlvbnMgPHY2b3BzQGlldGYub3JnPg0KQ2M6IDZtYW4gPDZtYW5AaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3Y2b3BzXSBOQVQ2NCBpbiBSQSwgZHJhZnQtaWV0Zi02bWFuLXJhLXByZWY2NA0KDQpJ IHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFsIHBvc3NpYmxlIHNvbHV0aW9ucywgYnV0IHRoZSBzaW1w bGVyIG9uZSBzZWVtcyB0byBiZSB0aGUgZHVhbC1zdGFjayBTSVAgcHJveGllcy4gQW5vdGhlciBv bmUgaXMgZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMsIHdoaWNoIEkgZGlkbuKAmXQga25ldywgdW50 aWwgdG9kYXksIGlzIGFscmVhZHkgaW4gdGhlIElFU0cgZm9yIGFwcHJvdmFsIHRoaXMgVGhydXNk YXkuDQpBbHNvIGl0IGNhbiBiZSBkb25lIHdpdGggRUFNIGFuZCBhbHNvIGFzIEkgbWVudGlvbiBp biBhIHByZXZpb3VzIGVtYWlsIHZpYSB0aGUgb3B0aW1pemF0aW9uIGZvciA0NjRYTEFULiBKdXN0 IHVwbG9hZGVkIHRoZSBuZXcgdmVyc2lvbjoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxhdC1vcHQtY2RuLWNhY2hlcy8/aW5jbHVkZV90 ZXh0PTE8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRwYWxldC0yRHY2b3BzLTJENDY0eGxh dC0yRG9wdC0yRGNkbi0yRGNhY2hlc18tM0ZpbmNsdWRlLTVGdGV4dC0zRDEmZD1Ed01GYVEmYz1C RnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMw MjlzTVFHUTJrWSZtPVdQazdubDdvbkdERkNCaWRXVFhqWmlVN3R1WlEyU3Z5U3lhcGdlcGpmUHMm cz1tNWJmYnZzcEZzam42dTBjVTllbFVENi0wbktPOXp1UUUyeE1DampLdnl3JmU9Pg0KDQoNCg0K DQoNCkVsIDgvNy8xOSAxOTowMSwgInY2b3BzIGVuIG5vbWJyZSBkZSBEYXZpZCBGYXJtZXIiIDx2 Nm9wcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBlbiBu b21icmUgZGUgZmFybWVyQHVtbi5lZHU8bWFpbHRvOmZhcm1lckB1bW4uZWR1Pj4gZXNjcmliacOz Og0KDQoNCg0KT24gTW9uLCBKdWwgOCwgMjAxOSBhdCAxMDo0OSBBTSBNdWRyaWMsIER1c2FuIChE dXNhbikgPGRtdWRyaWNAYXZheWEuY29tPG1haWx0bzpkbXVkcmljQGF2YXlhLmNvbT4+IHdyb3Rl Og0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYW5mcmVkaSAoVVMpLCBB bGJlcnQgRSA8YWxiZXJ0LmUubWFuZnJlZGlAYm9laW5nLmNvbTxtYWlsdG86YWxiZXJ0LmUubWFu ZnJlZGlAYm9laW5nLmNvbT4+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IGlwdjYgPGlwdjYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYu b3JnPj4gT24gQmVoYWxmIE9mIE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KPg0KPiA+IC0gSG93IGNh biBETlM2NCB0ZWxsIElQdjYgb25seSBjbGllbnQgdGhlIElQIG9mIElQdjQgb25seSBjbGllbnQs IGFuZCB2aWNlDQo+IHZlcnNhPw0KPg0KPiBJUHY2IHRvIElQdjQgc2hvdWxkIGJlIHN0cmFpZ2h0 Zm9yd2FyZCwgYmVjYXVzZSBpdCdzIGEgb25lLXRvLW9uZQ0KPiByZWxhdGlvbnNoaXAuIFRoZSBv dGhlciB3YXkgYXJvdW5kIHdvdWxkIG5vcm1hbGx5IG5vdCB3b3JrLA0KW0R1c2FuXSBUaGVyZSBp cyBubyBzb2x1dGlvbiBmb3IgSVB2NG9ubHkgY2xpZW50IHRvIHJlYWNoIElQdjZvbmx5IGNsaWVu dD8NCg0KSSBtb3N0bHkgc2F5LCBzbyB3aGF0ISBJdCBpcyBhbiB1bmZvcnR1bmF0ZSByZWFsaXR5 IG9mIHRvZGF5J3MgSW50ZXJuZXQsIGJlY2F1c2Ugb2YgTkFUNDQgYW5kL29yIHN0YXRlZnVsIGZp cmV3YWxsIGRlZmF1bHQgZGVueSBpbmJvdW5kIHBvbGljeSwgbWFueSB0aW1lcyBjbGllbnRzIGNh bid0IHNwZWFrIHRvIG90aGVyIGNsaWVudHMsIGJlIHRoZXkgSVB2NCBvbmx5LCBJUHY2IG9ubHks IG9yIGV2ZW4gZHVhbCBzdGFjay4gU29tZXRpbWVzIGZpcmV3YWxsIHRyYXZlcnNhbCB0ZWNobm9s b2dpZXMgY2FuIHdvcmsgYXJvdW5kIHRoaXMsIGFsc28gZGVwZW5kaW5nIG9uIHRoZSBmaXJld2Fs bCB0cmF2ZXJzYWwgc29sdXRpb24gdXNlZCBzb21ldGltZXMgSVB2NCBvbmx5IGFuZCBJUHY2IG9u bHkgY2xpZW50cyB3aWxsIGJlIGFibGUgdG8gdGFsayB0byBlYWNoIG90aGVyLiAgTXkgZ3Vlc3Mg aXMgdGhhdCBJUHY0IG9ubHkgdG8gSVB2NiBvbmx5IGZpcmV3YWxsIHRyYXZlcnNhbCB3b3VsZCBi ZSBsZXNzIGVmZmVjdGl2ZSB0aGFuIE5BVDQ0IGNsaWVudCB0byBOQVQ0NCBjbGllbnQgZmlyZXdh bGwgdHJhdmVyc2FsLCBidXQgaXQgaXMgc2hvdWxkIHN0aWxsIGJlIHBvc3NpYmxlIGluIHNvbWUg Y2FzZXMuDQoNCj4gYnV0IGV2ZXJ5b25lDQo+IGhhcyBiZWVuIGFjY3VzdG9tZWQgdG8gdGhhdCB3 aXRoIElQdjQgTkFQVCBhbHJlYWR5Lg0KW0R1c2FuXSBIb3cgSVB2NCBvbmx5IHVzZXJzIChlLmcu IEF2YXlhIElQdjQgb25seSBwaG9uZXMpIGNhbiBiZSBhY2N1c3RvbWVkIG5vdCB0byBiZSBhYmxl IHRvIGNhbGwgSVB2Nm9ubHkgdXNlcnMgKGxpa2UgQXBwbGUgSVB2NiBvbmx5IHBob25lcyk/DQoN ClRoZXkgbWF5IG5vdCBiZSBhYmxlIHRvIHRhbGsgcGVlciB0byBwZWVyLiBIb3dldmVyLCB0aHJv dWdoIGEgZHVhbC1zdGFjayBTSVAgb3Igb3RoZXIgcHJveGllcy9zZXNzaW9uIGJvcmRlciBjb250 cm9sbGVyLCB0aGV5IGNvdWxkIHByb2JhYmx5IGNvbXBsZXRlIGEgY2FsbC4NCg0KPlRoZSBjbGll bnQgYmVoaW5kIHRoZQ0KPiBOQVBUIGluaXRpYXRlcy4NCj4NCj4gPiBJcyBETlM2NCBzZXJ2ZXIg cmV0dXJuaW5nIElQdjRvbnkgY2xpZW50IGFkZHJlc3MgdG8gSVB2Nm9ubHkgY2xpZW50LCB1c2lu Zw0KPiB0aGUgQSBSUj8NCj4NCj4gVGhlIEROUyBzeW50aGVzaXplcyB0aGUgSVB2NiBhZGRyZXNz LCB3aGljaCBoYXMgdGhlIElQdjQgYWRkcmVzcw0KPiBlbWJlZGRlZCBpbiBpdC4NCj4NCj4gPiAt IEhvdyBjYW4gSVB2NG9ubHkgY2xpZW50IGdldCB0aGUgYWRkcmVzcyBvZiBJUHY2b25seSBjbGll bnQgKG9yLCBpdCBpcw0KPiBpbXBvc3NpYmxlIGZvciBJUHY0b25seSBjbGllbnQgdG8gZ2V0IElQ djYgYWRkcmVzcyBvZiBJUHY2b25seSBjbGllbnQpPw0KPg0KPiBUaGF0J3MgY2xlYXJseSBtb3Jl IGRpZmZpY3VsdCwgd2hpY2ggaXMgd2h5IHRoZSBub3JtYWwgY291cnNlIG9mIGFjdGlvbiBpcyBm b3INCj4gdGhlIElQdjYgY2xpZW50IHRvIGluaXRpYXRlIHRoZSBzZXNzaW9uLi4NCltEdXNhbl0g V2hhdCBpZiBJUHY0b25seSBjbGllbnQgbmVlZHMgdG8gaW5pdGlhdGUgdGhlIHNlc3Npb24gdG8g SVB2Nm9ubHkgY2xpZW50PyBXaGF0IGlzIHRoZSBzb2x1dGlvbiBmb3IgdGhhdCB1c2UgY2FzZT8N Cg0KTWFueSBmaXJld2FsbCB0cmF2ZXJzYWwgc29sdXRpb25zIHNob3VsZCB3b3JrIGluIHRoaXMg Y2FzZSwgYnV0IElQdjQgb25seSBjbGllbnQgdG8gY2xpZW50IGlzbid0IGd1YXJhbnRlZWQgdG8g d29yayBpbiBhbGwgY2FzZXMgZWl0aGVyLg0KDQo+DQo+ID4gLSBEbyB0aGVzZSBJUHY0IGFuZCBJ UHY2IGNsaWVudCBhZGRyZXNzZXMgbmVlZCB0byBiZSBwcmUtY29uZmlndXJlZCBvbiB0aGUNCj4g dHJhbnNsYXRvciBhbmQvb3IgRE5TNjQ/DQo+DQo+IEZvciBJUHY0IHRvIElQdjYsIGlmIHlvdSBt dXN0IGFsbG93IHRoZSBJUHY0IGNsaWVudCB0byBpbml0aWF0ZSB0aGUgc2Vzc2lvbiwgeW91J2QN Cj4gaGF2ZSB0byBoYXZlIHByZWNvbmZpZ3VyZSBzb21ldGhpbmcuDQpbRHVzYW5dIFdoZXJlIGFu ZCBob3cgaXMgdGhpcyBjb25maWd1cmF0aW9uIGRvbmU/DQoNCj4NCj4gQmVydA0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3Jn PG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NjxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX2lwdjYmZD1Ed01GYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFK eGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPVdQazdubDdvbkdERkNCaWRXVFhqWmlV N3R1WlEyU3Z5U3lhcGdlcGpmUHMmcz1LNzY2ZjR3NUVtak9aaTB2ckUzNG1QUkJPaW5kbEhjZzl6 bW5ZQi14ZnRzJmU9Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRhdmlkIEZhcm1lciAgICAgICAgICAgICAgIEVt YWlsOmZhcm1lckB1bW4uZWR1PG1haWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1Pg0KTmV0d29y a2luZyAmIFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzDQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24g VGVjaG5vbG9neQ0KVW5pdmVyc2l0eSBvZiBNaW5uZXNvdGENCjIyMTggVW5pdmVyc2l0eSBBdmUg U0UgICAgICAgIFBob25lOiA2MTItNjI2LTA4MTUNCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5 ICAgQ2VsbDogNjEyLTgxMi05OTUyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gdjZvcHMgbWFpbGluZyBsaXN0IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm Lm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdRRmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0 USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1XUGs3bmw3 b25HREZDQmlkV1RYalppVTd0dVpRMlN2eVN5YXBnZXBqZlBzJnM9T3hmcXZ6eWxtSVEwSUdja0JX ZmdxNHowSnNyUER5WEJRMzRXb1FMbVZhRSZlPT4NCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KSVB2NCBpcyBvdmVyDQpBcmUgeW91IHJlYWR5IGZvciB0 aGUgbmV3IEludGVybmV0ID8NCmh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cudGhlaXB2NmNv bXBhbnkuY29tJmQ9RHdRRmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVh SnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1XUGs3bmw3b25HREZDQmlkV1RYalpp VTd0dVpRMlN2eVN5YXBnZXBqZlBzJnM9RGxYYUZBUzlENGlYd0FDX0w5Y2pyM18xalZHVlhzXzI1 cm42NlR2ajdyOCZlPT4NClRoZSBJUHY2IENvbXBhbnkNCg0KVGhpcyBlbGVjdHJvbmljIG1lc3Nh Z2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlk ZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1l eHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9y IHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFs bHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQg d2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5n LCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9u LCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5 b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlz IGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCg== --_000_DM6PR15MB2506C6CC4E3853915F6AD1DEBBF10DM6PR15MB2506namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpo Mg0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIENo YXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5I ZWFkaW5nMkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglmb250LXdlaWdodDpib2xkO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0 IDg1LjA1cHQgNzAuODVwdCA4NS4wNXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIEpvcmRpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgeW91IHNheWluZyB5 b3VyIGRyYWZ0ICZuYnNwO+KAnDxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij40NjRY TEFUIE9wdGltaXphdGlvbuKAnTwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox OC4wcHQiPg0KPC9zcGFuPjwvYj53aWxsIHByb3ZpZGUgSVB2NG9ubHkgYXBwIHRvIElQdjZvbmx5 IGFwcCBjb21tdW5pY2F0aW9uIGxpa2UgdGhpcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi0tLS0tLiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgSVB2NiZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOy4tLS0tLS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBDRSZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7IC8mbmJzcDsgSVB2Ni0mbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAuLS0tLS0uJm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7LyBJUHY0LSBcJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgb3ImbmJzcDsmbmJzcDsg JiM0MzstLSgmbmJzcDsmbmJzcDsgb25seSZuYnNwOyZuYnNwOyZuYnNwOyApLS0tKCBOQVQ2NCAp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7IG9ubHkmbmJzcDsmbmJzcDsgXCZuYnNwOyZuYnNwOyB8 Jm5ic3A7IFVFJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgXCZuYnNwOyBBY2Nlc3MgL1wmbmJz cDsmbmJzcDsmbmJzcDsgYC0tLS0tJyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOygmbmJzcDsgU21hcnRUViZuYnNwOyApLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7XCZuYnNwOyZuYnNwOyBTVEImbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyB8IHdp dGgmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBgLS0mIzQzOy0tJyZuYnNwOyZuYnNw OyZuYnNwOyBcJm5ic3A7Jm5ic3A7IC4tLS0tLS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtcIFZvSVAmbmJzcDsgLyZuYnNwOyZuYnNw OyZuYnNwOyB8IE5BVDQ2IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcIC8mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYC0tLS0tJyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IENMQVQmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tLSYjNDM7LS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJz cDsgSVB2NiZuYnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4tLSYj NDM7LS0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyBETlMvJm5ic3A7IHwmbmJzcDsmbmJzcDsgKCZuYnNwOyBJbnRlcm5ldCApSVB2Ni8gSVB2Ni0g XDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0t JiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBETlM2NCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy0tLS0v Jm5ic3A7IG9ubHkgJm5ic3A7Jm5ic3A7XDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLSYjNDM7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LyZuYnNwOyZuYnNwOyZuYnNwOyAoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGAtLS0tLScmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXCZu YnNwOyBBUFAmbmJzcDsgJm5ic3A7Jm5ic3A7LzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7XCAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBgLS0tLS0n PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyAmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIElQdjQgdG8gSVB2NiBmbG93 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldoYXQgZGlkIG5vdCB3b3JrIHNvIGZhciBhbmQgd2hhdCBoYWQgdG8gYmUgYWRkZWQgaW4g eW91ciBkcmFmdCB0byBtYWtlIHRoaXMgZmxvdyB3b3JrPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Ib3cgY2FuIElQdjYtb25seSBBUFAgZ2V0IHRoZSBJUFY0IHB1YmxpYyBhZGRyZXNzLCB1c2Vk IGJ5IE5BVF90cmFuc2xhdG9yLCB3aGVuIHNlbmRpbmcgYSBwYWNrZXQgZnJvbSBJUHY2LW9ueSBB UFAgdG8gSVB2NC1vbmx5IEFQUD8gVGhpcyBJUHY0IGFkZHJlc3MgaXMgdGhlIHNhbWUgZGVzdGlu YXRpb24gSVB2NCBhZGRyZXNzIHRvIHdoaWNoIElQdjQtb25seSBBUFAgc2VuZHMgYSBwYWNrZXQg dG93YXJkcyBJUHY2LW9ubHkNCiBBUFAgKCAxOTIuMC4yLjIuIGFkZHJlc3MgaW4gSmVu4oCZcyBl eGFtcGxlKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RHVzYW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RnJvbTo8L2I+IHY2b3BzICZsdDt2Nm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhh bGYgT2YgPC9iPg0KSk9SREkgUEFMRVQgTUFSVElORVo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBKdWx5IDgsIDIwMTkgNTo0MCBQTTxicj4NCjxiPlRvOjwvYj4gSVB2NiBPcGVyYXRpb25zICZs dDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IDZtYW4gJmx0OzZtYW5AaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIE5BVDY0IGluIFJBLCBkcmFm dC1pZXRmLTZtYW4tcmEtcHJlZjY0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5JIHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFsIHBvc3NpYmxlIHNvbHV0aW9ucywgYnV0 IHRoZSBzaW1wbGVyIG9uZSBzZWVtcyB0byBiZSB0aGUgZHVhbC1zdGFjayBTSVAgcHJveGllcy4g QW5vdGhlciBvbmUgaXMgZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMsIHdoaWNoIEkgZGlkbuKAmXQg a25ldywgdW50aWwgdG9kYXksDQogaXMgYWxyZWFkeSBpbiB0aGUgSUVTRyBmb3IgYXBwcm92YWwg dGhpcyBUaHJ1c2RheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5BbHNvIGl0IGNhbiBiZSBkb25lIHdpdGggRUFNIGFuZCBhbHNvIGFz IEkgbWVudGlvbiBpbiBhIHByZXZpb3VzIGVtYWlsIHZpYSB0aGUgb3B0aW1pemF0aW9uIGZvciA0 NjRYTEFULiBKdXN0IHVwbG9hZGVkIHRoZSBuZXcgdmVyc2lvbjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyI+PGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19k YXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRwYWxldC0yRHY2b3BzLTJENDY0eGxhdC0y RG9wdC0yRGNkbi0yRGNhY2hlc18tM0ZpbmNsdWRlLTVGdGV4dC0zRDEmYW1wO2Q9RHdNRmFRJmFt cDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VX QjhZTFpVMjMwMjlzTVFHUTJrWSZhbXA7bT1XUGs3bmw3b25HREZDQmlkV1RYalppVTd0dVpRMlN2 eVN5YXBnZXBqZlBzJmFtcDtzPW01YmZidnNwRnNqbjZ1MGNVOWVsVUQ2LTBuS085enVRRTJ4TUNq akt2eXcmYW1wO2U9Ij48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxhdC1vcHQtY2RuLWNhY2hlcy8/aW5jbHVk ZV90ZXh0PTE8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+RWwgOC83LzE5IDE5OjAxLCAmcXVvdDt2Nm9wcyBl biBub21icmUgZGUgRGF2aWQgRmFybWVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHMt Ym91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4gZW4gbm9tYnJlIGRl DQo8YSBocmVmPSJtYWlsdG86ZmFybWVyQHVtbi5lZHUiPmZhcm1lckB1bW4uZWR1PC9hPiZndDsg ZXNjcmliacOzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFu Zz0iRVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBs YW5nPSJFUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+T24gTW9uLCBK dWwgOCwgMjAxOSBhdCAxMDo0OSBBTSBNdWRyaWMsIER1c2FuIChEdXNhbikgJmx0OzxhIGhyZWY9 Im1haWx0bzpkbXVkcmljQGF2YXlhLmNvbSI+ZG11ZHJpY0BhdmF5YS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IE1hbmZyZWRpIChVUyksIEFsYmVydCBFICZsdDs8YSBo cmVmPSJtYWlsdG86YWxiZXJ0LmUubWFuZnJlZGlAYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmFsYmVydC5lLm1hbmZyZWRpQGJvZWluZy5jb208L2E+Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogaXB2NiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjYt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBNdWRyaWMsIER1c2FuIChEdXNh bik8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAtIEhvdyBjYW4gRE5TNjQgdGVsbCBJUHY2IG9u bHkgY2xpZW50IHRoZSBJUCBvZiBJUHY0IG9ubHkgY2xpZW50LCBhbmQgdmljZTxicj4NCiZndDsg dmVyc2E/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElQdjYgdG8gSVB2NCBzaG91bGQgYmUgc3RyYWln aHRmb3J3YXJkLCBiZWNhdXNlIGl0J3MgYSBvbmUtdG8tb25lPGJyPg0KJmd0OyByZWxhdGlvbnNo aXAuIFRoZSBvdGhlciB3YXkgYXJvdW5kIHdvdWxkIG5vcm1hbGx5IG5vdCB3b3JrLCA8YnI+DQpb RHVzYW5dIFRoZXJlIGlzIG5vIHNvbHV0aW9uIGZvciBJUHY0b25seSBjbGllbnQgdG8gcmVhY2gg SVB2Nm9ubHkgY2xpZW50PyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNw YW4gbGFuZz0iRVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVTIj5JIG1vc3RseSBzYXksIHNvIHdoYXQhIEl0IGlzIGFuIHVuZm9ydHVuYXRlIHJlYWxp dHkgb2YgdG9kYXkncyBJbnRlcm5ldCwgYmVjYXVzZSBvZiBOQVQ0NCBhbmQvb3Igc3RhdGVmdWwg ZmlyZXdhbGwgZGVmYXVsdCBkZW55IGluYm91bmQgcG9saWN5LCBtYW55IHRpbWVzIGNsaWVudHMg Y2FuJ3Qgc3BlYWsgdG8gb3RoZXIgY2xpZW50cywNCiBiZSB0aGV5IElQdjQgb25seSwgSVB2NiBv bmx5LCBvciBldmVuIGR1YWwgc3RhY2suIFNvbWV0aW1lcyBmaXJld2FsbCB0cmF2ZXJzYWwgdGVj aG5vbG9naWVzIGNhbiB3b3JrIGFyb3VuZCB0aGlzLCBhbHNvIGRlcGVuZGluZyBvbiB0aGUgZmly ZXdhbGwgdHJhdmVyc2FsIHNvbHV0aW9uIHVzZWQgc29tZXRpbWVzIElQdjQgb25seSBhbmQgSVB2 NiBvbmx5IGNsaWVudHMgd2lsbCBiZSBhYmxlIHRvIHRhbGsgdG8gZWFjaCBvdGhlci4mbmJzcDsg TXkgZ3Vlc3MNCiBpcyB0aGF0IElQdjQgb25seSB0byBJUHY2IG9ubHkgZmlyZXdhbGwgdHJhdmVy c2FsIHdvdWxkIGJlIGxlc3MgZWZmZWN0aXZlIHRoYW4gTkFUNDQgY2xpZW50IHRvIE5BVDQ0IGNs aWVudCBmaXJld2FsbCB0cmF2ZXJzYWwsIGJ1dCBpdCBpcyBzaG91bGQgc3RpbGwgYmUgcG9zc2li bGUgaW4gc29tZSBjYXNlcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3Bh biBsYW5nPSJFUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIj4mZ3Q7IGJ1 dCBldmVyeW9uZTxicj4NCiZndDsgaGFzIGJlZW4gYWNjdXN0b21lZCB0byB0aGF0IHdpdGggSVB2 NCBOQVBUIGFscmVhZHkuIDxicj4NCltEdXNhbl0gSG93IElQdjQgb25seSB1c2VycyAoZS5nLiBB dmF5YSBJUHY0IG9ubHkgcGhvbmVzKSBjYW4gYmUgYWNjdXN0b21lZCBub3QgdG8gYmUgYWJsZSB0 byBjYWxsIElQdjZvbmx5IHVzZXJzIChsaWtlIEFwcGxlIElQdjYgb25seSBwaG9uZXMpPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPlRoZXkgbWF5IG5vdCBi ZSBhYmxlIHRvIHRhbGsgcGVlciB0byBwZWVyLiBIb3dldmVyLCB0aHJvdWdoIGEgZHVhbC1zdGFj ayBTSVAgb3Igb3RoZXIgcHJveGllcy9zZXNzaW9uIGJvcmRlciBjb250cm9sbGVyLCB0aGV5IGNv dWxkIHByb2JhYmx5IGNvbXBsZXRlIGEgY2FsbC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9 IkVTIj4mZ3Q7VGhlIGNsaWVudCBiZWhpbmQgdGhlPGJyPg0KJmd0OyBOQVBUIGluaXRpYXRlcy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBJcyBETlM2NCBzZXJ2ZXIgcmV0dXJuaW5nIElQdjRv bnkgY2xpZW50IGFkZHJlc3MgdG8gSVB2Nm9ubHkgY2xpZW50LCB1c2luZzxicj4NCiZndDsgdGhl IEEgUlI/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBETlMgc3ludGhlc2l6ZXMgdGhlIElQdjYg YWRkcmVzcywgd2hpY2ggaGFzIHRoZSBJUHY0IGFkZHJlc3M8YnI+DQomZ3Q7IGVtYmVkZGVkIGlu IGl0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0gSG93IGNhbiBJUHY0b25seSBjbGllbnQg Z2V0IHRoZSBhZGRyZXNzIG9mIElQdjZvbmx5IGNsaWVudCAob3IsIGl0IGlzPGJyPg0KJmd0OyBp bXBvc3NpYmxlIGZvciBJUHY0b25seSBjbGllbnQgdG8gZ2V0IElQdjYgYWRkcmVzcyBvZiBJUHY2 b25seSBjbGllbnQpPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0J3MgY2xlYXJseSBtb3JlIGRp ZmZpY3VsdCwgd2hpY2ggaXMgd2h5IHRoZSBub3JtYWwgY291cnNlIG9mIGFjdGlvbiBpcyBmb3I8 YnI+DQomZ3Q7IHRoZSBJUHY2IGNsaWVudCB0byBpbml0aWF0ZSB0aGUgc2Vzc2lvbi4uPGJyPg0K W0R1c2FuXSBXaGF0IGlmIElQdjRvbmx5IGNsaWVudCBuZWVkcyB0byBpbml0aWF0ZSB0aGUgc2Vz c2lvbiB0byBJUHY2b25seSBjbGllbnQ/IFdoYXQgaXMgdGhlIHNvbHV0aW9uIGZvciB0aGF0IHVz ZSBjYXNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJF UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPk1h bnkgZmlyZXdhbGwgdHJhdmVyc2FsIHNvbHV0aW9ucyBzaG91bGQgd29yayBpbiB0aGlzIGNhc2Us IGJ1dCBJUHY0IG9ubHkgY2xpZW50IHRvIGNsaWVudCBpc24ndCBndWFyYW50ZWVkIHRvIHdvcmsg aW4gYWxsIGNhc2VzIGVpdGhlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48 c3BhbiBsYW5nPSJFUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIj4mZ3Q7 IDxicj4NCiZndDsgJmd0OyAtIERvIHRoZXNlIElQdjQgYW5kIElQdjYgY2xpZW50IGFkZHJlc3Nl cyBuZWVkIHRvIGJlIHByZS1jb25maWd1cmVkIG9uIHRoZTxicj4NCiZndDsgdHJhbnNsYXRvciBh bmQvb3IgRE5TNjQ/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZvciBJUHY0IHRvIElQdjYsIGlmIHlv dSBtdXN0IGFsbG93IHRoZSBJUHY0IGNsaWVudCB0byBpbml0aWF0ZSB0aGUgc2Vzc2lvbiwgeW91 J2Q8YnI+DQomZ3Q7IGhhdmUgdG8gaGF2ZSBwcmVjb25maWd1cmUgc29tZXRoaW5nLjxicj4NCltE dXNhbl0gV2hlcmUgYW5kIGhvdyBpcyB0aGlzIGNvbmZpZ3VyYXRpb24gZG9uZT88YnI+DQo8YnI+ DQomZ3Q7IDxicj4NCiZndDsgQmVydDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KSUVURiBJ UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwdjZA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHY2QGlldGYub3JnPC9hPjxicj4NCkFkbWluaXN0 cmF0aXZlIFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lwdjYm YW1wO2Q9RHdNRmFRJmFtcDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9VVQzQms5Y2JM ZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZhbXA7bT1XUGs3bmw3b25HREZDQmlk V1RYalppVTd0dVpRMlN2eVN5YXBnZXBqZlBzJmFtcDtzPUs3NjZmNHc1RW1qT1ppMHZyRTM0bVBS Qk9pbmRsSGNnOXptbllCLXhmdHMmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIj48YnIgY2xl YXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUu NHB0Ij48c3BhbiBsYW5nPSJFUyI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT08YnI+DQpEYXZpZCBGYXJtZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkVtYWlsJTNBZmFybWVy QHVtbi5lZHUiIHRhcmdldD0iX2JsYW5rIj4NCkVtYWlsOmZhcm1lckB1bW4uZWR1PC9hPjxicj4N Ck5ldHdvcmtpbmcgJmFtcDsgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXM8YnI+DQpPZmZpY2Ug b2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTxicj4NClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhJm5i c3A7Jm5ic3A7IDxicj4NCjIyMTggVW5pdmVyc2l0eSBBdmUgU0UmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgUGhvbmU6IDYxMi02MjYtMDgxNTxicj4NCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0z MDI5Jm5ic3A7Jm5ic3A7IENlbGw6IDYxMi04MTItOTk1Mjxicj4NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUu NHB0Ij48c3BhbiBsYW5nPSJFUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gdjZvcHMgbWFpbGluZyBsaXN0DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0 Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX3Y2b3BzJmFtcDtkPUR3UUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJmFtcDty PVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmYW1wO209V1BrN25s N29uR0RGQ0JpZFdUWGpaaVU3dHVaUTJTdnlTeWFwZ2VwamZQcyZhbXA7cz1PeGZxdnp5bG1JUTBJ R2NrQldmZ3E0ejBKc3JQRHlYQlEzNFdvUUxtVmFFJmFtcDtlPSI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IkVTIj48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPGJyPg0KSVB2NCBpcyBvdmVyPGJyPg0KQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRl cm5ldCA/PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3d3dy50aGVpcHY2Y29tcGFueS5jb20mYW1wO2Q9RHdRRmFRJmFtcDtj PUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZ TFpVMjMwMjlzTVFHUTJrWSZhbXA7bT1XUGs3bmw3b25HREZDQmlkV1RYalppVTd0dVpRMlN2eVN5 YXBnZXBqZlBzJmFtcDtzPURsWGFGQVM5RDRpWHdBQ19MOWNqcjNfMWpWR1ZYc18yNXJuNjZUdmo3 cjgmYW1wO2U9Ij5odHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbTwvYT48YnI+DQpUaGUgSVB2 NiBDb21wYW55PGJyPg0KPGJyPg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5m b3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5m b3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhv cml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZg0KIHRoZSBj b250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5n IGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNp ZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlv biBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzDQogb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBw YXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVw bHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0 aW9uIGFuZCBkZWxldGUgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR15MB2506C6CC4E3853915F6AD1DEBBF10DM6PR15MB2506namp_-- --_004_DM6PR15MB2506C6CC4E3853915F6AD1DEBBF10DM6PR15MB2506namp_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 09 Jul 2019 20:03:25 GMT"; modification-date="Tue, 09 Jul 2019 20:03:25 GMT" Received: from BYAPR15MB2504.namprd15.prod.outlook.com (2603:10b6:4:4c::12) by DM6PR15MB2506.namprd15.prod.outlook.com with HTTPS via DM5PR1101CA0002.NAMPRD11.PROD.OUTLOOK.COM; Tue, 9 Jul 2019 01:34:22 +0000 Received: from SN6PR15CA0025.namprd15.prod.outlook.com (2603:10b6:805:16::38) by BYAPR15MB2504.namprd15.prod.outlook.com (2603:10b6:a02:8e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 9 Jul 2019 01:34:19 +0000 Received: from BY2NAM03FT043.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::202) by SN6PR15CA0025.outlook.office365.com (2603:10b6:805:16::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1987.14 via Frontend Transport; Tue, 9 Jul 2019 01:34:19 +0000 Received: from PW365VMAP01.avaya.com (135.11.29.21) by BY2NAM03FT043.mail.protection.outlook.com (10.152.85.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Tue, 9 Jul 2019 01:34:19 +0000 Received: from AZ-US1EXHC02.global.avaya.com (135.11.85.13) by PW365VMAP01.avaya.com (135.11.29.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Mon, 8 Jul 2019 20:34:13 -0500 Received: from p-us1-erheast-smtpauth.us1.avaya.com (135.11.50.38) by AZ-US1EXHC02.global.avaya.com (135.11.85.13) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 8 Jul 2019 21:34:12 -0400 Received: from emeappfilter.avaya.com ([135.64.140.155]) by p-us1-erheast.us1.avaya.com with ESMTP; 08 Jul 2019 21:34:12 -0400 Received: from pps.filterd (emeappfilter.avaya.com [127.0.0.1]) by emeappfilter.avaya.com (8.16.0.21/8.16.0.21) with SMTP id x691UUEA009575 for ; Mon, 8 Jul 2019 21:34:12 -0400 Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by emeappfilter.avaya.com with ESMTP id 2tm8vsgg90-1 for ; Mon, 08 Jul 2019 21:34:10 -0400 Received: from mail-qt1-f176.google.com ([209.85.160.176]) by de307622-de-ieremea.avaya.com with ESMTP/TLS/AES128-GCM-SHA256; 08 Jul 2019 21:34:08 -0400 Received: by mail-qt1-f176.google.com with SMTP id k10so12430857qtq.1 for ; Mon, 08 Jul 2019 18:34:08 -0700 (PDT) From: Jen Linkova To: "Mudric, Dusan (Dusan)" CC: "Manfredi (US), Albert E" , IPv6 Operations , 6man <6man@ietf.org> Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AQHVNfZfQTP2spnzX0G8BrvKPAtN5g== Date: Tue, 9 Jul 2019 01:33:55 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: Content-Language: en-US X-MS-Exchange-Organization-AuthSource: BY2NAM03FT043.eop-NAM03.prod.protection.outlook.com X-MS-Exchange-Organization-ComplianceLabelId: ddf901f2-09d6-417d-8c19-bf4f789a14e3 X-MS-Has-Attach: X-MS-Exchange-Organization-Network-Message-Id: c2811951-f936-4512-f3e5-08d7040d903a X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ironport-av: E=Sophos; i="5.63,468,1557201600"; d="scan'208"; a="290604701" 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=IWLOcMYgLdYzJFpA6aiNMUlE224uHjnnzUJKO+MdkpY=; b=bNYo6EgR+3H6Tzy60EytwN+V/Q23t1p2IEMEkNa+aVTrulBu9bMWYmngBiadSRDjrY vsEVddh72kku4UlxxoD0Jr1dugUsqCjIKF+wNbjjqYfT0RzrFqliOuSJwz/F367Ys1CU 6C7W5cisU2TlBiKlN5y32nNmU/BQ/OPI64qt1FrvW8i9vSEV4LYJFCp6qTrMKYuG2HqT RM9cFRdfWW8qF4X1fcIPpeW/kHmJ0PFbq80pVgJN2LAAnxSjSRF6o+zM4D2szAW1kt+O MrDQ5qAuofBjrSmJpdWNN+Y36EApRdh+5GA2C6pObRa6lErAuv63kAA2056ilTU209sM FfBg== x-proofpoint-virus-version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-09_01:,, signatures=0 x-proofpoint-spam-details: rule=inbound_no_bulk_notspam policy=inbound_no_bulk score=0 priorityscore=306 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=213 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=899 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907090017 x-ms-exchange-organization-originalclientipaddress: 135.11.29.21 x-ms-exchange-organization-originalserveripaddress: 10.152.85.147 received-spf: SoftFail (protection.outlook.com: domain of transitioning gmail.com discourages use of 135.11.29.21 as permitted sender) x-ms-publictraffictype: Email x-forefront-antispam-report: CIP:135.11.29.21; IPV:CAL; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(4636009)(2980300002)(189003)(199004)(8156004)(86362001)(11346002)(82202003)(76482006)(446003)(8676002)(50466002)(68736007)(53936002)(81156014)(81166006)(6246003)(107886003)(6306002)(126002)(356004)(486006)(6666004)(498394004)(59536001)(6916009)(476003)(95326003)(23676004)(336012)(229853002)(69596002)(4326008)(76176011)(34756004)(26826003)(47776003)(61266001)(53546011)(5660300002)(966005)(55446002)(305945005)(1096003)(73392003)(54906003)(73972006)(5820100001)(42186006)(26005)(8936002)(14444005); DIR:INB; SFP:; SCL:1; SRVR:BYAPR15MB2504; H:PW365VMAP01.avaya.com; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Antispam-Mailbox-Delivery: ucf:0; jmr:0; ex:0; auth:0; dest:I; ENG:(20160514016)(750119)(520011016)(944506303)(944626516); X-Microsoft-Antispam-Message-Info: =?utf-8?B?THBFVkwvYjhSbllhQU0zZGtNMUFxQ2F6blZ4ZHQyb2RFRXZ4WmZsbllXNjhS?= =?utf-8?B?aEdPNGkvS09Lc1lndHdRcjJiemZsTk9zcDg5ZFhDM2dpUTNwdVpEeUR1b3Zp?= =?utf-8?B?QnJmdWxUcFZvaXlsWVNXNmFVdzBhbXJxdjVQUmt1UjlVOFI1amV6QVZnVjFX?= =?utf-8?B?UCtUaGVzQUthL2JtL245dzVHU1IrZ2VjYnRxSDNBaG1ybGxheHFrTUd3MU5E?= =?utf-8?B?c0tYZ05BTGJtb2k5UWtUeDFuSFRFRmwzM0pYQU1KL0RkWFpZQ0llK1ZMTFdW?= =?utf-8?B?NjN2b0xBajNDUTBURWMxd0xSWDN5VFR5Y2I1WmNndGRhRVFnUlhMOE1jQ2wv?= =?utf-8?B?R3RDZ3JCY1I2bmFiaVBLOGRHRDUwTTFIUTN0YUN3T1lEQllGcm04SW0zckZZ?= =?utf-8?B?TFhUTjAzODBvdWJScHBkb1FoczVYRnJRbUZycWdRYy9BTGR0WmZoYXN4M1ds?= =?utf-8?B?SDRYeEVpa28wTGJCVmFKQUxRamtBYVFzZ0YwcFowdjlVamw2QWhuaDlWQkRx?= =?utf-8?B?d0NmRlNFWHVUQXhlbWRoYWZLNHQ2MVFDS21pT2pOeFYvajhseGRJTHB6Ujha?= =?utf-8?B?Vy9qYTZweXlxRGZ4UWF4azRrdEVBQWdnSzV0ZXREemc1aUp6MWVvaGpJOHhk?= =?utf-8?B?UHBVd0JDYzlvYSsrWE45aURHWGR6RkdjNlZTbXBDUCtTWUE0dzIzUWRudUVt?= =?utf-8?B?dDZqOUx2ODVaNzVrbThBdHprdWdLQ0dpcis1YW1oRkJCNE53MGloczkvcmo0?= =?utf-8?B?emR4YmNsNmdKSXlqc0dteERCNk5MV21mSXBLQXFaSUVocTlzK0lKSDBpYjBI?= =?utf-8?B?RExianJVWk5GeHg3TWlFMVkrZzBuL0hvaXE4cGozZUN4NHh1TVdwQVZqQTRx?= =?utf-8?B?OWpjdFRYSzMwcXlNWkkxaCtrQTdXK3RlUVhuWUtrZExIdU1ZZVZEY0NsQjBV?= =?utf-8?B?NlZwS094QnYxek1mRDRnV0RXRk16VExzakpiUU5TTEo4Z1gzTHZCc2VVZ0Fq?= =?utf-8?B?Q2hyZXdHZzU4QXI3N3B1UllSeXZVR08yb3RYVExxbFc0YzMvZklaS2d4UkJz?= =?utf-8?B?M0Q4aEx2YkoxbnZOb0hOTWtDSkJRSlk0T3lSRmZ5bm4rVHdjVlU5SE1RSFB1?= =?utf-8?B?b29LWkpmMWxvQnVDOUsxU3VSOFR1YjIveFNEbkFydGZhSDZKcTluQWRseThD?= =?utf-8?B?YkdQM3Q3SnpJbGRQNWYrd2dRL3o4Ly9HQXFOc3ZvV0tDbUtvbVVlbEptSjdG?= =?utf-8?B?UU1udkw0ZE1pZWRKMGRsbDZTSUszdytLRGowMzQrcFdYeFk4NGhsbnp4aFA4?= =?utf-8?B?RnByUUxXbVkvaGgwZHlEa0ZzelR0OFpVejlnWlFubHltWVpudW1Kb3JUcFNs?= =?utf-8?B?QURXaldQcUhPWmJHb3JmOUt3bVhGd04vYmZ6bkFQd3NLR3VIWlduRVFQK1ZP?= =?utf-8?B?aGVNb1l3RHlQOEF2WFF2TFJOYTZYeklFMDlXWkZBPT0=?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 T24gVHVlLCBKdWwgOSwgMjAxOSBhdCAxOjUwIEFNIE11ZHJpYywgRHVzYW4gKER1c2FuKSA8ZG11 ZHJpY0BhdmF5YS5jb20+IHdyb3RlOg0KPiBbRHVzYW5dIFdoYXQgaWYgSVB2NG9ubHkgY2xpZW50 IG5lZWRzIHRvIGluaXRpYXRlIHRoZSBzZXNzaW9uIHRvIElQdjZvbmx5IGNsaWVudD8gV2hhdCBp cyB0aGUgc29sdXRpb24gZm9yIHRoYXQgdXNlIGNhc2U/DQoNCmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM3 NzU1JmQ9RHdJQmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNp Q3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1fY1dSc2R6b2Y1ZFhJOXlUUUg1MUhfS0h0Y1NS Y01BdEFSQXJLVmNkbldNJnM9d0R4V0V3Uy1lLU4tSTBvQWZjZGktNUd1Y05pQ1FwUjMydDlSdzRS WnluMCZlPSBtZW50aW9uZWQgYmVmb3JlLg0KDQpJUHY0LW9ubHkgY2xpZW50IC0tIElQdjQtZW5h YmxlZCBuZXR3b3JrLS0tIFNJSVQgdHJhbnNsYXRvciAtLS0tDQpJUHY2LW9ubHkgTEFOIC0tLSBJ UHY2LW9ubHkgc2VydmVyLg0KDQpMZXQncyBzYXkgIHlvdXIgSVB2NC1vbmx5IGNsaWVudCBuZWVk cyB0byB0YWxrIHRvIHRoZSBJcHY2LW9ubHkNCnNlcnZlciwgaXB2Ni1vbmx5LmV4YW1wbGUubmV0 Lg0KRm9yIHRoaXMgdG8gaGFwcGVuIHRoZSBvd25lciBvZiB0aGUgSXB2Ni1vbmx5IHNlcnZlciBu ZWVkcyB0bw0KY29uZmlndXJlIHRoZSB0cmFuc2xhdG9yIChTSUlUIGJveCBpbiB0aGUgZGlhZ3Jh bSBhYm92ZSkuDQpUaGUgb3duZXIgd291bGQgY3JlYXRlIGEgRE5TIEEgUlIgZm9yICBpcHY2LW9u bHkuZXhhbXBsZS5uZXQuIC0gbGV0J3MNCnNheSwgMTkyLjAuMi4yDQpJcHY2LW9ubHkgc2VydmVy IHdvdWxkIGhhdmUgYW4gSVB2NiBhZGRyZXNzIHdoaWNoIGhhcyB0aGF0IElQdjQNCmFkZHJlc3Mg ZW5jb2RlZCAtIGZvciBleGFtcGxlLCAyMDAxOmRiODoxOjoxOTIuMC4yLjINClRoYXQgSVB2NCBh ZGRyZXNzIChvciB0aGUgcHJlZml4IG1vc3QgbGlrZWx5KSB3aWxsIGJlIHJvdXRlZCB0byB0aGUg dHJhbnNsYXRvci4NCg0KU28geW91ciBJcHY0LW9ubHkgY2xpZW50IHNlbmRzIGEgRE5TIHJlcXVl c3QgdG8gcmVzb2x2ZQ0KaXB2Ni1vbmx5LmV4YW1wbGUubmV0LCBnZXRzIDE5Mi4wLjIuMiBiYWNr LCBzZW5kcyBhIHBhY2tldCB0bw0KMTkyLjAuMi4yLg0KVGhlIHBhY2tldCByZWFjaGVzIHRoZSB0 cmFuc2xhdG9yLiBUaGUgdHJhbnNsYXRvciB0cmFuc2xhdGVzIElQdjQNCnBhY2tldCB0byBJUHY2 IHBhY2tldCBhbmQgc2VuZHMgaXQgdG8gdGhlIHNlcnZlciAobm90ZSB0aGF0IHRoZQ0KZGVzdGlu YXRpb24gSVB2NiBhZGRyZXNzIGNhbiBiZSBlYXNpbHkgY29uc3RydWN0ZWQgYXMgdGhlIHRyYW5z bGF0b3INCmtub3dzIHRoZSBwcmVmaXggYW5kIGp1c3QgYWRkcyB0aGUgSVB2NCBhZGRyZXNzIC0g MTkyLjAuMi4yIC0gdG8gdGhhdA0KcHJlZml4IHRvIGdldCB0aGUgZGVzdGluYXRpb24gSVB2NiBh ZGRyZXNzLiBJUHY2IHNvdXJjZSBhZGRyZXNzIGlzDQpzeW50aGVzaXNlZCBpbiB0aGUgc2FtZSB3 YXkgZnJvbSB0aGUgY2xpZW50IElQdjQgYWRkcmVzcykuDQoNCkhlcmUgaXMgYSBuaWNlIHRhbGsg VG9yZSBBbmRlcnNvbiBnYXZlIGF0IFJJUEUgNyB5ZWFycyBhZ286DQpodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3JpcGU2NC5yaXBlLm5ldF9wcmVz ZW50YXRpb25zXzY3LTJEMjAxMjA0MTctMkRSSVBFNjQtMkRUaGUtNUZDYXNlLTVGZm9yLTVGSVB2 Ni01Rk9ubHktNUZEYXRhLTVGQ2VudHJlcy5wZGYmZD1Ed0lCYVEmYz1CRnBXUXc4YnN1S3BsMVNn aVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPV9j V1JzZHpvZjVkWEk5eVRRSDUxSF9LSHRjU1JjTUF0QVJBcktWY2RuV00mcz1Hc1BUZFByX1p3V1lL MTNMSXJoVHY5cllNNmRZSmZnYlQ4SHRMd1ZSa1pvJmU9DQoNCg0KDQo+ID4gRm9yIElQdjQgdG8g SVB2NiwgaWYgeW91IG11c3QgYWxsb3cgdGhlIElQdjQgY2xpZW50IHRvIGluaXRpYXRlIHRoZSBz ZXNzaW9uLCB5b3UnZA0KPiA+IGhhdmUgdG8gaGF2ZSBwcmVjb25maWd1cmUgc29tZXRoaW5nLg0K PiBbRHVzYW5dIFdoZXJlIGFuZCBob3cgaXMgdGhpcyBjb25maWd1cmF0aW9uIGRvbmU/DQoNCk9u IHRoZSB0cmFuc2xhdG9yIHdoaWNoIGNvbm5lY3RzIElQdjYtb25seSBuZXR3b3JrIHRvIGR1YWwt c3RhY2svSVB2NC1vbmx5IG9uZS4NCkluIGdlbmVyYWwsIHdoZW4geW91IG5lZWQgdG8gbGV0IG9u ZSBwcm90b2NvbCB0YWxrIHRvIGFub3RoZXIsIHlvdSdkDQpoYXZlIGEgcG9pbnQgKG9yIHRoZSBl ZGdlKSB3aGVyZSB0aG9zZSB0d28gbmV0d29ya3MgbWVldCBlYWNoIG90aGVyLg0KVXN1YWxseSB5 b3UnZCBoYXZlIGEgYm94IChvciBib3hlcykgaW50ZXJjb25uZWN0aW5nIHRoZW0gLSBxdWl0ZSBv ZnRlbg0KaXQncyBleGFjdGx5IHRoZSBib3ggeW91J2QgbmVlZCB0byBjb25maWd1cmUgOykNCg0K LS0NClNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCg== --_004_DM6PR15MB2506C6CC4E3853915F6AD1DEBBF10DM6PR15MB2506namp_-- From nobody Tue Jul 9 13:12:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBF712006D; Tue, 9 Jul 2019 13:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=avaya365.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 WJw9O_V0LRhY; Tue, 9 Jul 2019 13:12:17 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 CEBEB12001B; Tue, 9 Jul 2019 13:12:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FHAAC29CRd/yYyC4dmHAEBAQQBAQcEA?= =?us-ascii?q?QGBVQUBAQsBgUNQbXUEMwqEEoNHA4UxiRqCW4UpNYNuAY8nFIEQAxgXJQkBAQE?= =?us-ascii?q?NASAJBAIBAQKEPgIXglA2Bw4BAwEBAQQBAQEBBAECAmmFPAyCeE0vCgIvAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDQIpHgEBGAEBAQE?= =?us-ascii?q?CARIRHQEBLAsBBAcEAgEIDgMEAQEBKgICAh8RHQgCBA4FCAYNB4MBgWoDDg8BA?= =?us-ascii?q?gIKoToCgQgwiF8BAXCBMhqCNSoBAQV1hAsNC4ILBwkJAYEqAYhBgzSBQT6BEUa?= =?us-ascii?q?CTD6CGkcEGIELJhg8gkwygiaMHoJShH2BCpRyLUAJAoIXgyuDK4k8hA6CLG2GN?= =?us-ascii?q?IN5A4o3lHGBc44KAgICAgQFAg4BAQWBVgEygVhwFTuCbAmCOAwXg06EWYV6cgE?= =?us-ascii?q?BE4EUjQ4BgSABAQ?= X-IPAS-Result: =?us-ascii?q?A2FHAAC29CRd/yYyC4dmHAEBAQQBAQcEAQGBVQUBAQsBgUN?= =?us-ascii?q?QbXUEMwqEEoNHA4UxiRqCW4UpNYNuAY8nFIEQAxgXJQkBAQENASAJBAIBAQKEP?= =?us-ascii?q?gIXglA2Bw4BAwEBAQQBAQEBBAECAmmFPAyCeE0vCgIvAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDQIpHgEBGAEBAQECARIRHQEBLAsBB?= =?us-ascii?q?AcEAgEIDgMEAQEBKgICAh8RHQgCBA4FCAYNB4MBgWoDDg8BAgIKoToCgQgwiF8?= =?us-ascii?q?BAXCBMhqCNSoBAQV1hAsNC4ILBwkJAYEqAYhBgzSBQT6BEUaCTD6CGkcEGIELJ?= =?us-ascii?q?hg8gkwygiaMHoJShH2BCpRyLUAJAoIXgyuDK4k8hA6CLG2GNIN5A4o3lHGBc44?= =?us-ascii?q?KAgICAgQFAg4BAQWBVgEygVhwFTuCbAmCOAwXg06EWYV6cgEBE4EUjQ4BgSABA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.63,471,1557201600"; d="scan'208";a="355778853" Received: from mailauth.avaya.com (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Jul 2019 16:11:49 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 16:11:48 -0400 Received: from PW365VMAP01.avaya.com (135.11.29.21) by az-us1exhc01.global.avaya.com (135.11.85.12) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 9 Jul 2019 16:11:48 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (104.47.42.50) by PW365VMAP01.avaya.com (135.11.29.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Tue, 9 Jul 2019 15:11:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bhE1zx3zBE3cfIXVighFEH3dr5Edd3XQncyJr8nzhz9TPgYDneAJwKa5DRLvImiYw718qxe09C5mRbxFiYdJsND8R8JyFHq1xkIzlslnXJ6geWq1UsBaRA+DE5Al4ic9r7nArGz2YiVtlez0PgHcD7/6lqi6g8rEn6CHp+PfruDfo7BfOYst6/KgU6h6nMZn6UGocvlawFIggotr6zvz89j+E4te8BsJu1tw6OMAsT1igLTR+DErEzG83PHfjMi7H0TZe1XfTxB2VijojLkONb9pCopo1sYiS7Vg04/FUQ1ktdwDomUQudpTqYc3PGMyROMzihgkM08cFgsDBPPSbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NH2eQorqJcq5RCTK9gQyUwNXsQvOkju6yy+yvLjSbAo=; b=c4g8EsXy99D9TBhDVlvN3gf/9ZO72WkdGagGyL3vXMsVlQIQfShmue8Dr+KwWwgKlvS55DbKkXYrNqUIjLCdf+nVbpp92h7vsW1ugSJU70lnGWpXUGqxyoOoTaRfWCSAeWNrpXyPtvot2wacvv3IZTaaPNXYEx31zF1nj0B9hCQmJdC5KdtZohqb05LZRawBpu2xB84XUnNTbs1+o3oH3gvrrF7xBKs96ZJLs/3P8Sp8tLyRXSDA9tPc3kEsvrtiS+wezyHJE2FAoo+WSw2x4Lz0TM0kLhDzgmBYKLNO25lDceto3PSimigNNTEx7GNl7VU38wAtcmqZ8RTRuuM8/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=avaya.com;dmarc=pass action=none header.from=avaya.com;dkim=pass header.d=avaya.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NH2eQorqJcq5RCTK9gQyUwNXsQvOkju6yy+yvLjSbAo=; b=nc7GoQKoWpwI97tQ+F/dV7bRAfkDBpjA+uBSX4S03GG/kprjO5UW78I5JnxAaP0jKeuwRsmGCwV2b2dJrqFjKVDCfcwUA+Zbldbq/b6F0uQP0BQsysmYCErhMmVL9CCPXupEYKTgLLQeNebdSvKSuwqKP3mhBNON2PnYhZcH6/k= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2473.namprd15.prod.outlook.com (20.176.71.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 9 Jul 2019 20:11:47 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2052.020; Tue, 9 Jul 2019 20:11:47 +0000 From: "Mudric, Dusan (Dusan)" To: Jen Linkova CC: "Manfredi (US), Albert E" , IPv6 Operations , 6man <6man@ietf.org> Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AQHVNfZfQTP2spnzX0G8BrvKPAtN5qbCtR3w Date: Tue, 9 Jul 2019 20:11:47 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6d6d82ac-be4e-4edb-3c13-08d704a9abd5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DM6PR15MB2473; x-ms-traffictypediagnostic: DM6PR15MB2473: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:260; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(376002)(366004)(39860400002)(13464003)(199004)(189003)(25786009)(81156014)(1411001)(81166006)(9686003)(99936001)(6306002)(66616009)(66476007)(66556008)(8676002)(68736007)(4326008)(66446008)(64756008)(55016002)(76116006)(476003)(6916009)(486006)(66946007)(316002)(54906003)(5660300002)(14444005)(3846002)(478600001)(6116002)(5024004)(52536014)(256004)(8936002)(966005)(66066001)(19627235002)(6436002)(71190400001)(76176011)(229853002)(7736002)(71200400001)(55236004)(53546011)(99286004)(33656002)(7696005)(86362001)(6506007)(14454004)(102836004)(305945005)(446003)(26005)(11346002)(186003)(2906002)(74316002)(53936002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2473; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: z+k0J/Zrpojl8C4LLHwfj8mjMDIpOhgm6TqehQO6WBR+702gyn0o1wl3ZRzROTE5d6OMRXu+7kH5IvijIsPoZoGXBqfT6ctqndJgHNtpkEoMeTaSvXUvDCpoMnVDoIRj+Y3an1JJZFSmFkSlcRtrkv4CAkuo7CMUSSkw+5Cj3Y8m22ncjl0tl0me1pbc1c7w+EgLEfFsc3OGDf7ukxuxDxQxOq8vhPWcB/m/S7OM2UNtPAtKGbA2XAqkZI1TwxUer7bRFmZqmlwab7Fqmcm/1WvrvV2TWbbPAFv2cPUs8k21lYWMT6gKiAW20sIyIqM7+alXpfT1VgfaHXi0G2oMjt+b3DMDhM1Ev5BYwy9nvKhNH7mEQ9983cSi7KunPfE9E0ws4wjNizP66fqGSJwFhk84sBTUJgf3lqw04hMX7hU= Content-Type: multipart/mixed; boundary="_002_DM6PR15MB2506825AA181439E4151DD74BBF10DM6PR15MB2506namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6d6d82ac-be4e-4edb-3c13-08d704a9abd5 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 20:11:47.2148 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2473 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 20:12:20 -0000 --_002_DM6PR15MB2506825AA181439E4151DD74BBF10DM6PR15MB2506namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEplbi4gDQoNCkluIHlvdXIgZXhhbXBsZSAiIElQdjQtb25seSBjbGllbnQgbmVlZHMg dG8gdGFsayB0byB0aGUgSXB2Ni1vbmx5IHNlcnZlciIuIElmIElQdjQtb25seSBjbGllbnQgbmVl ZHMgdG8gdGFsayB0byB0aGUgSXB2Ni1vbmx5IGNsaWVudCwgdGhlIGNhbGwgZmxvdyB3aWxsIGJl IHRoZSBzYW1lPyBJbiB0aGUgb3RoZXIgZGlyZWN0aW9uLCBJUHY2LW9ubHkgY2xpZW50IGNhbGxp bmcgSVB2NC1vbmx5IGNsaWVudCBuZWVkcyB0byB1c2UgRE5TNjQvTkFUNjQsIGFzIGluIHlvdXIg cHJldmlvdXMgZXhhbXBsZSAoYXR0YWNoZWQpLiBUaGlzIG1lYW5zLCBmb3IgYmktZGlyZWN0aW9u YWwgY29tbXVuaWNhdGlvbiBOQVQ0Ni9ETlM0NiBhbmQgTkFUNjQvRE5TNjQgbmVlZCB0byBiZSB1 c2VkIChtYXkgYmUgbXkgdGVybWlub2xvZ3kgaXMgbm90IHF1aXRlIGNvcnJlY3QpLiANCg0KSG93 ZXZlciwgSm9yZGkgc2FpZCB0aGF0IHRoZSBwcm9ibGVtIGlzIG5vdCBmdWxseSBzb2x2ZWQgeWV0 ICgidGhlICphY3R1YWwqIGltcGxlbWVudGF0aW9uIG9mIDQ2NFhMQVQvTkFUNjQgZG9lc24ndCBh bGxvdyBJUHY0LW9ubHkgaG9zdHMgdG8gY29ubmVjdCB0byBJUHY2LW9ubHkgaG9zdHMuIikgYW5k IGhlIGlzIHdyaXRpbmcgZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxhdC1vcHQtY2RuLWNhY2hlcy4g V2hhdCBpcyBpbiB0aGUgY3VycmVudCB0ZWNobm9sb2d5IHRoYXQgcHJldmVudHMgYmktZGlyZWN0 aW9uYWwgY2FsbCBmbG93IGJldHdlZW4gSVB2NC1vbnkgYW5kIElQdjYtb25seSBob3N0cz8NCg0K RHVzYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKZW4gTGlua292 YSA8ZnVycnkxM0BnbWFpbC5jb20+DQo+IFNlbnQ6IE1vbmRheSwgSnVseSA4LCAyMDE5IDk6MzQg UE0NCj4gVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKSA8ZG11ZHJpY0BhdmF5YS5jb20+DQo+IENj OiBNYW5mcmVkaSAoVVMpLCBBbGJlcnQgRSA8YWxiZXJ0LmUubWFuZnJlZGlAYm9laW5nLmNvbT47 IElQdjYNCj4gT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuIDw2bWFuQGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSZTogTkFUNjQgaW4gUkEsIGRyYWZ0LWlldGYtNm1hbi1yYS1wcmVmNjQN Cj4gDQo+IE9uIFR1ZSwgSnVsIDksIDIwMTkgYXQgMTo1MCBBTSBNdWRyaWMsIER1c2FuIChEdXNh bikgPGRtdWRyaWNAYXZheWEuY29tPg0KPiB3cm90ZToNCj4gPiBbRHVzYW5dIFdoYXQgaWYgSVB2 NG9ubHkgY2xpZW50IG5lZWRzIHRvIGluaXRpYXRlIHRoZSBzZXNzaW9uIHRvIElQdjZvbmx5DQo+ IGNsaWVudD8gV2hhdCBpcyB0aGUgc29sdXRpb24gZm9yIHRoYXQgdXNlIGNhc2U/DQo+IA0KPiBo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX190 b29scy5pZXRmLm9yZ19odG1sX3JmYzc3NTUmZD1Ed0lCYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpI NjRRDQo+ICZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1f Y1dSc2R6b2Y1ZFhJDQo+IDl5VFFINTFIX0tIdGNTUmNNQXRBUkFyS1ZjZG5XTSZzPXdEeFdFd1Mt ZS1OLUkwb0FmY2RpLQ0KPiA1R3VjTmlDUXBSMzJ0OVJ3NFJaeW4wJmU9IG1lbnRpb25lZCBiZWZv cmUuDQo+IA0KPiBJUHY0LW9ubHkgY2xpZW50IC0tIElQdjQtZW5hYmxlZCBuZXR3b3JrLS0tIFNJ SVQgdHJhbnNsYXRvciAtLS0tIElQdjYtb25seSBMQU4gLQ0KPiAtLSBJUHY2LW9ubHkgc2VydmVy Lg0KPiANCj4gTGV0J3Mgc2F5ICB5b3VyIElQdjQtb25seSBjbGllbnQgbmVlZHMgdG8gdGFsayB0 byB0aGUgSXB2Ni1vbmx5IHNlcnZlciwgaXB2Ni0NCj4gb25seS5leGFtcGxlLm5ldC4NCj4gRm9y IHRoaXMgdG8gaGFwcGVuIHRoZSBvd25lciBvZiB0aGUgSXB2Ni1vbmx5IHNlcnZlciBuZWVkcyB0 byBjb25maWd1cmUgdGhlDQo+IHRyYW5zbGF0b3IgKFNJSVQgYm94IGluIHRoZSBkaWFncmFtIGFi b3ZlKS4NCj4gVGhlIG93bmVyIHdvdWxkIGNyZWF0ZSBhIEROUyBBIFJSIGZvciAgaXB2Ni1vbmx5 LmV4YW1wbGUubmV0LiAtIGxldCdzIHNheSwNCj4gMTkyLjAuMi4yIElwdjYtb25seSBzZXJ2ZXIg d291bGQgaGF2ZSBhbiBJUHY2IGFkZHJlc3Mgd2hpY2ggaGFzIHRoYXQgSVB2NA0KPiBhZGRyZXNz IGVuY29kZWQgLSBmb3IgZXhhbXBsZSwgMjAwMTpkYjg6MTo6MTkyLjAuMi4yIFRoYXQgSVB2NCBh ZGRyZXNzIChvcg0KPiB0aGUgcHJlZml4IG1vc3QgbGlrZWx5KSB3aWxsIGJlIHJvdXRlZCB0byB0 aGUgdHJhbnNsYXRvci4NCj4gDQo+IFNvIHlvdXIgSXB2NC1vbmx5IGNsaWVudCBzZW5kcyBhIERO UyByZXF1ZXN0IHRvIHJlc29sdmUgaXB2Ni0NCj4gb25seS5leGFtcGxlLm5ldCwgZ2V0cyAxOTIu MC4yLjIgYmFjaywgc2VuZHMgYSBwYWNrZXQgdG8gMTkyLjAuMi4yLg0KPiBUaGUgcGFja2V0IHJl YWNoZXMgdGhlIHRyYW5zbGF0b3IuIFRoZSB0cmFuc2xhdG9yIHRyYW5zbGF0ZXMgSVB2NCBwYWNr ZXQgdG8NCj4gSVB2NiBwYWNrZXQgYW5kIHNlbmRzIGl0IHRvIHRoZSBzZXJ2ZXIgKG5vdGUgdGhh dCB0aGUgZGVzdGluYXRpb24gSVB2NiBhZGRyZXNzDQo+IGNhbiBiZSBlYXNpbHkgY29uc3RydWN0 ZWQgYXMgdGhlIHRyYW5zbGF0b3Iga25vd3MgdGhlIHByZWZpeCBhbmQganVzdCBhZGRzIHRoZQ0K PiBJUHY0IGFkZHJlc3MgLSAxOTIuMC4yLjIgLSB0byB0aGF0IHByZWZpeCB0byBnZXQgdGhlIGRl c3RpbmF0aW9uIElQdjYgYWRkcmVzcy4NCj4gSVB2NiBzb3VyY2UgYWRkcmVzcyBpcyBzeW50aGVz aXNlZCBpbiB0aGUgc2FtZSB3YXkgZnJvbSB0aGUgY2xpZW50IElQdjQNCj4gYWRkcmVzcykuDQo+ IA0KPiBIZXJlIGlzIGEgbmljZSB0YWxrIFRvcmUgQW5kZXJzb24gZ2F2ZSBhdCBSSVBFIDcgeWVh cnMgYWdvOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtDQo+IDNBX19yaXBlNjQucmlwZS5uZXRfcHJlc2VudGF0aW9uc182Ny0yRDIwMTIwNDE3LTJE UklQRTY0LTJEVGhlLQ0KPiA1RkNhc2UtNUZmb3ItNUZJUHY2LTVGT25seS01RkRhdGEtDQo+IDVG Q2VudHJlcy5wZGYmZD1Ed0lCYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JM ZWFKDQo+IHhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1fY1dSc2R6b2Y1ZFhJOXlU UUg1MUhfS0h0Y1MNCj4gUmNNQXRBUkFyS1ZjZG5XTSZzPUdzUFRkUHJfWndXWUsxM0xJcmhUdjly WU02ZFlKZmdiVDhIdEx3VlJrDQo+IFpvJmU9DQo+IA0KPiANCj4gDQo+ID4gPiBGb3IgSVB2NCB0 byBJUHY2LCBpZiB5b3UgbXVzdCBhbGxvdyB0aGUgSVB2NCBjbGllbnQgdG8gaW5pdGlhdGUgdGhl DQo+ID4gPiBzZXNzaW9uLCB5b3UnZCBoYXZlIHRvIGhhdmUgcHJlY29uZmlndXJlIHNvbWV0aGlu Zy4NCj4gPiBbRHVzYW5dIFdoZXJlIGFuZCBob3cgaXMgdGhpcyBjb25maWd1cmF0aW9uIGRvbmU/ DQo+IA0KPiBPbiB0aGUgdHJhbnNsYXRvciB3aGljaCBjb25uZWN0cyBJUHY2LW9ubHkgbmV0d29y ayB0byBkdWFsLXN0YWNrL0lQdjQtb25seQ0KPiBvbmUuDQo+IEluIGdlbmVyYWwsIHdoZW4geW91 IG5lZWQgdG8gbGV0IG9uZSBwcm90b2NvbCB0YWxrIHRvIGFub3RoZXIsIHlvdSdkIGhhdmUgYQ0K PiBwb2ludCAob3IgdGhlIGVkZ2UpIHdoZXJlIHRob3NlIHR3byBuZXR3b3JrcyBtZWV0IGVhY2gg b3RoZXIuDQo+IFVzdWFsbHkgeW91J2QgaGF2ZSBhIGJveCAob3IgYm94ZXMpIGludGVyY29ubmVj dGluZyB0aGVtIC0gcXVpdGUgb2Z0ZW4gaXQncw0KPiBleGFjdGx5IHRoZSBib3ggeW91J2QgbmVl ZCB0byBjb25maWd1cmUgOykNCj4gDQo+IC0tDQo+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkN Cg== --_002_DM6PR15MB2506825AA181439E4151DD74BBF10DM6PR15MB2506namp_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 09 Jul 2019 20:11:46 GMT"; modification-date="Tue, 09 Jul 2019 20:11:46 GMT" Received: from BN7PR15MB2500.namprd15.prod.outlook.com (2603:10b6:4:3b::38) by DM6PR15MB2506.namprd15.prod.outlook.com with HTTPS via DM5PR03CA0049.NAMPRD03.PROD.OUTLOOK.COM; Fri, 5 Jul 2019 02:21:46 +0000 Received: from BN8PR15CA0014.namprd15.prod.outlook.com (2603:10b6:408:c0::27) by BN7PR15MB2500.namprd15.prod.outlook.com (2603:10b6:406:87::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Fri, 5 Jul 2019 02:21:44 +0000 Received: from CO1NAM03FT034.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::206) by BN8PR15CA0014.outlook.office365.com (2603:10b6:408:c0::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16 via Frontend Transport; Fri, 5 Jul 2019 02:21:44 +0000 Received: from PW365VMAP01.avaya.com (135.11.29.21) by CO1NAM03FT034.mail.protection.outlook.com (10.152.80.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Fri, 5 Jul 2019 02:21:43 +0000 Received: from AZ-US1EXHC02.global.avaya.com (135.11.85.13) by PW365VMAP01.avaya.com (135.11.29.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Thu, 4 Jul 2019 21:21:42 -0500 Received: from p-us1-erheast-smtpauth.us1.avaya.com (135.11.50.38) by AZ-US1EXHC02.global.avaya.com (135.11.85.13) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 4 Jul 2019 22:21:42 -0400 Received: from us1ppfilter.us1.avaya.com ([135.11.50.94]) by p-us1-erheast.us1.avaya.com with ESMTP; 04 Jul 2019 22:21:39 -0400 Received: from pps.filterd (us1ppfilter.us1.avaya.com [127.0.0.1]) by us1ppfilter.us1.avaya.com (8.16.0.21/8.16.0.21) with SMTP id x652K7MC022532 for ; Thu, 4 Jul 2019 22:21:41 -0400 Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by us1ppfilter.us1.avaya.com with ESMTP id 2te4mrx56s-1 for ; Thu, 04 Jul 2019 22:21:39 -0400 Received: from mail-qt1-f175.google.com ([209.85.160.175]) by p-us1-iereast.us1.avaya.com with ESMTP/TLS/AES128-GCM-SHA256; 04 Jul 2019 22:21:38 -0400 Received: by mail-qt1-f175.google.com with SMTP id d17so8341219qtj.8 for ; Thu, 04 Jul 2019 19:21:38 -0700 (PDT) From: Jen Linkova To: "Mudric, Dusan (Dusan)" CC: Fred Baker , IPv6 Operations , 6man <6man@ietf.org> Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 Thread-Index: AQHVMthYQTP2spnzX0G8BrvKPAtN5g== Date: Fri, 5 Jul 2019 02:21:25 +0000 Message-ID: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: Content-Language: en-US X-MS-Exchange-Organization-AuthSource: CO1NAM03FT034.eop-NAM03.prod.protection.outlook.com X-MS-Exchange-Organization-ComplianceLabelId: ddf901f2-09d6-417d-8c19-bf4f789a14e3 X-MS-Has-Attach: X-MS-Exchange-Organization-Network-Message-Id: 5dc34e8b-3def-4b0d-96bf-08d700ef85ed X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ironport-av: E=Sophos; i="5.63,453,1557201600"; d="scan'208"; a="351421538" 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=M/RFvdlV8rwPFY+uY1mVOPKUNPAWi9Cx1t2FCJgNPi8=; b=AbOz+2bpfMpujMR3vUGvx+jqo6UPinBKY537ZlG3vAPxtlDNgIoe9RugSxC7NaKaR6 2FmGifz+bOkLmfAL/gh2nw4j92e6kl9ImI+GN81f4pogp8wUxIYmp2SBUEhdrQnTYaws h+rRx5fBw+doNH4jcNaxsgpYbOEY0nQ/aKEnfqpbjUAMXhV0xs3gi5aiQbZ6R6h8ZawX hZ0Ui/2WVzRQgw0BuxUf1iHClUkbGauQ9XolAxEoYUYC88yVzbCjthwO+nda6T4nbjkC rXRczx2fRtm+4iym/Pr9eXp+HMfdE0riltZfGHtg5OPFCoJYeJcVmDwmILzFr7pqtPwe hE7A== x-proofpoint-virus-version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-04_10:,, signatures=0 x-proofpoint-spam-details: rule=inbound_no_bulk_notspam policy=inbound_no_bulk score=0 priorityscore=299 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=243 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=697 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907050030 x-ms-exchange-organization-originalclientipaddress: 135.11.29.21 x-ms-exchange-organization-originalserveripaddress: 10.152.80.177 received-spf: SoftFail (protection.outlook.com: domain of transitioning gmail.com discourages use of 135.11.29.21 as permitted sender) x-ms-publictraffictype: Email x-forefront-antispam-report: CIP:135.11.29.21; IPV:CAL; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(4636009)(2980300002)(13464003)(199004)(189003)(8156004)(95326003)(59536001)(68736007)(26005)(55446002)(53546011)(23676004)(486006)(54906003)(8676002)(5660300002)(5820100001)(50466002)(76176011)(47776003)(61266001)(81156014)(81166006)(476003)(34756004)(1096003)(498394004)(305945005)(86362001)(26826003)(76482006)(11346002)(446003)(8936002)(107886003)(69596002)(229853002)(966005)(6916009)(73972006)(4326008)(336012)(42186006)(73392003)(126002)(82202003)(53936002)(356004)(6666004)(6306002)(6246003); DIR:INB; SFP:; SCL:1; SRVR:BN7PR15MB2500; H:PW365VMAP01.avaya.com; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Antispam-Mailbox-Delivery: ucf:0; jmr:0; ex:0; auth:0; dest:I; ENG:(20160514016)(750119)(520011016)(944506303)(944626516); X-Microsoft-Antispam-Message-Info: =?utf-8?B?L0NJSTBjU2xBNmdyc2g0NnhYbXdUYVFoR09OSzlRalJUYVNHeE9iT0J1eTNL?= =?utf-8?B?RGlOeklXeWxyREtubFdzMmRoa1NnRGJHbStrSE1KKzcweVpPNzdYUDE1WlJW?= =?utf-8?B?MVhZQXZjRE5WMU5ZWFd4QjNueWRqajUvd2lmbnloMFhrUXN0eElyejRPdzBa?= =?utf-8?B?b1pYK0xaaG1PWFRVaUE2WjVia1BaQU5aUk94UmZtTGl1dEZGNmg1bS83T1hZ?= =?utf-8?B?bUF2dzFtL1BEY0xyWnZZVVVvWHl5b2VzWGI3MzhRaXBjMkNFaWJJRXducnBq?= =?utf-8?B?ZU0rR25rWGt2ejAyenB6UUIzMG9xRTN1YlhDcTh4cDMzYW1SZDB0Wkx3dkJS?= =?utf-8?B?N0FtR0xDVDgyMm1jYUgrOW1CTjhBcnFweTcxdVpNUFhNeDdFVm83NGRoTWg3?= =?utf-8?B?Y2xOM3JieFFDSm9HRkpTMHRHS3dGOFhMNkROaU1mQ2VBWng4KzdYQjR0b1BS?= =?utf-8?B?OEgwaEtjejlMVXB1TmVwdHZoOXdXb1FUZ2ViWEJKcDZJZjJtT3VDbDJBbFE3?= =?utf-8?B?dHQ1MkI3UDI1dWhLb0J6bzEzUkQ1SDMvd1ZtcWxOVlBpNk9kSWVNMTh3YkdQ?= =?utf-8?B?a0svdlBtbDVNSzUyb2FjcXZZUW55cVhYOFVORGZjN3VhREQvNDRUQ01ZeXJi?= =?utf-8?B?YytKUkFPOEViL3EvOUZQRzVWRFQxOVRsSXkvLzZvZDJDcmJQUzRicHFDRnBi?= =?utf-8?B?OG5iYUR5TVZZK1pML2Q0NTRRVmJHYVNLaW5XTnh0MEdKYjRqMlZFcU1yWmI5?= =?utf-8?B?WHE5dHJxNmdkZnRmbXIwaElHVzdObE9iUlVScEZINHZUc0RndFI3OEt6K01H?= =?utf-8?B?TVhpZjRXQldWclF5L3EvUEo0M3M4MVVuL1J4bi85aElsMjRPZTQ1cHhjOUZu?= =?utf-8?B?Qm5QY3R5T1lQYnJBNXpmRDhFZk1Cb05FTkpBeVB1RG5sczgwLys0YmV4V1JH?= =?utf-8?B?bXE2bHZ5QzdwMXVZREQ1c3hpaUNMVW96WExuOUR5NHVWSlN0SE1RT2pzTFA1?= =?utf-8?B?Y01rVTkvYi9MelFZYXJsU3I1cDJGNWZoZjFWeXpVNzFwTDU0c3N0VHprWWRE?= =?utf-8?B?V0NlUy9nZHdqWmh1eXNWNFh1T29wQTBPMUQ3MHQzQTFXM0wwaTNnUENzUnNj?= =?utf-8?B?K1kxdURqT21VQ2dKSklKVmRWclJVS1RKd0pXSUttTHVPcmJBVFk0N0QxWUtO?= =?utf-8?B?OTVhM3hpWGpwNklGSVBNcUoyVUpTbkxIbm9YTVVjcnVSZG1sQ2RXNkswZUk0?= =?utf-8?B?bHM2SjkrekJycnZGcFZmSVNiWEd1YnJrczJKc3B4SDVvb0NzMUV5QXNBOFUy?= =?utf-8?B?Wk5qQ0xrekN3WDJHa0oxNzRENVQ4Qko3dEtuMmRvenpjVFlKeENUazFhNDRK?= =?utf-8?B?VGVjZGNWNkRnUDFrbnBRekUrNjRITENOMjVMUGg0VkFXRUtUZFU0a3FEZHFj?= =?utf-8?B?UEFTa1VvenBqK2NBTFFtUnBhZ0txMDBRUzJBYlBBPT0=?= Content-Type: text/plain; charset="utf-8" Content-ID: <6EE5B9433BC93E4D9CFFC18756F1F012@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 SGkgRHVzYW4sDQoNCk9uIEZyaSwgSnVsIDUsIDIwMTkgYXQgNjoxOSBBTSBNdWRyaWMsIER1c2Fu IChEdXNhbikgPGRtdWRyaWNAYXZheWEuY29tPiB3cm90ZToNCj4gV2hhdCBpcyB0aGUgYmVzdCBy ZWZlcmVuY2UgZG9jdW1lbnQgZm9yIGEgVHJhbnNsYXRvciB0aGF0IGZhY2lsaXRhdGVzOg0KPg0K PiAtIElQdjRvbmx5IC0gdG8gLSBJUHY2b25seSwgYW5kDQoNCmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM3 NzU1JmQ9RHdJQmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNp Q3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1yWG4tcWNmU0loakIxRlZacTlmVDBIV0tJRTRG c1ZXNTVQdzR1ZmNkNFFjJnM9NmpneTgxZVBlaVdhQkZNTDNYd1BDM3dEeEdreURydnpXRzBKZzlP b2dfdyZlPQ0KDQo+IC0gSVB2Nm9ubHkgLSB0byAtIElQdjRPbmx5DQoNCmh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRt bF9yZmM2MTQ2JmQ9RHdJQmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVh SnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1yWG4tcWNmU0loakIxRlZacTlmVDBI V0tJRTRGc1ZXNTVQdzR1ZmNkNFFjJnM9U29iU0Z1dnpQbTlYUTNiV2hTRUxibmhrNEt0QWFZSjd5 QjVRV2Y3MEE2QSZlPQ0KDQo+IGNsaWVudHMgbWVzc2FnZSBleGNoYW5nZXM/DQo+DQo+IElzIHRo aXMgY29tbXVuaWNhdGlvbiBiaWRpcmVjdGlvbmFsIG9yIHdvcmtzIG9ubHkgZnJvbSBJUHY2b25s eS10by1JUHY0b25seSBjbGllbnQgKG1lYW5pbmcgSVB2Nm9ubHkgY2xpZW50IGhhcyB0byBpbml0 aWF0ZSB0aGUgY29tbXVuaWNhdGlvbik/DQo+DQo+IEhvdyBjYW4gVHJhbnNsYXRvciBvciBETlM2 NCB0ZWxsIElQdjYgb25seSBjbGllbnQgdGhlIElQIG9mIElQdjQgb25seSBjbGllbnQsIGFuZCB2 aWNlIHZlcnNhPw0KDQpJbiBhIG51dHNoZWxsOg0KDQpJUHY2LW9ubHkgY2xpZW50IGFza3MgRE5T NjQgc2VydmVyIGZvciBBQUFBIGZvciwgbGV0J3Mgc2F5LCBpcHY0b25seS5leGFtcGxlLm5ldA0K QXMgdGhhdCBzZXJ2ZXIgaXMgSVB2NC1vbmwsIGRvZXMgbm90IGhhdmUgQUFBQSBSUiwgdGhlIERO UzY0IHNlcnZlcg0Kc3ludGhlc2lzZSBhIG5ldyBBQUFBIHVzaW5nIGFuIElQdjYgcHJlZml4ICh1 c3VhbGx5IC85NiAtIHRoZQ0KV2VsbC1Lbm93biBQcmVmaXggaXMgNjQ6ZmY5Yjo6Lzk2KSBhbmQg SVB2NCBhZGRyZXNzIGZyb20gdGhlIEENClJSLiBUaGUgYWxnb3JpdGhtIGRlc2NyaWJlZCBpbiBy ZmM2MTQ3DQoNClNvIGlmIGlwdjRvbmx5LmV4YW1wbGUubmV0IGhhcyBhbiBJUHY0IGFkZHJlc3Mg MTkyLjAuMi4yLCB0aGVuIEROUzY0DQp3aWxsIHJldHVybiA2NDpmZjliOjoxOTIuMC4yLjIgYXMg QUFBQSBSUi4NClRoZSBpcHY2LW9ubHkgY2xpZW50IHdvdWxkIGluaXRpYXRlIGEgY29ubmVjdGlv biB0byB0aGF0IGFkZHJlc3MgLiBBcw0KTkFUNjQgcHJlZml4IGlzIHN1cHBvc2VkIHRvIGJlIHJv dXRlZCB0byB0aGUgTkFUNjQgZGV2aWNlLCB0aGF0IGRldmljZQ0Kd291bGQgdHJhbnNsYXRlIElQ djYgcGFja2V0IHRvIElQdjQgcGFja2V0IHVzaW5nIHRoZSBhbGdvcml0aG0NCmRlc2NyaWJlZCBp biBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rv b2xzLmlldGYub3JnX2h0bWxfcmZjNjA1MiZkPUR3SUJhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2 NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09clhuLXFj ZlNJaGpCMUZWWnE5ZlQwSFdLSUU0RnNWVzU1UHc0dWZjZDRRYyZzPVhUQ1lNalkzSE9LRXg1MzVQ VV9JT3JhOEpBaVJEX1VheXQxU3dySm5XdjgmZT0uDQoNCg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21haWwuY29t Pg0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAzLCAyMDE5IDM6MzIgUE0NCj4gPiBUbzogTXVk cmljLCBEdXNhbiAoRHVzYW4pIDxkbXVkcmljQGF2YXlhLmNvbT4NCj4gPiBDYzogNm1hbiA8Nm1h bkBpZXRmLm9yZz47IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+DQo+ID4gU3ViamVj dDogUmU6IE5BVDY0IGluIFJBLCBkcmFmdC1pZXRmLTZtYW4tcmEtcHJlZjY0DQo+ID4NCj4gPg0K PiA+DQo+ID4gPiBPbiBKdWwgMywgMjAxOSwgYXQgMTI6MDEgUE0sIE11ZHJpYywgRHVzYW4gKER1 c2FuKSA8ZG11ZHJpY0BhdmF5YS5jb20+DQo+ID4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gW0R1c2Fu XSBQbGVhc2UgY2xhcmlmeSBob3cgSVB2NC1vbmx5IGhvc3QgY2FuIHJlYWNoIElQdjYgb25seSBo b3N0LCBhbmQgdmljZQ0KPiA+IHZlcnNhLiBBbHNvLCBob3cgSVB2NiBvbmx5IGhvc3QgY2FuIGtu b3cgSVB2NCBhZGRyZXNzIG9mIElQdjQgb25seSBob3N0LA0KPiA+IGFzc3VtaW5nIElQdjQgb25s eSBob3N0IGlzIGluIGEgcHVibGljIGRvbWFpbj8NCj4gPg0KPiA+IFNpbXBsZS4gVXNpbmcgYSBU cmFuc2xhdG9yLCBlaXRoZXIgYXQgbGF5ZXIgMyBvciBhYm92ZSBpdC4gQW55IG90aGVyIHdheQ0K PiA+IGRvZXNuJ3Qgd29yay4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFRoZSBm YWN0IHRoYXQgdGhlcmUgaXMgYSBoaWdod2F5IHRvIGhlbGwgYW5kIGEgc3RhaXJ3YXkgdG8gaGVh dmVuIGlzIGFuDQo+ID4gaW50ZXJlc3RpbmcgY29tbWVudCBvbiBwcm9qZWN0ZWQgdHJhZmZpYyB2 b2x1bWUuLi4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9faXB2NiZkPUR3SUJhUSZjPUJGcFdRdzhic3VLcGwxU2dp Wkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09clhu LXFjZlNJaGpCMUZWWnE5ZlQwSFdLSUU0RnNWVzU1UHc0dWZjZDRRYyZzPUdIY05kRWh0T1ZKX2NM dk9JSWI2b05OREpJZ3BiOG1fb3FIaWVQcVlpY2cmZT0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCi0t DQpTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo= --_002_DM6PR15MB2506825AA181439E4151DD74BBF10DM6PR15MB2506namp_-- From nobody Tue Jul 9 13:24:18 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26A0120352; Tue, 9 Jul 2019 13:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=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=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 UYnmwVBkia7o; Tue, 9 Jul 2019 13:24:11 -0700 (PDT) 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 803071202CD; Tue, 9 Jul 2019 13:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562703845; x=1563308645; 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; bh=mPQY7GVUli6WZL1dKOTWn2 iJAB3XW6eLVUkqXdUmkdg=; b=LMppyJxeFPg7Pd78NVArhIgy72iIrVhH4fAYP4 BfT8u/uO2y1HSV1ZFWk0GEcehl7b3dHNloNO18cLYR3sytsnZemZRcwMvXmuOqKN mmBE/e7yuUejFnBNendELgTGv6kvacTQc9rETEJqoT5UN07VbBVN2RTsgTNTmgv2 EjdOs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 09 Jul 2019 22:24:05 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 09 Jul 2019 22:24:04 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006320714.msg; Tue, 09 Jul 2019 22:24:03 +0200 X-MDRemoteIP: 2001:470:1f09:495:5153:a097:6f4d:431c X-MDHelo: [10.10.10.139] X-MDArrival-Date: Tue, 09 Jul 2019 22:24:03 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1093b5d1d9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Tue, 09 Jul 2019 22:24:01 +0200 From: JORDI PALET MARTINEZ To: "Mudric, Dusan (Dusan)" , IPv6 Operations CC: 6man <6man@ietf.org> Message-ID: Thread-Topic: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3645555841_649128464" Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 20:24:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3645555841_649128464 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Dusan, =20 The problem is that the IPv6-only =E2=80=9Cremote server=E2=80=9D don=E2=80= =99t have IPv4 connectivity. Also, it doesn=E2=80=99t have an IPv4 address.= Let=E2=80=99s suppose this is a streaming server. =20 The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is an IPv= 4-only SmartTV), is connected to a CLAT (this is in the CPE, and the CPE is= connected via IPv6-only) to the service provider. =20 The optimization that we are suggesting is using EAM (explicit mapping) to = avoid the IPv4 flow from the smartTV to be converted back to IPv4, because = the CLAT already converted it to IPv6. =20 If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming server, the= CLAT will create an EAMT, so because it believes the streaming service is = reachable with IPv4 (which is not), but the =E2=80=9Coptimized CLAT=E2=80= =9D will then use the AAAA. =20 So, the flow is: IPv4 from the smartTV to the CLAT IPv6 from the CLAT to the streaming service =20 In normal conditions, if the streaming service is really dual-stack and we = don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D 464XLAT proto= col), it will be: =20 IPv4 from the smartTV to the CLAT IPv6 from the CLAT to the NAT64 IPv4 from the NAT64 to the streaming service =20 If the streaming service is IPv6 only, with the actual 464XLAT protocol, th= is connectivity is not possible. =20 You see the point? =20 Please take a look at the document, I think is well described, otherwise pr= ovide suggestions about what you believe is not clear enough and we will ma= ke sure to improve the text and drawings! =20 By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80=9D, wh= ich I think is the best solution. =20 Regards, Jordi @jordipalet =20 =20 =20 El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: =20 Hi Jordi, =20 Are you saying your draft =E2=80=9C464XLAT Optimization=E2=80=9D will prov= ide IPv4only app to IPv6only app communication like this? =20 =20 +-------+ .-----. =20 | IPv6 | / \ =20 .-----. | CE | / IPv6- \ .-----. =20 / IPv4- \ | or +--( only )---( NAT64 ) / only \ | UE | \ Access /\ `-----' =20 ( SmartTV )--+ | \ / \ =20 \ STB / | with | `--+--' \ .-----. =20 \ VoIP / | NAT46 | | \ / \ `-----' | CLAT | +---+----+ / IPv6 \ .--+--. | | | DNS/ | ( Internet )IPv6/ IPv6- \ +-------+ | DNS64 | \ /----/ only \ +--------+ \ / ( ) `-----' \ APP / \ / `-----' <------------------------ IPv4 to IPv6 flow ------------------------> =20 What did not work so far and what had to be added in your draft to make thi= s flow work? =20 How can IPv6-only APP get the IPV4 public address, used by NAT_translator, = when sending a packet from IPv6-ony APP to IPv4-only APP? This IPv4 address= is the same destination IPv4 address to which IPv4-only APP sends a packet= towards IPv6-only APP ( 192.0.2.2. address in Jen=E2=80=99s example). =20 Thanks, Dusan. =20 From: v6ops On Behalf Of JORDI PALET MARTINEZ Sent: Monday, July 8, 2019 5:40 PM To: IPv6 Operations Cc: 6man <6man@ietf.org> Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 =20 I think there are several possible solutions, but the simpler one seems to = be the dual-stack SIP proxies. Another one is draft-ietf-tram-turnbis, whic= h I didn=E2=80=99t knew, until today, is already in the IESG for approval t= his Thrusday. Also it can be done with EAM and also as I mention in a previous email via = the optimization for 464XLAT. Just uploaded the new version: =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?= include_text=3D1 =20 =20 =20 =20 =20 El 8/7/19 19:01, "v6ops en nombre de David Farmer" escribi=C3=B3: =20 =20 =20 On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) w= rote: > -----Original Message----- > From: Manfredi (US), Albert E >=20 > -----Original Message----- > From: ipv6 On Behalf Of Mudric, Dusan (Dusan) >=20 > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and v= ice > versa? >=20 > IPv6 to IPv4 should be straightforward, because it's a one-to-one > relationship. The other way around would normally not work,=20 [Dusan] There is no solution for IPv4only client to reach IPv6only client?= =20 =20 I mostly say, so what! It is an unfortunate reality of today's Internet, be= cause of NAT44 and/or stateful firewall default deny inbound policy, many t= imes clients can't speak to other clients, be they IPv4 only, IPv6 only, or= even dual stack. Sometimes firewall traversal technologies can work around= this, also depending on the firewall traversal solution used sometimes IPv= 4 only and IPv6 only clients will be able to talk to each other. My guess = is that IPv4 only to IPv6 only firewall traversal would be less effective t= han NAT44 client to NAT44 client firewall traversal, but it is should still= be possible in some cases.=20 =20 > but everyone > has been accustomed to that with IPv4 NAPT already.=20 [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed= not to be able to call IPv6only users (like Apple IPv6 only phones)? =20 They may not be able to talk peer to peer. However, through a dual-stack SI= P or other proxies/session border controller, they could probably complete = a call.=20 =20 >The client behind the > NAPT initiates. >=20 > > Is DNS64 server returning IPv4ony client address to IPv6only client, us= ing > the A RR? >=20 > The DNS synthesizes the IPv6 address, which has the IPv4 address > embedded in it. >=20 > > - How can IPv4only client get the address of IPv6only client (or, it is > impossible for IPv4only client to get IPv6 address of IPv6only client)? >=20 > That's clearly more difficult, which is why the normal course of action i= s for > the IPv6 client to initiate the session.. [Dusan] What if IPv4only client needs to initiate the session to IPv6only c= lient? What is the solution for that use case? =20 Many firewall traversal solutions should work in this case, but IPv4 only c= lient to client isn't guaranteed to work in all cases either.=20 =20 >=20 > > - Do these IPv4 and IPv6 client addresses need to be pre-configured on = the > translator and/or DNS64? >=20 > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the sessi= on, you'd > have to have preconfigure something. [Dusan] Where and how is this configuration done? >=20 > Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. --B_3645555841_649128464 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Dusan,

 

The problem is that th= e IPv6-only =E2=80=9Cremote server=E2=80=9D don=E2=80=99t have IPv4 connect= ivity. Also, it doesn=E2=80=99t have an IPv4 address. Let=E2=80=99s suppose= this is a streaming server.

&= nbsp;

The =E2=80=9Clocal=E2=80=9D IPv4-o= nly host (let=E2=80=99s suppose is an IPv4-only SmartTV), is connected to a= CLAT (this is in the CPE, and the CPE is connected via IPv6-only) to the s= ervice provider.

 <= /span>

The optimization that we are suggesting is usi= ng EAM (explicit mapping) to avoid the IPv4 flow from the smartTV to be con= verted back to IPv4, because the CLAT already converted it to IPv6.

 

If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming server= , the CLAT will create an EAMT, so because it believes the streaming servic= e is reachable with IPv4 (which is not), but the =E2=80=9Coptimized CLAT=E2= =80=9D will then use the AAAA.

 

So, the flow is:

IPv4 from the smartTV to the CLAT

IPv6 from the CLAT to the streaming service

 

In normal conditions, if the streaming service is really dual-stack an= d we don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D 464XLAT = protocol), it will be:

 <= /o:p>

IPv4 from the smartTV to the CLAT

IPv6 from the CLAT to the NAT64

IPv4 from the NAT64 to the streaming service=

 

If the streaming service is IPv6 only, with the actual 464XLAT= protocol, this connectivity is not possible.

 

You see the point= ?

 

Please take a look at the document, I think is wel= l described, otherwise provide suggestions about what you believe is not cl= ear enough and we will make sure to improve the text and drawings!

 

By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80=9D= , which I think is the best solution.

 

Regards,

Jordi

@jor= dipalet

 

&= nbsp;

 

<= div>

El 9/7/19 22:05, &quo= t;v6ops en nombre de Mudric, Dusan (Dusan)" <v6ops-bounces@ietf.org en nombre de dmudric@avaya.com> escribi=C3=B3:

&= nbsp;

Hi J= ordi,

 = ;

Are you s= aying your draft  =E2=80=9C464XLAT= Optimization=E2=80=9D will provide IPv4only app to IPv6only app communication like this?

 

 

       &nbs= p;          +-------+ &nb= sp;   .-----.        &nbs= p;          =

      &= nbsp;           | IP= v6  |    /       \ &= nbsp;           &nbs= p; 

 &nbs= p;    .-----.     |  CE &= nbsp; |   /  IPv6-  \     .-----.&n= bsp;  

&n= bsp;    / IPv4- \    |  or &nb= sp; +--(   only    )---( NAT64 )=

    /  only =   \   |  UE   |   \  Access /\=     `-----'    

   (&n= bsp; SmartTV  )--+       |  &n= bsp; \       /  \    = ;        

    \   STB&nb= sp;  /   | with  |     `--+--' = ;   \   .-----.     

    &nb= sp;\ VoIP  /    | NAT46 |     =    |        \ /  &nb= sp;    \

      `-----'     | CLAT&n= bsp; |    +---+----+    /  IPv6 &nb= sp; \      .--+--.

        &= nbsp;         |   &n= bsp;   |    |  DNS/  |   (&nbs= p; Internet )IPv6/ IPv6- \

           &= nbsp;      +-------+    |  DNS= 64 |    \         /-= ---/  only   \

           = ;            &n= bsp;       +--------+    = \       /    (  &nb= sp;        )

        = ;            &n= bsp;            = ;            &n= bsp; `-----'      \  APP    /<= /span>

   &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      \      &n= bsp;/

  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         `-----'

   <------------------------ IPv4 to IPv6 flow ----------= -------------->

 

What did not work so far and what had to be added in your draft = to make this flow work?

 

How can IPv6-only APP get the IPV4 public address, used by NAT_tra= nslator, when sending a packet from IPv6-ony APP to IPv4-only APP? This IPv= 4 address is the same destination IPv4 address to which IPv4-only APP sends= a packet towards IPv6-only APP ( 192.0.2.2. address in Jen=E2=80=99s examp= le).

 =

Thanks,

Dusan.

 =

= From: v6ops <v6ops-bounces@ietf.org> On Behalf Of JORDI= PALET MARTINEZ
Sent: Monday, July 8, 2019 5:40 PM
To: = IPv6 Operations <v6ops@ietf.org>
Cc: 6man <6man@ietf.org= >
Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64<= o:p>

 

I think there are several possible solutions, but the simpl= er one seems to be the dual-stack SIP proxies. Another one is draft-ietf-tr= am-turnbis, which I didn=E2=80=99t knew, until today, is already in the IES= G for approval this Thrusday.

Also it can be don= e with EAM and also as I mention in a previous email via the optimization f= or 464XLAT. Just uploaded the new version:

 = ;

https://datatracker.ietf.org/doc/draft-palet-v6ops-464x= lat-opt-cdn-caches/?include_text=3D1

 <= /span>

 

 <= o:p>

 

 

El 8= /7/19 19:01, "v6ops en nombre de David Farmer" <v6ops-bounces@ietf.org en nombre de farmer@umn.edu> escribi=C3=B3:=

 

=

 

 

On Mon, Jul 8, 20= 19 at 10:49 AM Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote:

> -----Original Message--= ---
> From: Manfredi (US), Albert E <albert.e.manfredi@boeing.com>>
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Mudric, Dusan (Dusan)
>
> > - How can D= NS64 tell IPv6 only client the IP of IPv4 only client, and vice
> ver= sa?
>
> IPv6 to IPv4 should be straightforward, because it's a= one-to-one
> relationship. The other way around would normally not w= ork,
[Dusan] There is no solution for IPv4only client to reach IPv6only= client?

> but everyone
> has been accustomed to that with IPv4 NAPT al= ready.
[Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be= accustomed not to be able to call IPv6only users (like Apple IPv6 only pho= nes)?

=

>The client behind the=
> NAPT initiates.
>
> > Is DNS64 server returning IP= v4ony client address to IPv6only client, using
> the A RR?
> > The DNS synthesizes the IPv6 address, which has the IPv4 address
= > embedded in it.
>
> > - How can IPv4only client get th= e address of IPv6only client (or, it is
> impossible for IPv4only cli= ent to get IPv6 address of IPv6only client)?
>
> That's clearl= y more difficult, which is why the normal course of action is for
> t= he IPv6 client to initiate the session..
[Dusan] What if IPv4only client= needs to initiate the session to IPv6only client? What is the solution for= that use case?

<= p class=3DMsoNormal style=3D'margin-left:70.8pt'>

 

--

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer  &= nbsp;            Email:farmer@umn.edu
Networking &= ; Telecommunication Services
Office of Information Technology
Univers= ity of Minnesota  
2218 University Ave SE     =   Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell:= 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

_______________________________________________ v6ops mailing l= ist v6ops@ietf.org http= s://www.ietf.org/mailman/listinfo/v6ops


**********************************************
I= Pv4 is over
Are you ready for the new Internet ?
http://www.theipv6= company.com
The IPv6 Company

This electronic message contains= information which may be privileged or confidential. The information is in= tended to be for the exclusive use of the individual(s) named above and fur= ther non-explicilty authorized disclosure, copying, distribution or use of = the contents of this information, even if partially, including attached fil= es, is strictly prohibited and will be considered a criminal offense. If yo= u are not the intended recipient be aware that any disclosure, copying, dis= tribution or use of the contents of this information, even if partially, in= cluding attached files, is strictly prohibited, will be considered a crimin= al offense, so you must reply to the original sender to inform about this communication and delete it.=

_________= ______________________________________ v6ops mailing list v6ops@ietf.org ht= tps://www.ietf.org/mailman/listinfo/v6ops


********= **************************************
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.

--B_3645555841_649128464-- From nobody Tue Jul 9 13:27:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7742912007A; Tue, 9 Jul 2019 13:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 2ajEUcyA-A8p; Tue, 9 Jul 2019 13:27:53 -0700 (PDT) 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 1863212006D; Tue, 9 Jul 2019 13:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562704070; x=1563308870; 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=5e+N8mYyMe5nMU9sC5Oh/Z4l40YSI3KTBwBEt8StkC0=; b=ICYVNAJZDjRHy dUM4kxKO6fVt2Z7H1Woo9EAfyVcFGAuj8YGmO59GMFLGs9aWmL60W3bt3+fcXH99 l5MBkVFzJK87coX1oTK5nuSVTOsTDqPRPbiY2M+Ka8xpzwDPWe/yrcteOkKPsDCF rL5rQTCShLSi2PRSb8+h2SQFPY03JY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 09 Jul 2019 22:27:50 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 09 Jul 2019 22:27:49 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006320720.msg; Tue, 09 Jul 2019 22:27:49 +0200 X-MDRemoteIP: 2001:470:1f09:495:5153:a097:6f4d:431c X-MDHelo: [10.10.10.139] X-MDArrival-Date: Tue, 09 Jul 2019 22:27:49 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1093b5d1d9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Tue, 09 Jul 2019 22:27:47 +0200 From: JORDI PALET MARTINEZ To: "Mudric, Dusan (Dusan)" CC: IPv6 Operations , 6man <6man@ietf.org> Message-ID: <71018197-3A57-40F8-8AE2-8D987DEFEADC@consulintel.es> Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 20:27:55 -0000 If you do "manual" EAM configurations at each side, it is fully solved, but= is this useful in a generic case. So what I'm trying to do with the optimization is that the EAM creation is = "automated". Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 9/7/19 22:13, "ipv6 en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: Thanks Jen.=20 =20 In your example " IPv4-only client needs to talk to the Ipv6-only serve= r". If IPv4-only client needs to talk to the Ipv6-only client, the call flo= w will be the same? In the other direction, IPv6-only client calling IPv4-o= nly client needs to use DNS64/NAT64, as in your previous example (attached)= . This means, for bi-directional communication NAT46/DNS46 and NAT64/DNS64 = need to be used (may be my terminology is not quite correct).=20 =20 However, Jordi said that the problem is not fully solved yet ("the *act= ual* implementation of 464XLAT/NAT64 doesn't allow IPv4-only hosts to conne= ct to IPv6-only hosts.") and he is writing draft-palet-v6ops-464xlat-opt-cd= n-caches. What is in the current technology that prevents bi-directional ca= ll flow between IPv4-ony and IPv6-only hosts? =20 Dusan =20 > -----Original Message----- > From: Jen Linkova > Sent: Monday, July 8, 2019 9:34 PM > To: Mudric, Dusan (Dusan) > Cc: Manfredi (US), Albert E ; IPv6 > Operations ; 6man <6man@ietf.org> > Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64 >=20 > On Tue, Jul 9, 2019 at 1:50 AM Mudric, Dusan (Dusan) > wrote: > > [Dusan] What if IPv4only client needs to initiate the session to IP= v6only > client? What is the solution for that use case? >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_rfc7755&d=3DDwIBaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q > &r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_cWRsdzof5dXI > 9yTQH51H_KHtcSRcMAtARArKVcdnWM&s=3DwDxWEwS-e-N-I0oAfcdi- > 5GucNiCQpR32t9Rw4RZyn0&e=3D mentioned before. >=20 > IPv4-only client -- IPv4-enabled network--- SIIT translator ---- IPv6= -only LAN - > -- IPv6-only server. >=20 > Let's say your IPv4-only client needs to talk to the Ipv6-only serve= r, ipv6- > only.example.net. > For this to happen the owner of the Ipv6-only server needs to configu= re the > translator (SIIT box in the diagram above). > The owner would create a DNS A RR for ipv6-only.example.net. - let's= say, > 192.0.2.2 Ipv6-only server would have an IPv6 address which has that = IPv4 > address encoded - for example, 2001:db8:1::192.0.2.2 That IPv4 addres= s (or > the prefix most likely) will be routed to the translator. >=20 > So your Ipv4-only client sends a DNS request to resolve ipv6- > only.example.net, gets 192.0.2.2 back, sends a packet to 192.0.2.2. > The packet reaches the translator. The translator translates IPv4 pac= ket to > IPv6 packet and sends it to the server (note that the destination IPv= 6 address > can be easily constructed as the translator knows the prefix and just= adds the > IPv4 address - 192.0.2.2 - to that prefix to get the destination IPv6= address. > IPv6 source address is synthesised in the same way from the client IP= v4 > address). >=20 > Here is a nice talk Tore Anderson gave at RIPE 7 years ago: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__ripe64.ripe.net_presentations_67-2D20120417-2DRIPE64-2DThe- > 5FCase-5Ffor-5FIPv6-5FOnly-5FData- > 5FCentres.pdf&d=3DDwIBaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJ > xhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D_cWRsdzof5dXI9yTQH51H_KHtcS > RcMAtARArKVcdnWM&s=3DGsPTdPr_ZwWYK13LIrhTv9rYM6dYJfgbT8HtLwVRk > Zo&e=3D >=20 >=20 >=20 > > > For IPv4 to IPv6, if you must allow the IPv4 client to initiate t= he > > > session, you'd have to have preconfigure something. > > [Dusan] Where and how is this configuration done? >=20 > On the translator which connects IPv6-only network to dual-stack/IPv4= -only > one. > In general, when you need to let one protocol talk to another, you'd = have a > point (or the edge) where those two networks meet each other. > Usually you'd have a box (or boxes) interconnecting them - quite ofte= n it's > exactly the box you'd need to configure ;) >=20 > -- > SY, Jen Linkova aka Furry -------------------------------------------------------------------- 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 Jul 9 13:54:49 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CBC120046; Tue, 9 Jul 2019 13:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=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=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 Sq_lTKNmMoeq; Tue, 9 Jul 2019 13:54:43 -0700 (PDT) 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 B546E12000E; Tue, 9 Jul 2019 13:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562705681; x=1563310481; 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; bh=UPaTpWMSytKzta+2rNyKya 61lUGI0ShRyQHp9rwJEXQ=; b=HZ72jAEbKeXpQroKBvqPZGU8IneEls2XaLkqME wg/BUFizqzFJQZH64gddIH8sTRNXU6FEpCV19sWjiCNrEKbKm4blBaIZb/bAu46k M3bt/cAScCZJL2FNUIiaeh7b/lTZGBOH71/+XvC1BS9BI8vhjlqdCtKJiNBp1WDw Z7FbM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 09 Jul 2019 22:54:41 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 09 Jul 2019 22:54:39 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006320735.msg; Tue, 09 Jul 2019 22:54:39 +0200 X-MDRemoteIP: 2001:470:1f09:495:e078:75ed:8505:ff6 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Tue, 09 Jul 2019 22:54:39 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1093b5d1d9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Tue, 09 Jul 2019 22:54:38 +0200 From: JORDI PALET MARTINEZ To: "Mudric, Dusan (Dusan)" , IPv6 Operations CC: 6man <6man@ietf.org> Message-ID: Thread-Topic: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3645557679_564410298" Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 20:54:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3645557679_564410298 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =EF=BB=BFBy the way, the difference between this and using SIIT-DC, is that= in SIIT-DC the flow will be: =20 IPv4 from the smartTV to the CLAT IPv6 from the CLAT to the NAT64 IPv4 from the NAT64 to the SIIT-DC BR IPv6 from the SIIT-DC BR to the streaming service =20 Note that our main goal with this work, was not to make =E2=80=9Ca new SIIT= -DC=E2=80=9D, but to make sure that IPv4-only devices behind a CLAT don=E2= =80=99t need to use the NAT64 if the services (such as CDNs, caches, etc.) = are already IPv6-enabled. =20 Regards, Jordi @jordipalet =20 =20 =20 El 9/7/19 22:25, "ipv6 en nombre de JORDI PALET MARTINEZ" escribi= =C3=B3: =20 Hi Dusan, =20 The problem is that the IPv6-only =E2=80=9Cremote server=E2=80=9D don=E2=80= =99t have IPv4 connectivity. Also, it doesn=E2=80=99t have an IPv4 address.= Let=E2=80=99s suppose this is a streaming server. =20 The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is an IPv= 4-only SmartTV), is connected to a CLAT (this is in the CPE, and the CPE is= connected via IPv6-only) to the service provider. =20 The optimization that we are suggesting is using EAM (explicit mapping) to = avoid the IPv4 flow from the smartTV to be converted back to IPv4, because = the CLAT already converted it to IPv6. =20 If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming server, the= CLAT will create an EAMT, so because it believes the streaming service is = reachable with IPv4 (which is not), but the =E2=80=9Coptimized CLAT=E2=80= =9D will then use the AAAA. =20 So, the flow is: IPv4 from the smartTV to the CLAT IPv6 from the CLAT to the streaming service =20 In normal conditions, if the streaming service is really dual-stack and we = don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D 464XLAT proto= col), it will be: =20 IPv4 from the smartTV to the CLAT IPv6 from the CLAT to the NAT64 IPv4 from the NAT64 to the streaming service =20 If the streaming service is IPv6 only, with the actual 464XLAT protocol, th= is connectivity is not possible. =20 You see the point? =20 Please take a look at the document, I think is well described, otherwise pr= ovide suggestions about what you believe is not clear enough and we will ma= ke sure to improve the text and drawings! =20 By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80=9D, wh= ich I think is the best solution. =20 Regards, Jordi @jordipalet =20 =20 =20 El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: =20 Hi Jordi, =20 Are you saying your draft =E2=80=9C464XLAT Optimization=E2=80=9D will prov= ide IPv4only app to IPv6only app communication like this? =20 =20 +-------+ .-----. =20 | IPv6 | / \ =20 .-----. | CE | / IPv6- \ .-----. =20 / IPv4- \ | or +--( only )---( NAT64 ) / only \ | UE | \ Access /\ `-----' =20 ( SmartTV )--+ | \ / \ =20 \ STB / | with | `--+--' \ .-----. =20 \ VoIP / | NAT46 | | \ / \ `-----' | CLAT | +---+----+ / IPv6 \ .--+--. | | | DNS/ | ( Internet )IPv6/ IPv6- \ +-------+ | DNS64 | \ /----/ only \ +--------+ \ / ( ) `-----' \ APP / \ / `-----' <------------------------ IPv4 to IPv6 flow ------------------------> =20 What did not work so far and what had to be added in your draft to make thi= s flow work? =20 How can IPv6-only APP get the IPV4 public address, used by NAT_translator, = when sending a packet from IPv6-ony APP to IPv4-only APP? This IPv4 address= is the same destination IPv4 address to which IPv4-only APP sends a packet= towards IPv6-only APP ( 192.0.2.2. address in Jen=E2=80=99s example). =20 Thanks, Dusan. =20 From: v6ops On Behalf Of JORDI PALET MARTINEZ Sent: Monday, July 8, 2019 5:40 PM To: IPv6 Operations Cc: 6man <6man@ietf.org> Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 =20 I think there are several possible solutions, but the simpler one seems to = be the dual-stack SIP proxies. Another one is draft-ietf-tram-turnbis, whic= h I didn=E2=80=99t knew, until today, is already in the IESG for approval t= his Thrusday. Also it can be done with EAM and also as I mention in a previous email via = the optimization for 464XLAT. Just uploaded the new version: =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?= include_text=3D1 =20 =20 =20 =20 =20 El 8/7/19 19:01, "v6ops en nombre de David Farmer" escribi=C3=B3: =20 =20 =20 On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) w= rote: > -----Original Message----- > From: Manfredi (US), Albert E >=20 > -----Original Message----- > From: ipv6 On Behalf Of Mudric, Dusan (Dusan) >=20 > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and v= ice > versa? >=20 > IPv6 to IPv4 should be straightforward, because it's a one-to-one > relationship. The other way around would normally not work,=20 [Dusan] There is no solution for IPv4only client to reach IPv6only client?= =20 =20 I mostly say, so what! It is an unfortunate reality of today's Internet, be= cause of NAT44 and/or stateful firewall default deny inbound policy, many t= imes clients can't speak to other clients, be they IPv4 only, IPv6 only, or= even dual stack. Sometimes firewall traversal technologies can work around= this, also depending on the firewall traversal solution used sometimes IPv= 4 only and IPv6 only clients will be able to talk to each other. My guess = is that IPv4 only to IPv6 only firewall traversal would be less effective t= han NAT44 client to NAT44 client firewall traversal, but it is should still= be possible in some cases.=20 =20 > but everyone > has been accustomed to that with IPv4 NAPT already.=20 [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed= not to be able to call IPv6only users (like Apple IPv6 only phones)? =20 They may not be able to talk peer to peer. However, through a dual-stack SI= P or other proxies/session border controller, they could probably complete = a call.=20 =20 >The client behind the > NAPT initiates. >=20 > > Is DNS64 server returning IPv4ony client address to IPv6only client, us= ing > the A RR? >=20 > The DNS synthesizes the IPv6 address, which has the IPv4 address > embedded in it. >=20 > > - How can IPv4only client get the address of IPv6only client (or, it is > impossible for IPv4only client to get IPv6 address of IPv6only client)? >=20 > That's clearly more difficult, which is why the normal course of action i= s for > the IPv6 client to initiate the session.. [Dusan] What if IPv4only client needs to initiate the session to IPv6only c= lient? What is the solution for that use case? =20 Many firewall traversal solutions should work in this case, but IPv4 only c= lient to client isn't guaranteed to work in all cases either.=20 =20 >=20 > > - Do these IPv4 and IPv6 client addresses need to be pre-configured on = the > translator and/or DNS64? >=20 > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the sessi= on, you'd > have to have preconfigure something. [Dusan] Where and how is this configuration done? >=20 > Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. -------------------------------------------------------------------- IETF I= Pv6 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. --B_3645557679_564410298 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

=EF=BB=BF<= span lang=3DEN-US style=3D'font-size:12.0pt'>By the way, the difference bet= ween this and using SIIT-DC, is that in SIIT-DC the flow will be:

 

IPv4 from the smartTV to the CLAT=

IPv6 from the CLAT to the NAT64<= span lang=3DEN-US>

IPv4 from the NA= T64 to the SIIT-DC BR

IPv6 from th= e SIIT-DC BR to the streaming service<= /span>

 

Note that our main goal with this work, was not to make =E2=80=9Ca new SII= T-DC=E2=80=9D, but to make sure that IPv4-only devices behind a CLAT don=E2= =80=99t need to use the NAT64 if the services (such as CDNs, caches, etc.) = are already IPv6-enabled.

&nbs= p;

Regards,

Jordi

@jordipalet

 

 

 

El 9/7/19 22:25, "ipv6 en = nombre de JORDI PALET MARTINEZ" <ipv6-bounces@ietf.org en nombre de jordi.palet=3D40consulintel.es@dmarc.ie= tf.org> escribi=C3=B3:

 

Hi Dusan,

 

The problem is that the IPv6-only = =E2=80=9Cremote server=E2=80=9D don=E2=80=99t have IPv4 connectivity. Also,= it doesn=E2=80=99t have an IPv4 address. Let=E2=80=99s suppose this is a s= treaming server.

 

The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppo= se is an IPv4-only SmartTV), is connected to a CLAT (this is in the CPE, an= d the CPE is connected via IPv6-only) to the service provider.<= /o:p>

 <= /o:p>

The optimization t= hat we are suggesting is using EAM (explicit mapping) to avoid the IPv4 flo= w from the smartTV to be converted back to IPv4, because the CLAT already c= onverted it to IPv6.

&n= bsp;

I= f we create a =E2=80=9Cfake=E2=80=9D A record in the streaming server, the = CLAT will create an EAMT, so because it believes the streaming service is r= eachable with IPv4 (which is not), but the =E2=80=9Coptimized CLAT=E2=80=9D= will then use the AAAA.

 

So, the flow is:

IPv4 from the smartTV to the CLAT

IPv6 from th= e CLAT to the streaming service

 

In normal conditions, if the streaming service is really dual-sta= ck and we don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D 464= XLAT protocol), it will be:

 

IPv4 from the smartTV to the CLAT<= /p>

IPv6 from the CLAT to th= e NAT64

IPv4 from the NAT64 to the streaming service

 

If the streaming service is IPv6 = only, with the actual 464XLAT protocol, this connectivity is not possible.<= /span>

 =

You s= ee the point?

 

Please take a look at the document, I think is well described, oth= erwise provide suggestions about what you believe is not clear enough and w= e will make sure to improve the text and drawings!

 

By the way, I=E2=80=99m talki= ng here about =E2=80=9Capproach 2=E2=80=9D, which I think is the best solution.

 

Regards,

Jordi

@jordipalet

 <= /o:p>

 

 

El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" <= ;v6ops-bounces@ietf.org en no= mbre de dmudric@avaya.com> escr= ibi=C3=B3:

 

Hi Jordi,

 

Are you saying your draft  =E2=80=9C464XLAT Optimization=E2=80=9D will provide IPv4only app to IPv6only app comm= unication like this?

 

 

    = ;            &n= bsp; +-------+     .-----.     = ;            &n= bsp;

  &n= bsp;            = ;   | IPv6  |    /   &nbs= p;   \          = ;     

      .-----= .     |  CE   |   /  IPv6= -  \     .-----.   

     / IP= v4- \    |  or   +--(   only &= nbsp;  )---( NAT64 )

    /  only   \   |  U= E   |   \  Access /\    `-----'&nbs= p;   

    \   STB   / &= nbsp; | with  |     `--+--'    \&nb= sp;  .-----.     

     \ VoIP  /&n= bsp;   | NAT46 |        | = ;       \ /     &nbs= p; \

  &nb= sp;   `-----'     | CLAT  |  &= nbsp; +---+----+    /  IPv6   \  &n= bsp;   .--+--.

           &nbs= p;      |       |&nb= sp;   |  DNS/  |   (  Internet )IPv6/ IP= v6- \

  &n= bsp;            = ;   +-------+    |  DNS64 |   = \         /----/  only  =  \

  =             &nb= sp;            =     +--------+     \   &n= bsp;   /    (      &= nbsp;    )

           &= nbsp;           &nbs= p;            &= nbsp;          `-----' &n= bsp;    \  APP    /

      &nbs= p;             =             &nb= sp;            =             &nb= sp;   \       /

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      `-----'

   <------------------------ IPv4 to IPv6= flow ------------------------>

 

What did not work so far and what had to be added in your draft to make this flow wo= rk?

 <= o:p>

How can IPv= 6-only APP get the IPV4 public address, used by NAT_translator, when sendin= g a packet from IPv6-ony APP to IPv4-only APP? This IPv4 address is the sam= e destination IPv4 address to which IPv4-only APP sends a packet towards IP= v6-only APP ( 192.0.2.2. address in Jen=E2=80=99s example).

<= p class=3DMsoNormal style=3D'margin-left:70.8pt'> 

Thanks,

Dusan.

 

From: v6ops &= lt;v6ops-bounces@ietf.org> On Behalf Of JORDI PALET MARTINEZ
<= b>Sent: Monday, July 8, 2019 5:40 PM
To: IPv6 Operations <= v6ops@ietf.org>
Cc: 6man <6man@ietf.org>
Subject:<= /b> Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64

=

 

I th= ink there are several possible solutions, but the simpler one seems to be t= he dual-stack SIP proxies. Another one is draft-ietf-tram-turnbis, which I = didn=E2=80=99t knew, until today, is already in the IESG for approval this = Thrusday.

Also it can be done with EAM and also = as I mention in a previous email via the optimization for 464XLAT. Just upl= oaded the new version:

 

https://datatracker.ietf.org/doc/draft= -palet-v6ops-464xlat-opt-cdn-caches/?include_text=3D1=

 

<= span style=3D'font-size:12.0pt;color:black'> 

 

 

=  

El 8/7/19 19:01, "v6ops en nombre de David Farmer" = <v6ops-bounces@ietf.org en= nombre de farmer@umn.edu> escribi= =C3=B3:

 

 

 

On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote:

> -----Ori= ginal Message-----
> From: Manfredi (US), Albert E <albert.e.manfredi@boein= g.com>
>
> -----Original Message-----
> From: ipv= 6 <ipv6-bounc= es@ietf.org> On Behalf Of Mudric, Dusan (Dusan)
>
> >= ; - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and vic= e
> versa?
>
> IPv6 to IPv4 should be straightforward, b= ecause it's a one-to-one
> relationship. The other way around would n= ormally not work,
[Dusan] There is no solution for IPv4only client to r= each IPv6only client?

 

I mostly say, so what! It is an unfo= rtunate reality of today's Internet, because of NAT44 and/or stateful firew= all default deny inbound policy, many times clients can't speak to other cl= ients, be they IPv4 only, IPv6 only, or even dual stack. Sometimes firewall= traversal technologies can work around this, also depending on the firewal= l traversal solution used sometimes IPv4 only and IPv6 only clients will be= able to talk to each other.  My guess is that IPv4 only to IPv6 only = firewall traversal would be less effective than NAT44 client to NAT44 clien= t firewall traversal, but it is should still be possible in some cases.&nbs= p;

 

> but everyone
> has = been accustomed to that with IPv4 NAPT already.
[Dusan] How IPv4 only u= sers (e.g. Avaya IPv4 only phones) can be accustomed not to be able to call= IPv6only users (like Apple IPv6 only phones)?

<= div>

 

They may not= be able to talk peer to peer. However, through a dual-stack SIP or other p= roxies/session border controller, they could probably complete a call. = ;

 

>The client behind the
> NAPT initiates.
&g= t;
> > Is DNS64 server returning IPv4ony client address to IPv6on= ly client, using
> the A RR?
>
> The DNS synthesizes the= IPv6 address, which has the IPv4 address
> embedded in it.
> <= br>> > - How can IPv4only client get the address of IPv6only client (= or, it is
> impossible for IPv4only client to get IPv6 address of IPv= 6only client)?
>
> That's clearly more difficult, which is why= the normal course of action is for
> the IPv6 client to initiate the= session..
[Dusan] What if IPv4only client needs to initiate the session= to IPv6only client? What is the solution for that use case?

=

 =

Many firewall traversal solutions should work in this case, but IPv4 only= client to client isn't guaranteed to work in all cases either. <= /o:p>

&nbs= p;

>
> >= ; - Do these IPv4 and IPv6 client addresses need to be pre-configured on th= e
> translator and/or DNS64?
>
> For IPv4 to IPv6, if yo= u must allow the IPv4 client to initiate the session, you'd
> have to= have preconfigure something.
[Dusan] Where and how is this configuratio= n done?

>
> Bert

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


 

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer     =          Email:farmer@umn.edu
Networking & Telecommun= ication Services
Office of Information Technology
University of Minne= sota  
2218 University Ave SE        Phon= e: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-995= 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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


**********************************************
IPv4 is ove= r
Are you ready for the new Internet ?
http://www.theipv6company.com<= /a>
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-exp= licilty authorized disclosure, copying, distribution or use of the contents= of this information, even if partially, including attached files, is stric= tly prohibited and will be considered a criminal offense. If you are not th= e intended recipient be aware that any disclosure, copying, distribution or= use of the contents of this information, even if partially, including atta= ched 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.

_______________________________________________ v6ops mailing li= st v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


**********************************************
= IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6c= ompany.com
The IPv6 Company

This electronic message contains info= rmation which may be privileged or confidential. The information is intende= d to be for the exclusive use of the individual(s) named above and further = non-explicilty authorized disclosure, copying, distribution or use of the c= ontents of this information, even if partially, including attached files, i= s strictly prohibited and will be considered a criminal offense. If you are= not the intended recipient be aware that any disclosure, copying, distribu= tion or use of the contents of this information, even if partially, includi= ng attached files, is strictly prohibited, will be considered a criminal of= fense, so you must reply to the original sender to inform about this commun= ication and delete it.

---------------------------------------------= ----------------------- 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 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.

--B_3645557679_564410298-- From nobody Tue Jul 9 16:28:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A2012030D; Tue, 9 Jul 2019 16:27:48 -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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 meuCYNKBkjm8; Tue, 9 Jul 2019 16:27:44 -0700 (PDT) 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 553CE120233; Tue, 9 Jul 2019 16:27:41 -0700 (PDT) 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 911EB3AB002; Tue, 9 Jul 2019 23:27:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7A8F2160048; Tue, 9 Jul 2019 23:27:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 34846160079; Tue, 9 Jul 2019 23:27:40 +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 kuRFzLfvEECR; Tue, 9 Jul 2019 23:27:40 +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 8FF5E160048; Tue, 9 Jul 2019 23:27:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: Date: Wed, 10 Jul 2019 09:27:35 +1000 Cc: "Mudric, Dusan (Dusan)" , IPv6 Operations , 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <0B1E408F-E7E9-4D53-B634-ADB1425B3BD8@isc.org> References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 23:27:52 -0000 And the answer to this =E2=80=9Cproblem=E2=80=9D is stop buying = IPv4-only garbage and deploy IPv6. Go talk to your legislators about banning the sale of IPv4-only = equipment. This is where this should be addressed. Not in the IETF. = IPv6 aware products don=E2=80=99t cost more to produce. Having lived through a metrification process, banning the sale of = imperial only equipment really helped. It was illegal to sell new cars = without kph on the speedometer. It was illegal to sell new rulers and = tape measures which where imperial only. It was illegal to sell new = scales that where imperial only. All packaging had to be labeled in = metric units. Sometimes governments need to step in and ban products = for the greater good. > On 10 Jul 2019, at 6:24 am, JORDI PALET MARTINEZ = wrote: >=20 > Hi Dusan, > =20 > The problem is that the IPv6-only =E2=80=9Cremote server=E2=80=9D = don=E2=80=99t have IPv4 connectivity. Also, it doesn=E2=80=99t have an = IPv4 address. Let=E2=80=99s suppose this is a streaming server. > =20 > The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is = an IPv4-only SmartTV), is connected to a CLAT (this is in the CPE, and = the CPE is connected via IPv6-only) to the service provider. > =20 > The optimization that we are suggesting is using EAM (explicit = mapping) to avoid the IPv4 flow from the smartTV to be converted back to = IPv4, because the CLAT already converted it to IPv6. > =20 > If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming = server, the CLAT will create an EAMT, so because it believes the = streaming service is reachable with IPv4 (which is not), but the = =E2=80=9Coptimized CLAT=E2=80=9D will then use the AAAA. > =20 > So, the flow is: > IPv4 from the smartTV to the CLAT > IPv6 from the CLAT to the streaming service > =20 > In normal conditions, if the streaming service is really dual-stack = and we don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D = 464XLAT protocol), it will be: > =20 > IPv4 from the smartTV to the CLAT > IPv6 from the CLAT to the NAT64 > IPv4 from the NAT64 to the streaming service > =20 > If the streaming service is IPv6 only, with the actual 464XLAT = protocol, this connectivity is not possible. > =20 > You see the point? > =20 > Please take a look at the document, I think is well described, = otherwise provide suggestions about what you believe is not clear enough = and we will make sure to improve the text and drawings! > =20 > By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80=9D,= which I think is the best solution. > =20 > Regards, > Jordi >=20 > @jordipalet >=20 > =20 > =20 > =20 > El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" = escribi=C3=B3: > =20 > Hi Jordi, > =20 > Are you saying your draft =E2=80=9C464XLAT Optimization=E2=80=9D will = provide IPv4only app to IPv6only app communication like this? > =20 > =20 > +-------+ .-----. =20 > | IPv6 | / \ =20 > .-----. | CE | / IPv6- \ .-----. =20 > / IPv4- \ | or +--( only )---( NAT64 ) > / only \ | UE | \ Access /\ `-----' =20 > ( SmartTV )--+ | \ / \ =20 > \ STB / | with | `--+--' \ .-----. =20 > \ VoIP / | NAT46 | | \ / \ > `-----' | CLAT | +---+----+ / IPv6 \ .--+--. > | | | DNS/ | ( Internet )IPv6/ IPv6- \ > +-------+ | DNS64 | \ /----/ only = \ > +--------+ \ / ( = ) > `-----' \ APP = / > \ / > `-----' > <------------------------ IPv4 to IPv6 flow = ------------------------> > =20 > What did not work so far and what had to be added in your draft to = make this flow work? > =20 > How can IPv6-only APP get the IPV4 public address, used by = NAT_translator, when sending a packet from IPv6-ony APP to IPv4-only = APP? This IPv4 address is the same destination IPv4 address to which = IPv4-only APP sends a packet towards IPv6-only APP ( 192.0.2.2. address = in Jen=E2=80=99s example). > =20 > Thanks, > Dusan. > =20 > From: v6ops On Behalf Of JORDI PALET MARTINEZ > Sent: Monday, July 8, 2019 5:40 PM > To: IPv6 Operations > Cc: 6man <6man@ietf.org> > Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 > =20 > I think there are several possible solutions, but the simpler one = seems to be the dual-stack SIP proxies. Another one is = draft-ietf-tram-turnbis, which I didn=E2=80=99t knew, until today, is = already in the IESG for approval this Thrusday. >=20 > Also it can be done with EAM and also as I mention in a previous email = via the optimization for 464XLAT. Just uploaded the new version: >=20 > =20 > = https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/= ?include_text=3D1 > =20 >=20 > =20 >=20 > =20 >=20 > =20 > =20 > El 8/7/19 19:01, "v6ops en nombre de David Farmer" = escribi=C3=B3: > =20 > =20 > =20 > On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) = wrote: >> > -----Original Message----- >> > From: Manfredi (US), Albert E >> >=20 >> > -----Original Message----- >> > From: ipv6 On Behalf Of Mudric, Dusan = (Dusan) >> >=20 >> > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, = and vice >> > versa? >> >=20 >> > IPv6 to IPv4 should be straightforward, because it's a one-to-one >> > relationship. The other way around would normally not work,=20 >> [Dusan] There is no solution for IPv4only client to reach IPv6only = client?=20 > =20 > I mostly say, so what! It is an unfortunate reality of today's = Internet, because of NAT44 and/or stateful firewall default deny inbound = policy, many times clients can't speak to other clients, be they IPv4 = only, IPv6 only, or even dual stack. Sometimes firewall traversal = technologies can work around this, also depending on the firewall = traversal solution used sometimes IPv4 only and IPv6 only clients will = be able to talk to each other. My guess is that IPv4 only to IPv6 only = firewall traversal would be less effective than NAT44 client to NAT44 = client firewall traversal, but it is should still be possible in some = cases.=20 > =20 >> > but everyone >> > has been accustomed to that with IPv4 NAPT already.=20 >> [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be = accustomed not to be able to call IPv6only users (like Apple IPv6 only = phones)? > =20 > They may not be able to talk peer to peer. However, through a = dual-stack SIP or other proxies/session border controller, they could = probably complete a call.=20 > =20 >> >The client behind the >> > NAPT initiates. >> >=20 >> > > Is DNS64 server returning IPv4ony client address to IPv6only = client, using >> > the A RR? >> >=20 >> > The DNS synthesizes the IPv6 address, which has the IPv4 address >> > embedded in it. >> >=20 >> > > - How can IPv4only client get the address of IPv6only client (or, = it is >> > impossible for IPv4only client to get IPv6 address of IPv6only = client)? >> >=20 >> > That's clearly more difficult, which is why the normal course of = action is for >> > the IPv6 client to initiate the session.. >> [Dusan] What if IPv4only client needs to initiate the session to = IPv6only client? What is the solution for that use case? > =20 > Many firewall traversal solutions should work in this case, but IPv4 = only client to client isn't guaranteed to work in all cases either.=20 > =20 >> >=20 >> > > - Do these IPv4 and IPv6 client addresses need to be = pre-configured on the >> > translator and/or DNS64? >> >=20 >> > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the = session, you'd >> > have to have preconfigure something. >> [Dusan] Where and how is this configuration done? >>=20 >> >=20 >> > Bert >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > =20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota =20 > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > _______________________________________________ v6ops mailing list = v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >=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 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. >=20 > _______________________________________________ v6ops mailing list = v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >=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 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. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 9 17:28:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308BB120098; Tue, 9 Jul 2019 17:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 bJ4jKEvE24cK; Tue, 9 Jul 2019 17:28:52 -0700 (PDT) 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 F3B6112008C; Tue, 9 Jul 2019 17:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562718527; x=1563323327; 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=w6fNauHgPBFGQdIKcbQdcFCze1rrvCAZJUQzzaLNuok=; b=VflLBz6wOTY7v SKHZrtBsoeMmfOUM+qUHCcEcMsZROliEDZBoHgOxS7q5YCYT/rskrUfsB19Z65/9 +rrw8f88hJ0A3f/WaJqMnuvrEWkF+3PiujG8GUDC05KXTaZxdptLpMRaSPBjjOaO rBkh9lCvyCG/ffLdXUedvt5UMPZvOs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 10 Jul 2019 02:28:47 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 10 Jul 2019 02:28:46 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006320869.msg; Wed, 10 Jul 2019 02:28:45 +0200 X-MDRemoteIP: 2001:470:1f09:495:e078:75ed:8505:ff6 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Wed, 10 Jul 2019 02:28:45 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1094617358=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Wed, 10 Jul 2019 02:28:42 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations CC: 6man <6man@ietf.org> Message-ID: <0EBE2E86-4FC7-446E-984D-1A91C91A899D@consulintel.es> Thread-Topic: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> <0B1E408F-E7E9-4D53-B634-ADB1425B3BD8@isc.org> In-Reply-To: <0B1E408F-E7E9-4D53-B634-ADB1425B3BD8@isc.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 00:28:55 -0000 HI Mark, I will agree with that, and I've actually recommended it to several governm= ents: "ban imports and manufacturing of non-IPv6-ready devices in 12 months= , ban sales of older stocks 6 months after that". Same we have done with DT= V, for example. It is a basic consumer protection measure. However, nobody is going to pay for replacement of existing IPv4-only equip= ment and apps in homes and enterprises, so we still need to provide solutio= ns for those. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 10/7/19 1:27, "Mark Andrews" escribi=C3=B3: And the answer to this =E2=80=9Cproblem=E2=80=9D is stop buying IPv4-on= ly garbage and deploy IPv6. =20 Go talk to your legislators about banning the sale of IPv4-only equipme= nt. This is where this should be addressed. Not in the IETF. IPv6 aware = products don=E2=80=99t cost more to produce. =20 Having lived through a metrification process, banning the sale of imper= ial only equipment really helped. It was illegal to sell new cars without = kph on the speedometer. It was illegal to sell new rulers and tape measure= s which where imperial only. It was illegal to sell new scales that where = imperial only. All packaging had to be labeled in metric units. Sometimes= governments need to step in and ban products for the greater good. =20 > On 10 Jul 2019, at 6:24 am, JORDI PALET MARTINEZ wrote: >=20 > Hi Dusan, > =20 > The problem is that the IPv6-only =E2=80=9Cremote server=E2=80=9D don= =E2=80=99t have IPv4 connectivity. Also, it doesn=E2=80=99t have an IPv4 ad= dress. Let=E2=80=99s suppose this is a streaming server. > =20 > The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is = an IPv4-only SmartTV), is connected to a CLAT (this is in the CPE, and the = CPE is connected via IPv6-only) to the service provider. > =20 > The optimization that we are suggesting is using EAM (explicit mappin= g) to avoid the IPv4 flow from the smartTV to be converted back to IPv4, be= cause the CLAT already converted it to IPv6. > =20 > If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming serve= r, the CLAT will create an EAMT, so because it believes the streaming servi= ce is reachable with IPv4 (which is not), but the =E2=80=9Coptimized CLAT= =E2=80=9D will then use the AAAA. > =20 > So, the flow is: > IPv4 from the smartTV to the CLAT > IPv6 from the CLAT to the streaming service > =20 > In normal conditions, if the streaming service is really dual-stack a= nd we don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D 464XLAT= protocol), it will be: > =20 > IPv4 from the smartTV to the CLAT > IPv6 from the CLAT to the NAT64 > IPv4 from the NAT64 to the streaming service > =20 > If the streaming service is IPv6 only, with the actual 464XLAT protoc= ol, this connectivity is not possible. > =20 > You see the point? > =20 > Please take a look at the document, I think is well described, otherw= ise provide suggestions about what you believe is not clear enough and we w= ill make sure to improve the text and drawings! > =20 > By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80= =9D, which I think is the best solution. > =20 > Regards, > Jordi >=20 > @jordipalet >=20 > =20 > =20 > =20 > El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: > =20 > Hi Jordi, > =20 > Are you saying your draft =E2=80=9C464XLAT Optimization=E2=80=9D wil= l provide IPv4only app to IPv6only app communication like this? > =20 > =20 > +-------+ .-----. =20 > | IPv6 | / \ =20 > .-----. | CE | / IPv6- \ .-----. =20 > / IPv4- \ | or +--( only )---( NAT64 ) > / only \ | UE | \ Access /\ `-----' =20 > ( SmartTV )--+ | \ / \ =20 > \ STB / | with | `--+--' \ .-----. =20 > \ VoIP / | NAT46 | | \ / \ > `-----' | CLAT | +---+----+ / IPv6 \ .--+--. > | | | DNS/ | ( Internet )IPv6/ IPv6- = \ > +-------+ | DNS64 | \ /----/ only = \ > +--------+ \ / ( = ) > `-----' \ APP = / > \ = / > `-----' > <------------------------ IPv4 to IPv6 flow ----------------------= --> > =20 > What did not work so far and what had to be added in your draft to ma= ke this flow work? > =20 > How can IPv6-only APP get the IPV4 public address, used by NAT_transl= ator, when sending a packet from IPv6-ony APP to IPv4-only APP? This IPv4 a= ddress is the same destination IPv4 address to which IPv4-only APP sends a = packet towards IPv6-only APP ( 192.0.2.2. address in Jen=E2=80=99s example)= . > =20 > Thanks, > Dusan. > =20 > From: v6ops On Behalf Of JORDI PALET MARTINE= Z > Sent: Monday, July 8, 2019 5:40 PM > To: IPv6 Operations > Cc: 6man <6man@ietf.org> > Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 > =20 > I think there are several possible solutions, but the simpler one see= ms to be the dual-stack SIP proxies. Another one is draft-ietf-tram-turnbis= , which I didn=E2=80=99t knew, until today, is already in the IESG for appr= oval this Thrusday. >=20 > Also it can be done with EAM and also as I mention in a previous emai= l via the optimization for 464XLAT. Just uploaded the new version: >=20 > =20 > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-ca= ches/?include_text=3D1 > =20 >=20 > =20 >=20 > =20 >=20 > =20 > =20 > El 8/7/19 19:01, "v6ops en nombre de David Farmer" escribi=C3=B3: > =20 > =20 > =20 > On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) wrote: >> > -----Original Message----- >> > From: Manfredi (US), Albert E >> >=20 >> > -----Original Message----- >> > From: ipv6 On Behalf Of Mudric, Dusan (Dus= an) >> >=20 >> > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client= , and vice >> > versa? >> >=20 >> > IPv6 to IPv4 should be straightforward, because it's a one-to-one >> > relationship. The other way around would normally not work,=20 >> [Dusan] There is no solution for IPv4only client to reach IPv6only c= lient?=20 > =20 > I mostly say, so what! It is an unfortunate reality of today's Intern= et, because of NAT44 and/or stateful firewall default deny inbound policy, = many times clients can't speak to other clients, be they IPv4 only, IPv6 on= ly, or even dual stack. Sometimes firewall traversal technologies can work = around this, also depending on the firewall traversal solution used sometim= es IPv4 only and IPv6 only clients will be able to talk to each other. My = guess is that IPv4 only to IPv6 only firewall traversal would be less effec= tive than NAT44 client to NAT44 client firewall traversal, but it is should= still be possible in some cases.=20 > =20 >> > but everyone >> > has been accustomed to that with IPv4 NAPT already.=20 >> [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be acc= ustomed not to be able to call IPv6only users (like Apple IPv6 only phones)= ? > =20 > They may not be able to talk peer to peer. However, through a dual-st= ack SIP or other proxies/session border controller, they could probably com= plete a call.=20 > =20 >> >The client behind the >> > NAPT initiates. >> >=20 >> > > Is DNS64 server returning IPv4ony client address to IPv6only cli= ent, using >> > the A RR? >> >=20 >> > The DNS synthesizes the IPv6 address, which has the IPv4 address >> > embedded in it. >> >=20 >> > > - How can IPv4only client get the address of IPv6only client (or= , it is >> > impossible for IPv4only client to get IPv6 address of IPv6only cli= ent)? >> >=20 >> > That's clearly more difficult, which is why the normal course of a= ction is for >> > the IPv6 client to initiate the session.. >> [Dusan] What if IPv4only client needs to initiate the session to IPv= 6only client? What is the solution for that use case? > =20 > Many firewall traversal solutions should work in this case, but IPv4 = only client to client isn't guaranteed to work in all cases either.=20 > =20 >> >=20 >> > > - Do these IPv4 and IPv6 client addresses need to be pre-configu= red on the >> > translator and/or DNS64? >> >=20 >> > For IPv4 to IPv6, if you must allow the IPv4 client to initiate th= e session, you'd >> > have to have preconfigure something. >> [Dusan] Where and how is this configuration done? >>=20 >> >=20 >> > Bert >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > =20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota =20 > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > _______________________________________________ v6ops mailing list v6= ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >=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 confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 > _______________________________________________ v6ops mailing list v6= ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >=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 confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =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 Jul 9 18:53:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BF1120048; Tue, 9 Jul 2019 18:53:23 -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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 gHR792x3Qyme; Tue, 9 Jul 2019 18:53:19 -0700 (PDT) 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 3BDF7120090; Tue, 9 Jul 2019 18:53:19 -0700 (PDT) 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 CFCFE3AB007; Wed, 10 Jul 2019 01:53:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BC5C316006D; Wed, 10 Jul 2019 01:53:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A8A16160060; Wed, 10 Jul 2019 01:53:18 +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 T-gtsFH5EUAQ; Wed, 10 Jul 2019 01:53:18 +0000 (UTC) Received: from [172.20.10.5] (unknown [120.17.138.250]) by zmx1.isc.org (Postfix) with ESMTPSA id 0A2C4160031; Wed, 10 Jul 2019 01:53:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <0EBE2E86-4FC7-446E-984D-1A91C91A899D@consulintel.es> Date: Wed, 10 Jul 2019 11:52:54 +1000 Cc: IPv6 Operations , 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> <0B1E408F-E7E9-4D53-B634-ADB1425B3BD8@isc.org> <0EBE2E86-4FC7-446E-984D-1A91C91A899D@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 01:53:23 -0000 Do we really need to provide a solution? The manufactures of the = devices can update their firmware. What internet connected device in = the house isn=E2=80=99t upgradable? All the games consoles are. = Printers are. TV=E2=80=99s are. Fridges are. The list goes on. Again this is where governments can force manufactures to do the right = thing by their existing customers. Mark > On 10 Jul 2019, at 10:28 am, JORDI PALET MARTINEZ = wrote: >=20 > HI Mark, >=20 > I will agree with that, and I've actually recommended it to several = governments: "ban imports and manufacturing of non-IPv6-ready devices in = 12 months, ban sales of older stocks 6 months after that". Same we have = done with DTV, for example. It is a basic consumer protection measure. >=20 > However, nobody is going to pay for replacement of existing IPv4-only = equipment and apps in homes and enterprises, so we still need to provide = solutions for those. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 > =EF=BB=BFEl 10/7/19 1:27, "Mark Andrews" escribi=C3=B3: >=20 > And the answer to this =E2=80=9Cproblem=E2=80=9D is stop buying = IPv4-only garbage and deploy IPv6. >=20 > Go talk to your legislators about banning the sale of IPv4-only = equipment. This is where this should be addressed. Not in the IETF. = IPv6 aware products don=E2=80=99t cost more to produce. >=20 > Having lived through a metrification process, banning the sale of = imperial only equipment really helped. It was illegal to sell new cars = without kph on the speedometer. It was illegal to sell new rulers and = tape measures which where imperial only. It was illegal to sell new = scales that where imperial only. All packaging had to be labeled in = metric units. Sometimes governments need to step in and ban products = for the greater good. >=20 >> On 10 Jul 2019, at 6:24 am, JORDI PALET MARTINEZ = wrote: >>=20 >> Hi Dusan, >>=20 >> The problem is that the IPv6-only =E2=80=9Cremote server=E2=80=9D = don=E2=80=99t have IPv4 connectivity. Also, it doesn=E2=80=99t have an = IPv4 address. Let=E2=80=99s suppose this is a streaming server. >>=20 >> The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is = an IPv4-only SmartTV), is connected to a CLAT (this is in the CPE, and = the CPE is connected via IPv6-only) to the service provider. >>=20 >> The optimization that we are suggesting is using EAM (explicit = mapping) to avoid the IPv4 flow from the smartTV to be converted back to = IPv4, because the CLAT already converted it to IPv6. >>=20 >> If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming = server, the CLAT will create an EAMT, so because it believes the = streaming service is reachable with IPv4 (which is not), but the = =E2=80=9Coptimized CLAT=E2=80=9D will then use the AAAA. >>=20 >> So, the flow is: >> IPv4 from the smartTV to the CLAT >> IPv6 from the CLAT to the streaming service >>=20 >> In normal conditions, if the streaming service is really dual-stack = and we don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D = 464XLAT protocol), it will be: >>=20 >> IPv4 from the smartTV to the CLAT >> IPv6 from the CLAT to the NAT64 >> IPv4 from the NAT64 to the streaming service >>=20 >> If the streaming service is IPv6 only, with the actual 464XLAT = protocol, this connectivity is not possible. >>=20 >> You see the point? >>=20 >> Please take a look at the document, I think is well described, = otherwise provide suggestions about what you believe is not clear enough = and we will make sure to improve the text and drawings! >>=20 >> By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80=9D= , which I think is the best solution. >>=20 >> Regards, >> Jordi >>=20 >> @jordipalet >>=20 >>=20 >>=20 >>=20 >> El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" = escribi=C3=B3: >>=20 >> Hi Jordi, >>=20 >> Are you saying your draft =E2=80=9C464XLAT Optimization=E2=80=9D = will provide IPv4only app to IPv6only app communication like this? >>=20 >>=20 >> +-------+ .-----. =20 >> | IPv6 | / \ =20 >> .-----. | CE | / IPv6- \ .-----. =20 >> / IPv4- \ | or +--( only )---( NAT64 ) >> / only \ | UE | \ Access /\ `-----' =20 >> ( SmartTV )--+ | \ / \ =20 >> \ STB / | with | `--+--' \ .-----. =20 >> \ VoIP / | NAT46 | | \ / \ >> `-----' | CLAT | +---+----+ / IPv6 \ .--+--. >> | | | DNS/ | ( Internet )IPv6/ IPv6- \ >> +-------+ | DNS64 | \ /----/ only = \ >> +--------+ \ / ( = ) >> `-----' \ APP = / >> \ / >> `-----' >> <------------------------ IPv4 to IPv6 flow = ------------------------> >>=20 >> What did not work so far and what had to be added in your draft to = make this flow work? >>=20 >> How can IPv6-only APP get the IPV4 public address, used by = NAT_translator, when sending a packet from IPv6-ony APP to IPv4-only = APP? This IPv4 address is the same destination IPv4 address to which = IPv4-only APP sends a packet towards IPv6-only APP ( 192.0.2.2. address = in Jen=E2=80=99s example). >>=20 >> Thanks, >> Dusan. >>=20 >> From: v6ops On Behalf Of JORDI PALET = MARTINEZ >> Sent: Monday, July 8, 2019 5:40 PM >> To: IPv6 Operations >> Cc: 6man <6man@ietf.org> >> Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 >>=20 >> I think there are several possible solutions, but the simpler one = seems to be the dual-stack SIP proxies. Another one is = draft-ietf-tram-turnbis, which I didn=E2=80=99t knew, until today, is = already in the IESG for approval this Thrusday. >>=20 >> Also it can be done with EAM and also as I mention in a previous = email via the optimization for 464XLAT. Just uploaded the new version: >>=20 >>=20 >> = https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/= ?include_text=3D1 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> El 8/7/19 19:01, "v6ops en nombre de David Farmer" = escribi=C3=B3: >>=20 >>=20 >>=20 >> On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) = wrote: >>>> -----Original Message----- >>>> From: Manfredi (US), Albert E >>>>=20 >>>> -----Original Message----- >>>> From: ipv6 On Behalf Of Mudric, Dusan = (Dusan) >>>>=20 >>>>> - How can DNS64 tell IPv6 only client the IP of IPv4 only client, = and vice >>>> versa? >>>>=20 >>>> IPv6 to IPv4 should be straightforward, because it's a one-to-one >>>> relationship. The other way around would normally not work,=20 >>> [Dusan] There is no solution for IPv4only client to reach IPv6only = client?=20 >>=20 >> I mostly say, so what! It is an unfortunate reality of today's = Internet, because of NAT44 and/or stateful firewall default deny inbound = policy, many times clients can't speak to other clients, be they IPv4 = only, IPv6 only, or even dual stack. Sometimes firewall traversal = technologies can work around this, also depending on the firewall = traversal solution used sometimes IPv4 only and IPv6 only clients will = be able to talk to each other. My guess is that IPv4 only to IPv6 only = firewall traversal would be less effective than NAT44 client to NAT44 = client firewall traversal, but it is should still be possible in some = cases.=20 >>=20 >>>> but everyone >>>> has been accustomed to that with IPv4 NAPT already.=20 >>> [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be = accustomed not to be able to call IPv6only users (like Apple IPv6 only = phones)? >>=20 >> They may not be able to talk peer to peer. However, through a = dual-stack SIP or other proxies/session border controller, they could = probably complete a call.=20 >>=20 >>>> The client behind the >>>> NAPT initiates. >>>>=20 >>>>> Is DNS64 server returning IPv4ony client address to IPv6only = client, using >>>> the A RR? >>>>=20 >>>> The DNS synthesizes the IPv6 address, which has the IPv4 address >>>> embedded in it. >>>>=20 >>>>> - How can IPv4only client get the address of IPv6only client (or, = it is >>>> impossible for IPv4only client to get IPv6 address of IPv6only = client)? >>>>=20 >>>> That's clearly more difficult, which is why the normal course of = action is for >>>> the IPv6 client to initiate the session.. >>> [Dusan] What if IPv4only client needs to initiate the session to = IPv6only client? What is the solution for that use case? >>=20 >> Many firewall traversal solutions should work in this case, but IPv4 = only client to client isn't guaranteed to work in all cases either.=20 >>=20 >>>>=20 >>>>> - Do these IPv4 and IPv6 client addresses need to be = pre-configured on the >>>> translator and/or DNS64? >>>>=20 >>>> For IPv4 to IPv6, if you must allow the IPv4 client to initiate the = session, you'd >>>> have to have preconfigure something. >>> [Dusan] Where and how is this configuration done? >>>=20 >>>>=20 >>>> Bert >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> --=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> David Farmer Email:farmer@umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota =20 >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >> _______________________________________________ v6ops mailing list = v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >>=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 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. >>=20 >> _______________________________________________ v6ops mailing list = v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >>=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 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. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 >=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 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. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 9 23:43:55 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B551120103; Tue, 9 Jul 2019 23:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 MaYGNnvzJaS0; Tue, 9 Jul 2019 23:43:50 -0700 (PDT) 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 B066F120100; Tue, 9 Jul 2019 23:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562741026; x=1563345826; 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=XAtEKQ8XX7zUPZmBijn0UFrE44tMAKnXU+e32f84NRo=; b=b7YKfMvvbj611 J5d1Q8BNLFe8RaRiArHRbUQN2yp4sSHDSpVxJY2aj0Bx3CpBkdwqkVvsU/5LrfZH ymTkbwpcbf9oxtEZhPtMzOBqiRvpyLWYXrhgJZzG2XM+N2CfBX+s88ruxCB3PsfG iqEhTXnzHUBVa1NB7zQuC2JUuU0+pE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 10 Jul 2019 08:43:46 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 10 Jul 2019 08:43:45 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006321080.msg; Wed, 10 Jul 2019 08:43:44 +0200 X-MDRemoteIP: 2001:470:1f09:495:ce2:d39:4c86:dc9 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 10 Jul 2019 08:43:44 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1094617358=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Wed, 10 Jul 2019 08:43:41 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations CC: 6man <6man@ietf.org> Message-ID: Thread-Topic: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> <0B1E408F-E7E9-4D53-B634-ADB1425B3BD8@isc.org> <0EBE2E86-4FC7-446E-984D-1A91C91A899D@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 06:43:54 -0000 We could also suggest governments to apply that law: "your 10 years old dev= ice must be updated or you will get a fine". Do you think that's realistic?= How the Spanish government apply a fine to a Chinese company? How about de= vices that were NOT designed to have any kind of firmware update? May vendors or app developers doesn't exist. How you resolve the problem fo= r those? Or governments should pay the renewal of all those devices and app= s? Really, I don't think is that easy/feasible! Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 10/7/19 3:54, "v6ops en nombre de Mark Andrews" escribi=C3=B3: Do we really need to provide a solution? The manufactures of the devic= es can update their firmware. What internet connected device in the house = isn=E2=80=99t upgradable? All the games consoles are. Printers are. TV= =E2=80=99s are. Fridges are. The list goes on. =20 Again this is where governments can force manufactures to do the right = thing by their existing customers. =20 Mark =20 > On 10 Jul 2019, at 10:28 am, JORDI PALET MARTINEZ wrote: >=20 > HI Mark, >=20 > I will agree with that, and I've actually recommended it to several g= overnments: "ban imports and manufacturing of non-IPv6-ready devices in 12 = months, ban sales of older stocks 6 months after that". Same we have done w= ith DTV, for example. It is a basic consumer protection measure. >=20 > However, nobody is going to pay for replacement of existing IPv4-only= equipment and apps in homes and enterprises, so we still need to provide s= olutions for those. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 > =EF=BB=BFEl 10/7/19 1:27, "Mark Andrews" escribi=C3= =B3: >=20 > And the answer to this =E2=80=9Cproblem=E2=80=9D is stop buying IP= v4-only garbage and deploy IPv6. >=20 > Go talk to your legislators about banning the sale of IPv4-only eq= uipment. This is where this should be addressed. Not in the IETF. IPv6 a= ware products don=E2=80=99t cost more to produce. >=20 > Having lived through a metrification process, banning the sale of = imperial only equipment really helped. It was illegal to sell new cars with= out kph on the speedometer. It was illegal to sell new rulers and tape mea= sures which where imperial only. It was illegal to sell new scales that wh= ere imperial only. All packaging had to be labeled in metric units. Somet= imes governments need to step in and ban products for the greater good. >=20 >> On 10 Jul 2019, at 6:24 am, JORDI PALET MARTINEZ wrote: >>=20 >> Hi Dusan, >>=20 >> The problem is that the IPv6-only =E2=80=9Cremote server=E2=80=9D do= n=E2=80=99t have IPv4 connectivity. Also, it doesn=E2=80=99t have an IPv4 a= ddress. Let=E2=80=99s suppose this is a streaming server. >>=20 >> The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is= an IPv4-only SmartTV), is connected to a CLAT (this is in the CPE, and the= CPE is connected via IPv6-only) to the service provider. >>=20 >> The optimization that we are suggesting is using EAM (explicit mappi= ng) to avoid the IPv4 flow from the smartTV to be converted back to IPv4, b= ecause the CLAT already converted it to IPv6. >>=20 >> If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming serv= er, the CLAT will create an EAMT, so because it believes the streaming serv= ice is reachable with IPv4 (which is not), but the =E2=80=9Coptimized CLAT= =E2=80=9D will then use the AAAA. >>=20 >> So, the flow is: >> IPv4 from the smartTV to the CLAT >> IPv6 from the CLAT to the streaming service >>=20 >> In normal conditions, if the streaming service is really dual-stack = and we don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D 464XLA= T protocol), it will be: >>=20 >> IPv4 from the smartTV to the CLAT >> IPv6 from the CLAT to the NAT64 >> IPv4 from the NAT64 to the streaming service >>=20 >> If the streaming service is IPv6 only, with the actual 464XLAT proto= col, this connectivity is not possible. >>=20 >> You see the point? >>=20 >> Please take a look at the document, I think is well described, other= wise provide suggestions about what you believe is not clear enough and we = will make sure to improve the text and drawings! >>=20 >> By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80= =9D, which I think is the best solution. >>=20 >> Regards, >> Jordi >>=20 >> @jordipalet >>=20 >>=20 >>=20 >>=20 >> El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: >>=20 >> Hi Jordi, >>=20 >> Are you saying your draft =E2=80=9C464XLAT Optimization=E2=80=9D wi= ll provide IPv4only app to IPv6only app communication like this? >>=20 >>=20 >> +-------+ .-----. =20 >> | IPv6 | / \ =20 >> .-----. | CE | / IPv6- \ .-----. =20 >> / IPv4- \ | or +--( only )---( NAT64 ) >> / only \ | UE | \ Access /\ `-----' =20 >> ( SmartTV )--+ | \ / \ =20 >> \ STB / | with | `--+--' \ .-----. =20 >> \ VoIP / | NAT46 | | \ / \ >> `-----' | CLAT | +---+----+ / IPv6 \ .--+--. >> | | | DNS/ | ( Internet )IPv6/ IPv6- = \ >> +-------+ | DNS64 | \ /----/ only = \ >> +--------+ \ / ( = ) >> `-----' \ APP = / >> \ = / >> `-----' >> <------------------------ IPv4 to IPv6 flow ----------------------= --> >>=20 >> What did not work so far and what had to be added in your draft to m= ake this flow work? >>=20 >> How can IPv6-only APP get the IPV4 public address, used by NAT_trans= lator, when sending a packet from IPv6-ony APP to IPv4-only APP? This IPv4 = address is the same destination IPv4 address to which IPv4-only APP sends a= packet towards IPv6-only APP ( 192.0.2.2. address in Jen=E2=80=99s example= ). >>=20 >> Thanks, >> Dusan. >>=20 >> From: v6ops On Behalf Of JORDI PALET MARTIN= EZ >> Sent: Monday, July 8, 2019 5:40 PM >> To: IPv6 Operations >> Cc: 6man <6man@ietf.org> >> Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 >>=20 >> I think there are several possible solutions, but the simpler one se= ems to be the dual-stack SIP proxies. Another one is draft-ietf-tram-turnbi= s, which I didn=E2=80=99t knew, until today, is already in the IESG for app= roval this Thrusday. >>=20 >> Also it can be done with EAM and also as I mention in a previous ema= il via the optimization for 464XLAT. Just uploaded the new version: >>=20 >>=20 >> https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-c= aches/?include_text=3D1 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> El 8/7/19 19:01, "v6ops en nombre de David Farmer" escribi=C3=B3: >>=20 >>=20 >>=20 >> On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) wrote: >>>> -----Original Message----- >>>> From: Manfredi (US), Albert E >>>>=20 >>>> -----Original Message----- >>>> From: ipv6 On Behalf Of Mudric, Dusan (Dus= an) >>>>=20 >>>>> - How can DNS64 tell IPv6 only client the IP of IPv4 only client,= and vice >>>> versa? >>>>=20 >>>> IPv6 to IPv4 should be straightforward, because it's a one-to-one >>>> relationship. The other way around would normally not work,=20 >>> [Dusan] There is no solution for IPv4only client to reach IPv6only = client?=20 >>=20 >> I mostly say, so what! It is an unfortunate reality of today's Inter= net, because of NAT44 and/or stateful firewall default deny inbound policy,= many times clients can't speak to other clients, be they IPv4 only, IPv6 o= nly, or even dual stack. Sometimes firewall traversal technologies can work= around this, also depending on the firewall traversal solution used someti= mes IPv4 only and IPv6 only clients will be able to talk to each other. My= guess is that IPv4 only to IPv6 only firewall traversal would be less effe= ctive than NAT44 client to NAT44 client firewall traversal, but it is shoul= d still be possible in some cases.=20 >>=20 >>>> but everyone >>>> has been accustomed to that with IPv4 NAPT already.=20 >>> [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be ac= customed not to be able to call IPv6only users (like Apple IPv6 only phones= )? >>=20 >> They may not be able to talk peer to peer. However, through a dual-s= tack SIP or other proxies/session border controller, they could probably co= mplete a call.=20 >>=20 >>>> The client behind the >>>> NAPT initiates. >>>>=20 >>>>> Is DNS64 server returning IPv4ony client address to IPv6only clie= nt, using >>>> the A RR? >>>>=20 >>>> The DNS synthesizes the IPv6 address, which has the IPv4 address >>>> embedded in it. >>>>=20 >>>>> - How can IPv4only client get the address of IPv6only client (or,= it is >>>> impossible for IPv4only client to get IPv6 address of IPv6only cli= ent)? >>>>=20 >>>> That's clearly more difficult, which is why the normal course of a= ction is for >>>> the IPv6 client to initiate the session.. >>> [Dusan] What if IPv4only client needs to initiate the session to IP= v6only client? What is the solution for that use case? >>=20 >> Many firewall traversal solutions should work in this case, but IPv4= only client to client isn't guaranteed to work in all cases either.=20 >>=20 >>>>=20 >>>>> - Do these IPv4 and IPv6 client addresses need to be pre-configur= ed on the >>>> translator and/or DNS64? >>>>=20 >>>> For IPv4 to IPv6, if you must allow the IPv4 client to initiate th= e session, you'd >>>> have to have preconfigure something. >>> [Dusan] Where and how is this configuration done? >>>=20 >>>>=20 >>>> Bert >>>=20 >>> -------------------------------------------------------------------= - >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------= - >>=20 >>=20 >> --=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> David Farmer Email:farmer@umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota =20 >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =20 >> _______________________________________________ v6ops mailing list v= 6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >>=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 confidential. The information is intended to be for the exclusive use o= f the individual(s) named above and further non-explicilty authorized discl= osure, copying, distribution or use of the contents of this information, ev= en 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. >>=20 >> _______________________________________________ v6ops mailing list v= 6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >>=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 confidential. The information is intended to be for the exclusive use o= f the individual(s) named above and further non-explicilty authorized discl= osure, copying, distribution or use of the contents of this information, ev= en 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. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 >=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 confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Wed Jul 10 00:11:51 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4858120161; Wed, 10 Jul 2019 00:11:49 -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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 H01s-SZsaqIO; Wed, 10 Jul 2019 00:11:46 -0700 (PDT) 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 E37E212011C; Wed, 10 Jul 2019 00:11:45 -0700 (PDT) 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 B460B3AB008; Wed, 10 Jul 2019 07:11:44 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A592E16006D; Wed, 10 Jul 2019 07:11:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 85DFB160060; Wed, 10 Jul 2019 07:11: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 qsiY4Fopm5o8; Wed, 10 Jul 2019 07:11: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 3B613160044; Wed, 10 Jul 2019 07:11:43 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: Date: Wed, 10 Jul 2019 17:11:40 +1000 Cc: IPv6 Operations , 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <9AA44A80-082B-4192-A482-D642D76B1A8D@isc.org> References: <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <6A99AEFF-02D6-4F24-9484-B72745126D70@consulintel.es> <0B1E408F-E7E9-4D53-B634-ADB1425B3BD8@isc.org> <0EBE2E86-4FC7-446E-984D-1A91C91A899D@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 07:11:50 -0000 > On 10 Jul 2019, at 4:43 pm, JORDI PALET MARTINEZ = wrote: >=20 > We could also suggest governments to apply that law: "your 10 years = old device must be updated or you will get a fine". Do you think that's = realistic? Actually yes. It was clear 10 years ago that IPv4 was dead and IPv6 was = the replacement. The manufacture gambled and lost. Think about the recent GPS epoch. Vendors put out updates for otherwise = eol=E2=80=99d products to avoid fines for shipping non fit for purpose equipment. They all knew or should have = known that a GPS epoch would happen in the life of the product. The same applies to shipping IPv4 only equipment. > How the Spanish government apply a fine to a Chinese company? How = about devices that were NOT designed to have any kind of firmware = update? I you are in Australia the seller is the one that is primarily = responsible. How they deal with their supply chain is up to them.=20 Devices that where not designed to have a firmware update you throw in = the bin. That said, for most of them, the machines they want to contact = have IPv4 addresses. > May vendors or app developers doesn't exist. How you resolve the = problem for those? Or governments should pay the renewal of all those = devices and apps? You throw those in the bin as well.=20 > Really, I don't think is that easy/feasible! >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 > =EF=BB=BFEl 10/7/19 3:54, "v6ops en nombre de Mark Andrews" = escribi=C3=B3: >=20 > Do we really need to provide a solution? The manufactures of the = devices can update their firmware. What internet connected device in = the house isn=E2=80=99t upgradable? All the games consoles are. = Printers are. TV=E2=80=99s are. Fridges are. The list goes on. >=20 > Again this is where governments can force manufactures to do the = right thing by their existing customers. >=20 > Mark >=20 >> On 10 Jul 2019, at 10:28 am, JORDI PALET MARTINEZ = wrote: >>=20 >> HI Mark, >>=20 >> I will agree with that, and I've actually recommended it to several = governments: "ban imports and manufacturing of non-IPv6-ready devices in = 12 months, ban sales of older stocks 6 months after that". Same we have = done with DTV, for example. It is a basic consumer protection measure. >>=20 >> However, nobody is going to pay for replacement of existing IPv4-only = equipment and apps in homes and enterprises, so we still need to provide = solutions for those. >>=20 >> Regards, >> Jordi >> @jordipalet >>=20 >>=20 >>=20 >> =EF=BB=BFEl 10/7/19 1:27, "Mark Andrews" escribi=C3=B3:= >>=20 >> And the answer to this =E2=80=9Cproblem=E2=80=9D is stop buying = IPv4-only garbage and deploy IPv6. >>=20 >> Go talk to your legislators about banning the sale of IPv4-only = equipment. This is where this should be addressed. Not in the IETF. = IPv6 aware products don=E2=80=99t cost more to produce. >>=20 >> Having lived through a metrification process, banning the sale of = imperial only equipment really helped. It was illegal to sell new cars = without kph on the speedometer. It was illegal to sell new rulers and = tape measures which where imperial only. It was illegal to sell new = scales that where imperial only. All packaging had to be labeled in = metric units. Sometimes governments need to step in and ban products = for the greater good. >>=20 >>> On 10 Jul 2019, at 6:24 am, JORDI PALET MARTINEZ = wrote: >>>=20 >>> Hi Dusan, >>>=20 >>> The problem is that the IPv6-only =E2=80=9Cremote server=E2=80=9D = don=E2=80=99t have IPv4 connectivity. Also, it doesn=E2=80=99t have an = IPv4 address. Let=E2=80=99s suppose this is a streaming server. >>>=20 >>> The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is = an IPv4-only SmartTV), is connected to a CLAT (this is in the CPE, and = the CPE is connected via IPv6-only) to the service provider. >>>=20 >>> The optimization that we are suggesting is using EAM (explicit = mapping) to avoid the IPv4 flow from the smartTV to be converted back to = IPv4, because the CLAT already converted it to IPv6. >>>=20 >>> If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming = server, the CLAT will create an EAMT, so because it believes the = streaming service is reachable with IPv4 (which is not), but the = =E2=80=9Coptimized CLAT=E2=80=9D will then use the AAAA. >>>=20 >>> So, the flow is: >>> IPv4 from the smartTV to the CLAT >>> IPv6 from the CLAT to the streaming service >>>=20 >>> In normal conditions, if the streaming service is really dual-stack = and we don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D = 464XLAT protocol), it will be: >>>=20 >>> IPv4 from the smartTV to the CLAT >>> IPv6 from the CLAT to the NAT64 >>> IPv4 from the NAT64 to the streaming service >>>=20 >>> If the streaming service is IPv6 only, with the actual 464XLAT = protocol, this connectivity is not possible. >>>=20 >>> You see the point? >>>=20 >>> Please take a look at the document, I think is well described, = otherwise provide suggestions about what you believe is not clear enough = and we will make sure to improve the text and drawings! >>>=20 >>> By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80=9D= , which I think is the best solution. >>>=20 >>> Regards, >>> Jordi >>>=20 >>> @jordipalet >>>=20 >>>=20 >>>=20 >>>=20 >>> El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" = escribi=C3=B3: >>>=20 >>> Hi Jordi, >>>=20 >>> Are you saying your draft =E2=80=9C464XLAT Optimization=E2=80=9D = will provide IPv4only app to IPv6only app communication like this? >>>=20 >>>=20 >>> +-------+ .-----. =20 >>> | IPv6 | / \ =20 >>> .-----. | CE | / IPv6- \ .-----. =20 >>> / IPv4- \ | or +--( only )---( NAT64 ) >>> / only \ | UE | \ Access /\ `-----' =20 >>> ( SmartTV )--+ | \ / \ =20 >>> \ STB / | with | `--+--' \ .-----. =20 >>> \ VoIP / | NAT46 | | \ / \ >>> `-----' | CLAT | +---+----+ / IPv6 \ .--+--. >>> | | | DNS/ | ( Internet )IPv6/ IPv6- \ >>> +-------+ | DNS64 | \ /----/ only = \ >>> +--------+ \ / ( = ) >>> `-----' \ APP = / >>> \ / >>> `-----' >>> <------------------------ IPv4 to IPv6 flow = ------------------------> >>>=20 >>> What did not work so far and what had to be added in your draft to = make this flow work? >>>=20 >>> How can IPv6-only APP get the IPV4 public address, used by = NAT_translator, when sending a packet from IPv6-ony APP to IPv4-only = APP? This IPv4 address is the same destination IPv4 address to which = IPv4-only APP sends a packet towards IPv6-only APP ( 192.0.2.2. address = in Jen=E2=80=99s example). >>>=20 >>> Thanks, >>> Dusan. >>>=20 >>> From: v6ops On Behalf Of JORDI PALET = MARTINEZ >>> Sent: Monday, July 8, 2019 5:40 PM >>> To: IPv6 Operations >>> Cc: 6man <6man@ietf.org> >>> Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 >>>=20 >>> I think there are several possible solutions, but the simpler one = seems to be the dual-stack SIP proxies. Another one is = draft-ietf-tram-turnbis, which I didn=E2=80=99t knew, until today, is = already in the IESG for approval this Thrusday. >>>=20 >>> Also it can be done with EAM and also as I mention in a previous = email via the optimization for 464XLAT. Just uploaded the new version: >>>=20 >>>=20 >>> = https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/= ?include_text=3D1 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> El 8/7/19 19:01, "v6ops en nombre de David Farmer" = escribi=C3=B3: >>>=20 >>>=20 >>>=20 >>> On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) = wrote: >>>>> -----Original Message----- >>>>> From: Manfredi (US), Albert E >>>>>=20 >>>>> -----Original Message----- >>>>> From: ipv6 On Behalf Of Mudric, Dusan = (Dusan) >>>>>=20 >>>>>> - How can DNS64 tell IPv6 only client the IP of IPv4 only client, = and vice >>>>> versa? >>>>>=20 >>>>> IPv6 to IPv4 should be straightforward, because it's a one-to-one >>>>> relationship. The other way around would normally not work,=20 >>>> [Dusan] There is no solution for IPv4only client to reach IPv6only = client?=20 >>>=20 >>> I mostly say, so what! It is an unfortunate reality of today's = Internet, because of NAT44 and/or stateful firewall default deny inbound = policy, many times clients can't speak to other clients, be they IPv4 = only, IPv6 only, or even dual stack. Sometimes firewall traversal = technologies can work around this, also depending on the firewall = traversal solution used sometimes IPv4 only and IPv6 only clients will = be able to talk to each other. My guess is that IPv4 only to IPv6 only = firewall traversal would be less effective than NAT44 client to NAT44 = client firewall traversal, but it is should still be possible in some = cases.=20 >>>=20 >>>>> but everyone >>>>> has been accustomed to that with IPv4 NAPT already.=20 >>>> [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be = accustomed not to be able to call IPv6only users (like Apple IPv6 only = phones)? >>>=20 >>> They may not be able to talk peer to peer. However, through a = dual-stack SIP or other proxies/session border controller, they could = probably complete a call.=20 >>>=20 >>>>> The client behind the >>>>> NAPT initiates. >>>>>=20 >>>>>> Is DNS64 server returning IPv4ony client address to IPv6only = client, using >>>>> the A RR? >>>>>=20 >>>>> The DNS synthesizes the IPv6 address, which has the IPv4 address >>>>> embedded in it. >>>>>=20 >>>>>> - How can IPv4only client get the address of IPv6only client (or, = it is >>>>> impossible for IPv4only client to get IPv6 address of IPv6only = client)? >>>>>=20 >>>>> That's clearly more difficult, which is why the normal course of = action is for >>>>> the IPv6 client to initiate the session.. >>>> [Dusan] What if IPv4only client needs to initiate the session to = IPv6only client? What is the solution for that use case? >>>=20 >>> Many firewall traversal solutions should work in this case, but IPv4 = only client to client isn't guaranteed to work in all cases either.=20 >>>=20 >>>>>=20 >>>>>> - Do these IPv4 and IPv6 client addresses need to be = pre-configured on the >>>>> translator and/or DNS64? >>>>>=20 >>>>> For IPv4 to IPv6, if you must allow the IPv4 client to initiate = the session, you'd >>>>> have to have preconfigure something. >>>> [Dusan] Where and how is this configuration done? >>>>=20 >>>>>=20 >>>>> Bert >>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>=20 >>>=20 >>> --=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> David Farmer Email:farmer@umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota =20 >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >>> _______________________________________________ v6ops mailing list = v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >>>=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 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. >>>=20 >>> _______________________________________________ v6ops mailing list = v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >>>=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 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. >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> --=20 >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >>=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 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. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=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 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. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 10 07:59:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68E6120332; Wed, 10 Jul 2019 07:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.798 X-Spam-Level: X-Spam-Status: No, score=-6.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 qn0n6YsQX19e; Wed, 10 Jul 2019 07:59:48 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 AF07A1203B2; Wed, 10 Jul 2019 07:59:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EtAADr/CVd/yYyC4diAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQEBgWeBFS9QbXIDBDMKhBKBX4FoA4UxiRaCW5kKgRADGBchBAk?= =?us-ascii?q?BAQEJAQMBGAEJBwQCAQECgQKDPAIXgls4EwEDAQEBBAEBAQEEAQICaYU8DIJ0B?= =?us-ascii?q?E0SHQoCAywBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQI?= =?us-ascii?q?NAiQFAQcEEQEBARgBAQEBAgEBAQMBDAgJAgIGARIBASwEBwEEBwIEAQgRBAEBA?= =?us-ascii?q?QUBAQEYAQYDAgQFEAEDCwELFAkJAQQBDQQBBgIGDQeDAYFqAw4PAQICCqJ8AoE?= =?us-ascii?q?IMIhfAQFwfzMagl8BAQV1PQETPAQBgn4YggsHCQUEAYEqh25UgX+BNYFBPiZrR?= =?us-ascii?q?oJMPoJhAQEBAQEBFoEBCggBARIBCRAIBBEKCwEJCAmCQzKCJot7AQcBChIvgiO?= =?us-ascii?q?EfYEKh1+EeoJKhVFtCQKCGYVKAYEMgUKJO4JOgixthjWDeQOKOIwQgSCHQowXg?= =?us-ascii?q?2kCAgICBAUCDgEBBYFnIjcwcXAVGiGCbAkJgi8MF4NOhFk7hT9yAQETHXeMO4E?= =?us-ascii?q?iAYEVCwEB?= X-IPAS-Result: =?us-ascii?q?A2EtAADr/CVd/yYyC4diAxkBAQEBAQEBAQEBAQEHAQEBAQE?= =?us-ascii?q?BgWeBFS9QbXIDBDMKhBKBX4FoA4UxiRaCW5kKgRADGBchBAkBAQEJAQMBGAEJB?= =?us-ascii?q?wQCAQECgQKDPAIXgls4EwEDAQEBBAEBAQEEAQICaYU8DIJ0BE0SHQoCAywBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQINAiQFAQcEEQEBA?= =?us-ascii?q?RgBAQEBAgEBAQMBDAgJAgIGARIBASwEBwEEBwIEAQgRBAEBAQUBAQEYAQYDAgQ?= =?us-ascii?q?FEAEDCwELFAkJAQQBDQQBBgIGDQeDAYFqAw4PAQICCqJ8AoEIMIhfAQFwfzMag?= =?us-ascii?q?l8BAQV1PQETPAQBgn4YggsHCQUEAYEqh25UgX+BNYFBPiZrRoJMPoJhAQEBAQE?= =?us-ascii?q?BFoEBCggBARIBCRAIBBEKCwEJCAmCQzKCJot7AQcBChIvgiOEfYEKh1+EeoJKh?= =?us-ascii?q?VFtCQKCGYVKAYEMgUKJO4JOgixthjWDeQOKOIwQgSCHQowXg2kCAgICBAUCDgE?= =?us-ascii?q?BBYFnIjcwcXAVGiGCbAkJgi8MF4NOhFk7hT9yAQETHXeMO4EiAYEVCwEB?= X-IronPort-AV: E=Sophos;i="5.63,475,1557201600"; d="png'150?scan'150,208,217,150";a="291135845" Received: from mailauth.avaya.com (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jul 2019 10:59:14 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2019 10:59:13 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by AZ-US1EXHC04.global.avaya.com (135.11.85.15) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 10 Jul 2019 10:59:13 -0400 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.54) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Wed, 10 Jul 2019 09:59:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lZHnt6wl+A/gEW7+p02WiLaoh9Z3azJMfkcN+p6zZag=; b=abe9+XmleaBQlUHqJkkt/dIr4SY2KYE/JmUNfGyRRanibyfHUZhGHqmrx11PWxzcLnWvFKeJ4exElFPqLHKlBS5MxZDTjOg2hEq4pdKWNwpFjtjpwkBltnK3jdRzRoRRQLqmRybEykCjWfIxehGgbRCMLTALmB8NDWsNedgzLfA= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2844.namprd15.prod.outlook.com (20.178.229.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Wed, 10 Jul 2019 14:59:11 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2052.020; Wed, 10 Jul 2019 14:59:10 +0000 From: "Mudric, Dusan (Dusan)" To: JORDI PALET MARTINEZ , IPv6 Operations CC: 6man <6man@ietf.org> Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches Thread-Index: AdU3MAO94GH3M+6sQDywg8DZPsTffQ== Date: Wed, 10 Jul 2019 14:59:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c0fe9072-78a7-429c-18e9-08d705472a7e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DM6PR15MB2844; x-ms-traffictypediagnostic: DM6PR15MB2844: x-ms-exchange-purlcount: 9 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(346002)(376002)(366004)(13464003)(199004)(189003)(9686003)(86362001)(316002)(476003)(733005)(6436002)(8676002)(81156014)(229853002)(8936002)(790700001)(54556002)(4326008)(55016002)(25786009)(236005)(486006)(53386004)(53936002)(6306002)(54896002)(53946003)(99936001)(7696005)(9326002)(81166006)(99286004)(186003)(102836004)(6506007)(68736007)(53546011)(55236004)(7736002)(66476007)(76116006)(66556008)(14454004)(606006)(66616009)(66446008)(26005)(5024004)(2906002)(6116002)(5660300002)(14444005)(256004)(30864003)(110136005)(64756008)(3846002)(861006)(74316002)(52536014)(66574012)(6246003)(966005)(66946007)(478600001)(33656002)(71200400001)(66066001)(71190400001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2844; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5gYx9hWvlpCQQd+b9hNkYjg6qE39EN3iUXrjcpNuC2FYDrDxOuijg9IJ4L+Iaqlmlyn/yKN5Oo0g98BhCer+jYFkZ9M9Zy0FQ2Ixs3bd3IVd4fhJODjXhSmicNtSvg0sPsR65pIY7IXioilbiYXbU3zqVIuTwr+WA3FiSaDRbP0kgeG1GuBvrmSGuGr1TqS/M7ArmrNCZfmYuC1GbvoXSkg4d7OzG6w3exnXkw7eSt9JwwiPHEXwQ5O6qoCt8sfLUUxs0UMCvObcMUTR7YIu7BIFSs6e+kMT00/eXXOxWAcnz7IUIG2AxfS9iByMqQ70bNLVNXaJpBvWqArKrvYvAcvZm9mXKPgbyr2N+Lg3VmNwECuV4EB/+kSkI+qd5uRHWDVpZUsMepN/tkhnvOVj1tNPht4SpeEXuCq3F7vwkIw= Content-Type: multipart/related; boundary="_004_DM6PR15MB25065EFFACD414A6F1FE6E9EBBF00DM6PR15MB2506namp_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c0fe9072-78a7-429c-18e9-08d705472a7e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 14:59:10.8389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2844 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 14:59:54 -0000 --_004_DM6PR15MB25065EFFACD414A6F1FE6E9EBBF00DM6PR15MB2506namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR15MB25065EFFACD414A6F1FE6E9EBBF00DM6PR15MB2506namp_" --_000_DM6PR15MB25065EFFACD414A6F1FE6E9EBBF00DM6PR15MB2506namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQoNCkkgY2hhbmdlZCB0aGUgdGhyZWFkIHRpdGxlIHNpbmNlIHdlIGFyZSBub3cg ZGlzY3Vzc2luZyBkcmFmdC1wYWxldC12Nm9wcy00NjR4bGF0LW9wdC1jZG4tY2FjaGVzIHNvbHV0 aW9uLg0KDQpXaGVuIEROUzY0IHRyYW5zbGF0b3IgaW4gdGhpcyBmaWd1cmUgaHR0cHM6Ly9lbi53 aWtpcGVkaWEub3JnL3dpa2kvSVB2Nl90cmFuc2l0aW9uX21lY2hhbmlzbSMvbWVkaWEvRmlsZTpO QVQ2NC5zdmcgc2VuZHMgYSBwYWNrZXQgdG8gMTkyLjAuMi4xLCB0aGUgcGFja2V0IGhhcyB0aGUg c291cmNlIElQdjQgYWRkcmVzcyBvZiBETlM2NC4gSG93IGNhbiBETlMgc2VydmVyIGJlIGNvbmZp Z3VyZWQgdG8gcmV0dXJuIHRoYXQgYWRkcmVzcyBkdXJpbmcgaDIuZXhhbXBsZS5jb20gcmVzb2x1 dGlvbj8NCg0KUGxlYXNlIGZpbmQgbW9yZSBjb21tZW50cyBhbmQgcXVlc3Rpb25zIGlubGluZWQu DQoNClRoYW5rcywNCkR1c2FuLg0KDQpGcm9tOiBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGku cGFsZXRAY29uc3VsaW50ZWwuZXM+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDksIDIwMTkgNDoyNCBQ TQ0KVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKSA8ZG11ZHJpY0BhdmF5YS5jb20+OyBJUHY2IE9w ZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPg0KQ2M6IDZtYW4gPDZtYW5AaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBOQVQ2NCBpbiBSQSwgZHJhZnQtaWV0Zi02bWFuLXJhLXByZWY2NA0K DQpIaSBEdXNhbiwNCg0KVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgSVB2Ni1vbmx5IOKAnHJlbW90 ZSBzZXJ2ZXLigJ0gZG9u4oCZdCBoYXZlIElQdjQgY29ubmVjdGl2aXR5LiBBbHNvLCBpdCBkb2Vz buKAmXQgaGF2ZSBhbiBJUHY0IGFkZHJlc3MuIExldOKAmXMgc3VwcG9zZSB0aGlzIGlzIGEgc3Ry ZWFtaW5nIHNlcnZlci4NCg0KVGhlIOKAnGxvY2Fs4oCdIElQdjQtb25seSBob3N0IChsZXTigJlz IHN1cHBvc2UgaXMgYW4gSVB2NC1vbmx5IFNtYXJ0VFYpLCBpcyBjb25uZWN0ZWQgdG8gYSBDTEFU ICh0aGlzIGlzIGluIHRoZSBDUEUsIGFuZCB0aGUgQ1BFIGlzIGNvbm5lY3RlZCB2aWEgSVB2Ni1v bmx5KSB0byB0aGUgc2VydmljZSBwcm92aWRlci4NCg0KVGhlIG9wdGltaXphdGlvbiB0aGF0IHdl IGFyZSBzdWdnZXN0aW5nIGlzIHVzaW5nIEVBTSAoZXhwbGljaXQgbWFwcGluZykgdG8gYXZvaWQg dGhlIElQdjQgZmxvdyBmcm9tIHRoZSBzbWFydFRWIHRvIGJlIGNvbnZlcnRlZCBiYWNrIHRvIElQ djQsIGJlY2F1c2UgdGhlIENMQVQgYWxyZWFkeSBjb252ZXJ0ZWQgaXQgdG8gSVB2Ni4NCg0KSWYg d2UgY3JlYXRlIGEg4oCcZmFrZeKAnSBBIHJlY29yZCBpbiB0aGUgc3RyZWFtaW5nIHNlcnZlciwg dGhlIENMQVQgd2lsbCBjcmVhdGUgYW4gRUFNVCwgc28gYmVjYXVzZSBpdCBiZWxpZXZlcyB0aGUg c3RyZWFtaW5nIHNlcnZpY2UgaXMgcmVhY2hhYmxlIHdpdGggSVB2NCAod2hpY2ggaXMgbm90KSwg YnV0IHRoZSDigJxvcHRpbWl6ZWQgQ0xBVOKAnSB3aWxsIHRoZW4gdXNlIHRoZSBBQUFBLg0KDQpT bywgdGhlIGZsb3cgaXM6DQpJUHY0IGZyb20gdGhlIHNtYXJ0VFYgdG8gdGhlIENMQVQNCklQdjYg ZnJvbSB0aGUgQ0xBVCB0byB0aGUgc3RyZWFtaW5nIHNlcnZpY2UNCltEdXNhbl0gVGhpcyBpcyBh IGRpZmZlcmVudCBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyBhIGRpZmZlcmVudCB1c2UgY2FzZTog SVB2NC1vbmx5IGNsaWVudCBhY2Nlc3NpbmcgSVB2Ni1vbmx5IOKAnHJlbW90ZSBzZXJ2ZXLigJ0g aW4gSVB2NiBvbmx5IG5ldHdvcmsuIElQdjYtb25seSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCBQTEFU IChidHcsIGZvdW5kIGEgbmljZSBkaWFncmFtIHRoYXQgZGVwaWN0cyBDTEFULVBMQVQgaHR0cHM6 Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvdG1vaXB2Ni80NjR4bGF0ICkNCg0KW2h0dHA6Ly9kYW4u ZHJvd24ub3JnL2FuZHJvaWQvY2xhdC9DbGF0LVBsYXQucG5nXQ0KDQpJbiBub3JtYWwgY29uZGl0 aW9ucywgaWYgdGhlIHN0cmVhbWluZyBzZXJ2aWNlIGlzIHJlYWxseSBkdWFsLXN0YWNrDQpbRHVz YW5dIE5lZWQgdG8gYmUgbW9yZSBzcGVjaWZpYy4gSXMgdGhlIHN0cmVhbWluZyDigJxyZW1vdGUg c2VydmVy4oCdIHNlcnZlciBzdXBwb3J0aW5nIGR1YWwgc3RhY2sgYW5kIGlzIGluIGEgZHVhbCBz dGFjayBuZXR3b3JrPyBJcyB0aGUgYWNjZXNzIG5ldHdvcmsgSVB2Ni1vbmx5Pw0KYW5kIHdlIGRv buKAmXQgaGF2ZSBvcHRpbWl6YXRpb24gKHRoZSDigJxhY3R1YWzigJ0gNDY0WExBVCBwcm90b2Nv bCksIGl0IHdpbGwgYmU6DQoNCklQdjQgZnJvbSB0aGUgc21hcnRUViB0byB0aGUgQ0xBVA0KSVB2 NiBmcm9tIHRoZSBDTEFUIHRvIHRoZSBOQVQ2NA0KSVB2NCBmcm9tIHRoZSBOQVQ2NCB0byB0aGUg c3RyZWFtaW5nIHNlcnZpY2UNCltEdXNhbl0gSWYgdGhlIElQdjQtb255IGNsaWVudCBpcyBzdHJl YW1pbmcgb3ZlciBJUHY2LW9ubHkgbmV0d29yayB0byBhIGR1YWwgc3RhY2sg4oCccmVtb3RlIHNl cnZlcuKAnSBpbiBhIGR1YWwgc3RhY2sgbmV0d29yaywNCg0KICAqICAgSVB2NiBmcm9tIHRoZSBD TEFUIHRvIHRoZSBOQVQ2NA0KICAqICAgSVB2NCBmcm9tIHRoZSBOQVQ2NCB0byB0aGUgc3RyZWFt aW5nIHNlcnZpY2UNCmlzIG5vdCBuZWVkZWQuIElQdjYgYWNjZXNzIG5ldHdvcmsgY2FuIGRpcmVj dGx5IHNlbmQgSVB2NiBwYWNrZXRzIG92ZXIgZHVhbCBzdGFjayBuZXR3b3JrIHRvIHRoZSBkdWFs IHN0YWNrIOKAnHJlbW90ZSBzZXJ2ZXLigJ0uDQoNCklmIHRoZSBzdHJlYW1pbmcgc2VydmljZSBp cyBJUHY2IG9ubHksIHdpdGggdGhlIGFjdHVhbCA0NjRYTEFUIHByb3RvY29sLCB0aGlzIGNvbm5l Y3Rpdml0eSBpcyBub3QgcG9zc2libGUuDQpbRHVzYW5dIElmIHRoZSBzdHJlYW1pbmcgc2Vydmlj ZSBpcyBJUHY2IG9ubHksIG1lYW5pbmcgdGhlIElQdjYgb25seSDigJxyZW1vdGUgc2VydmVy4oCd IGlzIGluIElQdjYtb25seSBuZXR3b3JrLCBhZnRlciBJUHY0LXRvLUlQdjYgQ0xBVCB0cmFuc2xh dGlvbiB0aGUgcGFja2V0cyBmcm9tIElQdjQtb25seSBob3N0IHdpbGwgYmUgYWJsZSB0byByZWFj aCB0aGUgSVB2NiBvbmx5IOKAnHJlbW90ZSBzZXJ2ZXLigJ0uDQoNCllvdSBzZWUgdGhlIHBvaW50 Pw0KW0R1c2FuXSBOb3QgeWV0LiBQbGVhc2Ugc2VlIHRoZSBjb21tZW50cyBhYm92ZS4NCg0KUGxl YXNlIHRha2UgYSBsb29rIGF0IHRoZSBkb2N1bWVudCwgSSB0aGluayBpcyB3ZWxsIGRlc2NyaWJl ZCwgb3RoZXJ3aXNlIHByb3ZpZGUgc3VnZ2VzdGlvbnMgYWJvdXQgd2hhdCB5b3UgYmVsaWV2ZSBp cyBub3QgY2xlYXIgZW5vdWdoIGFuZCB3ZSB3aWxsIG1ha2Ugc3VyZSB0byBpbXByb3ZlIHRoZSB0 ZXh0IGFuZCBkcmF3aW5ncyENCg0KQnkgdGhlIHdheSwgSeKAmW0gdGFsa2luZyBoZXJlIGFib3V0 IOKAnGFwcHJvYWNoIDLigJ0sIHdoaWNoIEkgdGhpbmsgaXMgdGhlIGJlc3Qgc29sdXRpb24uDQpb RHVzYW5dIFNvcnJ5LCBJIGFtIG5vdCBhYmxlIHRvIGdldCB0aGUgbWFpbiBpZGVhcyBmcm9tIGRy YWZ0LXBhbGV0LXY2b3BzLTQ2NHhsYXQtb3B0LWNkbi1jYWNoZXMuIEkgZXhwZWN0IGlmIHRoZXJl IGFyZToNCg0KICAqICAgQSBkaWFncmFtIGV4cGxhaW5pbmcgdGhlIHByb2JsZW0ocykgd2l0aCBj YWxsIGZsb3dzLA0KICAqICAgRGVwaWN0ZWQgY29tcG9uZW50cyBhbmQgd2hlcmUgdGhleSBhcmUg KG9uIHdoaWNoIGRldmljZXMgKSwgYW5kDQogICogICBHbG9zc2FyeSB3aXRoIGRlZmluaXRpb25z DQppdCB3aWxsIGJlIGVhc2llciB0byBncmFzcCB0aGUgaWRlYXMuDQpbRHVzYW5dIFNlY3Rpb24g NC4yLjIgaXMgbm90IGNsZWFyLiBXaHkgRE5TIHByb3h5IHJlc29sdmVyIG5lZWRzIHRvIGRvIGFk ZGl0aW9uYWwgQUFBQSBxdWVyeT8gV2h5IGlzIHRoaXMgRE5TIHJlc3BvbnNlIG5lZWRlZCBieSBD TEFUPw0KW0R1c2FuXSBTZWN0aW9uIDQuMi4zIGdvZXMgaW50byBkZXRhaWxzIGFuZCBpdCBpcyBu b3QgY2xlYXIgd2hpY2ggcHJvYmxlbSBuZWVkcyB0byBiZSBzb2x2ZWQgYW5kIHdoYXQgdGhlIHNv bHV0aW9uIGlzLiBJIGNhbm5vdCBmb2xsb3cgdGhlc2UgZGV0YWlscyBiZWNhdXNlIEkgZG9u4oCZ dCBrbm93IHdoYXQgdGhleSBhcmUgZm9yLg0KW0R1c2FuXSBTZWN0aW9uIDQuMi40OiBteSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgRU1UIHRhYmxlIGlzIGluIENQRSByb3V0ZXIgKHNob3VsZCBiZSBk ZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50IHdoZXJlIHdoaWNoIGNvbXBvbmVudHMgYXJlIGFuZCBz aG91bGQgYmUgYSBnbG9zc2FyeSBmb3IgYWNyb255bXMsIGRlZmluaW5nIGZ1bmN0aW9uIGJsb2Nr cykgLiBQcm9iYWJseSBBIGFuZCBBQUFBIHJlc29sdXRpb25zIGFyZSBzdG9yZWQgb24gdGhlIHJv dXRlciBhbmQgd2hlbiBJUHY0IHBhY2tldCwgZGVzdGluZWQgdG8gQS1yZXNvbHZlZCBJUCwgY29t ZXMgdG8gQ1BFLCBkZXN0aW5hdGlvbiBJUHY0IGFkZHJlc3Mgd2lsbCBiZSBtYXBwZWQgdG8gSVB2 NiBhZGRyZXNzIGZyb20gQUFBQSByZXNvbHV0aW9uLiBUaGlzIHNob3VsZCBiZSBleHBsYWluZWQg YW5kIGZsb3cgZGlhZ3JhbSBwcm92aWRlZC4NCg0KUXVlc3Rpb246IFNvIGZhciBJIGNhbiBzZWUg aG93IHRoaXMgd2lsbCB3b3JrIGlmIGV2ZXJ5dGhpbmcgaXMgc3RhdGljYWxseSBjb25maWd1cmVk LiBCYXNlZCBvbiBKZW7igJlzIGNhbGwgZmxvdzoNCg0K4oCcVGhlIG93bmVyIHdvdWxkIGNyZWF0 ZSBhIEROUyBBIFJSIGZvciAgaXB2Ni1vbmx5LmV4YW1wbGUubmV0LiAtIGxldCdzIHNheSwgMTky LjAuMi4yIElwdjYtb25seSBzZXJ2ZXIgd291bGQgaGF2ZSBhbiBJUHY2IGFkZHJlc3Mgd2hpY2gg aGFzIHRoYXQgSVB2NCBhZGRyZXNzIGVuY29kZWQgLSBmb3IgZXhhbXBsZSwgMjAwMTpkYjg6MTo6 MTkyLjAuMi4yIFRoYXQgSVB2NCBhZGRyZXNzIChvciB0aGUgcHJlZml4IG1vc3QgbGlrZWx5KSB3 aWxsIGJlIHJvdXRlZCB0byB0aGUgdHJhbnNsYXRvci7igJ0NCnRoZSBJUHY2LW9ubHkg4oCccmVt b3RlIHNlcnZlcuKAnSBpcyBjb25maWd1cmVkIHRvIGhhdmUgMjAwMTpkYjg6MTo6MTkyLjAuMi4y IGFuZCBJUHY0IHBhY2tldHMgZnJvbSBJUHY0LW9ubHkgY2xpZW50LCBkZXN0aW5lZCB0byAxOTIu MC4yLjIsIHdpbGwgYmUgcm91dGVkIHRvIENQRSB0cmFuc2xhdG9yIChJIGd1ZXNzIGJlY2F1c2Ug YWxsIGRldmljZXMgYmVoaW5kIHRoZSB0cmFuc2xhdG9yIGhhdmUgdG8gYmUgaW4gdGhlIHNhbWUg c3VibmV0KS4gV2hhdCBpZiB0aGUgSVB2Ni1vbmx5IGhvc3RzIChvciB0aGUgcmVtb3RlIHNlcnZl ciBpbiB0aGlzIGV4YW1wbGUpIHVzZSBTTEFBQz8gSG93IGlzIHRoaXMgZ29pbmcgdG8gd29yaz8N Cg0KDQpSZWdhcmRzLA0KSm9yZGkNCkBqb3JkaXBhbGV0DQoNCg0KDQpFbCA5LzcvMTkgMjI6MDUs ICJ2Nm9wcyBlbiBub21icmUgZGUgTXVkcmljLCBEdXNhbiAoRHVzYW4pIiA8djZvcHMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRlIGRt dWRyaWNAYXZheWEuY29tPG1haWx0bzpkbXVkcmljQGF2YXlhLmNvbT4+IGVzY3JpYmnDszoNCg0K SGkgSm9yZGksDQoNCkFyZSB5b3Ugc2F5aW5nIHlvdXIgZHJhZnQgIOKAnDQ2NFhMQVQgT3B0aW1p emF0aW9u4oCdIHdpbGwgcHJvdmlkZSBJUHY0b25seSBhcHAgdG8gSVB2Nm9ubHkgYXBwIGNvbW11 bmljYXRpb24gbGlrZSB0aGlzPw0KDQoNCiAgICAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAg Li0tLS0tLg0KICAgICAgICAgICAgICAgICAgfCBJUHY2ICB8ICAgIC8gICAgICAgXA0KICAgICAg Li0tLS0tLiAgICAgfCAgQ0UgICB8ICAgLyAgSVB2Ni0gIFwgICAgIC4tLS0tLS4NCiAgICAgLyBJ UHY0LSBcICAgIHwgIG9yICAgKy0tKCAgIG9ubHkgICAgKS0tLSggTkFUNjQgKQ0KICAgIC8gIG9u bHkgICBcICAgfCAgVUUgICB8ICAgXCAgQWNjZXNzIC9cICAgIGAtLS0tLScNCiAgICggIFNtYXJ0 VFYgICktLSsgICAgICAgfCAgICBcICAgICAgIC8gIFwNCiAgICBcICAgU1RCICAgLyAgIHwgd2l0 aCAgfCAgICAgYC0tKy0tJyAgICBcICAgLi0tLS0tLg0KICAgICBcIFZvSVAgIC8gICAgfCBOQVQ0 NiB8ICAgICAgICB8ICAgICAgICBcIC8gICAgICAgXA0KICAgICAgYC0tLS0tJyAgICAgfCBDTEFU ICB8ICAgICstLS0rLS0tLSsgICAgLyAgSVB2NiAgIFwgICAgICAuLS0rLS0uDQogICAgICAgICAg ICAgICAgICB8ICAgICAgIHwgICAgfCAgRE5TLyAgfCAgICggIEludGVybmV0IClJUHY2LyBJUHY2 LSBcDQogICAgICAgICAgICAgICAgICArLS0tLS0tLSsgICAgfCAgRE5TNjQgfCAgICBcICAgICAg ICAgLy0tLS0vICBvbmx5ICAgXA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLSsgICAgIFwgICAgICAgLyAgICAoICAgICAgICAgICApDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGAtLS0tLScgICAgICBcICBBUFAgICAgLw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFwgICAgICAgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBgLS0tLS0nDQogICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIElQ djQgdG8gSVB2NiBmbG93IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCg0KV2hhdCBkaWQgbm90 IHdvcmsgc28gZmFyIGFuZCB3aGF0IGhhZCB0byBiZSBhZGRlZCBpbiB5b3VyIGRyYWZ0IHRvIG1h a2UgdGhpcyBmbG93IHdvcms/DQoNCkhvdyBjYW4gSVB2Ni1vbmx5IEFQUCBnZXQgdGhlIElQVjQg cHVibGljIGFkZHJlc3MsIHVzZWQgYnkgTkFUX3RyYW5zbGF0b3IsIHdoZW4gc2VuZGluZyBhIHBh Y2tldCBmcm9tIElQdjYtb255IEFQUCB0byBJUHY0LW9ubHkgQVBQPyBUaGlzIElQdjQgYWRkcmVz cyBpcyB0aGUgc2FtZSBkZXN0aW5hdGlvbiBJUHY0IGFkZHJlc3MgdG8gd2hpY2ggSVB2NC1vbmx5 IEFQUCBzZW5kcyBhIHBhY2tldCB0b3dhcmRzIElQdjYtb25seSBBUFAgKCAxOTIuMC4yLjIuIGFk ZHJlc3MgaW4gSmVu4oCZcyBleGFtcGxlKS4NCg0KVGhhbmtzLA0KRHVzYW4uDQoNCkZyb206IHY2 b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn Pj4gT24gQmVoYWxmIE9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaDQpTZW50OiBNb25kYXksIEp1bHkg OCwgMjAxOSA1OjQwIFBNDQpUbzogSVB2NiBPcGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+Pg0KQ2M6IDZtYW4gPDZtYW5AaWV0Zi5vcmc8bWFpbHRvOjZtYW5A aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gTkFUNjQgaW4gUkEsIGRyYWZ0LWlldGYt Nm1hbi1yYS1wcmVmNjQNCg0KSSB0aGluayB0aGVyZSBhcmUgc2V2ZXJhbCBwb3NzaWJsZSBzb2x1 dGlvbnMsIGJ1dCB0aGUgc2ltcGxlciBvbmUgc2VlbXMgdG8gYmUgdGhlIGR1YWwtc3RhY2sgU0lQ IHByb3hpZXMuIEFub3RoZXIgb25lIGlzIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLCB3aGljaCBJ IGRpZG7igJl0IGtuZXcsIHVudGlsIHRvZGF5LCBpcyBhbHJlYWR5IGluIHRoZSBJRVNHIGZvciBh cHByb3ZhbCB0aGlzIFRocnVzZGF5Lg0KQWxzbyBpdCBjYW4gYmUgZG9uZSB3aXRoIEVBTSBhbmQg YWxzbyBhcyBJIG1lbnRpb24gaW4gYSBwcmV2aW91cyBlbWFpbCB2aWEgdGhlIG9wdGltaXphdGlv biBmb3IgNDY0WExBVC4gSnVzdCB1cGxvYWRlZCB0aGUgbmV3IHZlcnNpb246DQoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBhbGV0LXY2b3BzLTQ2NHhsYXQtb3B0LWNk bi1jYWNoZXMvP2luY2x1ZGVfdGV4dD0xPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEcGFs ZXQtMkR2Nm9wcy0yRDQ2NHhsYXQtMkRvcHQtMkRjZG4tMkRjYWNoZXNfLTNGaW5jbHVkZS01RnRl eHQtM0QxJmQ9RHdNRmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnho ZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1XUGs3bmw3b25HREZDQmlkV1RYalppVTd0 dVpRMlN2eVN5YXBnZXBqZlBzJnM9bTViZmJ2c3BGc2puNnUwY1U5ZWxVRDYtMG5LTzl6dVFFMnhN Q2pqS3Z5dyZlPT4NCg0KDQoNCg0KDQpFbCA4LzcvMTkgMTk6MDEsICJ2Nm9wcyBlbiBub21icmUg ZGUgRGF2aWQgRmFybWVyIiA8djZvcHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRlIGZhcm1lckB1bW4uZWR1PG1haWx0bzpmYXJtZXJA dW1uLmVkdT4+IGVzY3JpYmnDszoNCg0KDQoNCk9uIE1vbiwgSnVsIDgsIDIwMTkgYXQgMTA6NDkg QU0gTXVkcmljLCBEdXNhbiAoRHVzYW4pIDxkbXVkcmljQGF2YXlhLmNvbTxtYWlsdG86ZG11ZHJp Y0BhdmF5YS5jb20+PiB3cm90ZToNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogTWFuZnJlZGkgKFVTKSwgQWxiZXJ0IEUgPGFsYmVydC5lLm1hbmZyZWRpQGJvZWluZy5jb208 bWFpbHRvOmFsYmVydC5lLm1hbmZyZWRpQGJvZWluZy5jb20+Pg0KPg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OmlwdjYtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNdWRyaWMsIER1c2FuIChEdXNh bikNCj4NCj4gPiAtIEhvdyBjYW4gRE5TNjQgdGVsbCBJUHY2IG9ubHkgY2xpZW50IHRoZSBJUCBv ZiBJUHY0IG9ubHkgY2xpZW50LCBhbmQgdmljZQ0KPiB2ZXJzYT8NCj4NCj4gSVB2NiB0byBJUHY0 IHNob3VsZCBiZSBzdHJhaWdodGZvcndhcmQsIGJlY2F1c2UgaXQncyBhIG9uZS10by1vbmUNCj4g cmVsYXRpb25zaGlwLiBUaGUgb3RoZXIgd2F5IGFyb3VuZCB3b3VsZCBub3JtYWxseSBub3Qgd29y aywNCltEdXNhbl0gVGhlcmUgaXMgbm8gc29sdXRpb24gZm9yIElQdjRvbmx5IGNsaWVudCB0byBy ZWFjaCBJUHY2b25seSBjbGllbnQ/DQoNCkkgbW9zdGx5IHNheSwgc28gd2hhdCEgSXQgaXMgYW4g dW5mb3J0dW5hdGUgcmVhbGl0eSBvZiB0b2RheSdzIEludGVybmV0LCBiZWNhdXNlIG9mIE5BVDQ0 IGFuZC9vciBzdGF0ZWZ1bCBmaXJld2FsbCBkZWZhdWx0IGRlbnkgaW5ib3VuZCBwb2xpY3ksIG1h bnkgdGltZXMgY2xpZW50cyBjYW4ndCBzcGVhayB0byBvdGhlciBjbGllbnRzLCBiZSB0aGV5IElQ djQgb25seSwgSVB2NiBvbmx5LCBvciBldmVuIGR1YWwgc3RhY2suIFNvbWV0aW1lcyBmaXJld2Fs bCB0cmF2ZXJzYWwgdGVjaG5vbG9naWVzIGNhbiB3b3JrIGFyb3VuZCB0aGlzLCBhbHNvIGRlcGVu ZGluZyBvbiB0aGUgZmlyZXdhbGwgdHJhdmVyc2FsIHNvbHV0aW9uIHVzZWQgc29tZXRpbWVzIElQ djQgb25seSBhbmQgSVB2NiBvbmx5IGNsaWVudHMgd2lsbCBiZSBhYmxlIHRvIHRhbGsgdG8gZWFj aCBvdGhlci4gIE15IGd1ZXNzIGlzIHRoYXQgSVB2NCBvbmx5IHRvIElQdjYgb25seSBmaXJld2Fs bCB0cmF2ZXJzYWwgd291bGQgYmUgbGVzcyBlZmZlY3RpdmUgdGhhbiBOQVQ0NCBjbGllbnQgdG8g TkFUNDQgY2xpZW50IGZpcmV3YWxsIHRyYXZlcnNhbCwgYnV0IGl0IGlzIHNob3VsZCBzdGlsbCBi ZSBwb3NzaWJsZSBpbiBzb21lIGNhc2VzLg0KDQo+IGJ1dCBldmVyeW9uZQ0KPiBoYXMgYmVlbiBh Y2N1c3RvbWVkIHRvIHRoYXQgd2l0aCBJUHY0IE5BUFQgYWxyZWFkeS4NCltEdXNhbl0gSG93IElQ djQgb25seSB1c2VycyAoZS5nLiBBdmF5YSBJUHY0IG9ubHkgcGhvbmVzKSBjYW4gYmUgYWNjdXN0 b21lZCBub3QgdG8gYmUgYWJsZSB0byBjYWxsIElQdjZvbmx5IHVzZXJzIChsaWtlIEFwcGxlIElQ djYgb25seSBwaG9uZXMpPw0KDQpUaGV5IG1heSBub3QgYmUgYWJsZSB0byB0YWxrIHBlZXIgdG8g cGVlci4gSG93ZXZlciwgdGhyb3VnaCBhIGR1YWwtc3RhY2sgU0lQIG9yIG90aGVyIHByb3hpZXMv c2Vzc2lvbiBib3JkZXIgY29udHJvbGxlciwgdGhleSBjb3VsZCBwcm9iYWJseSBjb21wbGV0ZSBh IGNhbGwuDQoNCj5UaGUgY2xpZW50IGJlaGluZCB0aGUNCj4gTkFQVCBpbml0aWF0ZXMuDQo+DQo+ ID4gSXMgRE5TNjQgc2VydmVyIHJldHVybmluZyBJUHY0b255IGNsaWVudCBhZGRyZXNzIHRvIElQ djZvbmx5IGNsaWVudCwgdXNpbmcNCj4gdGhlIEEgUlI/DQo+DQo+IFRoZSBETlMgc3ludGhlc2l6 ZXMgdGhlIElQdjYgYWRkcmVzcywgd2hpY2ggaGFzIHRoZSBJUHY0IGFkZHJlc3MNCj4gZW1iZWRk ZWQgaW4gaXQuDQo+DQo+ID4gLSBIb3cgY2FuIElQdjRvbmx5IGNsaWVudCBnZXQgdGhlIGFkZHJl c3Mgb2YgSVB2Nm9ubHkgY2xpZW50IChvciwgaXQgaXMNCj4gaW1wb3NzaWJsZSBmb3IgSVB2NG9u bHkgY2xpZW50IHRvIGdldCBJUHY2IGFkZHJlc3Mgb2YgSVB2Nm9ubHkgY2xpZW50KT8NCj4NCj4g VGhhdCdzIGNsZWFybHkgbW9yZSBkaWZmaWN1bHQsIHdoaWNoIGlzIHdoeSB0aGUgbm9ybWFsIGNv dXJzZSBvZiBhY3Rpb24gaXMgZm9yDQo+IHRoZSBJUHY2IGNsaWVudCB0byBpbml0aWF0ZSB0aGUg c2Vzc2lvbi4uDQpbRHVzYW5dIFdoYXQgaWYgSVB2NG9ubHkgY2xpZW50IG5lZWRzIHRvIGluaXRp YXRlIHRoZSBzZXNzaW9uIHRvIElQdjZvbmx5IGNsaWVudD8gV2hhdCBpcyB0aGUgc29sdXRpb24g Zm9yIHRoYXQgdXNlIGNhc2U/DQoNCk1hbnkgZmlyZXdhbGwgdHJhdmVyc2FsIHNvbHV0aW9ucyBz aG91bGQgd29yayBpbiB0aGlzIGNhc2UsIGJ1dCBJUHY0IG9ubHkgY2xpZW50IHRvIGNsaWVudCBp c24ndCBndWFyYW50ZWVkIHRvIHdvcmsgaW4gYWxsIGNhc2VzIGVpdGhlci4NCg0KPg0KPiA+IC0g RG8gdGhlc2UgSVB2NCBhbmQgSVB2NiBjbGllbnQgYWRkcmVzc2VzIG5lZWQgdG8gYmUgcHJlLWNv bmZpZ3VyZWQgb24gdGhlDQo+IHRyYW5zbGF0b3IgYW5kL29yIEROUzY0Pw0KPg0KPiBGb3IgSVB2 NCB0byBJUHY2LCBpZiB5b3UgbXVzdCBhbGxvdyB0aGUgSVB2NCBjbGllbnQgdG8gaW5pdGlhdGUg dGhlIHNlc3Npb24sIHlvdSdkDQo+IGhhdmUgdG8gaGF2ZSBwcmVjb25maWd1cmUgc29tZXRoaW5n Lg0KW0R1c2FuXSBXaGVyZSBhbmQgaG93IGlzIHRoaXMgY29uZmlndXJhdGlvbiBkb25lPw0KDQo+ DQo+IEJlcnQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pcHY2JmQ9RHdNRmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2la SDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1XUGs3 bmw3b25HREZDQmlkV1RYalppVTd0dVpRMlN2eVN5YXBnZXBqZlBzJnM9Szc2NmY0dzVFbWpPWmkw dnJFMzRtUFJCT2luZGxIY2c5em1uWUIteGZ0cyZlPT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KLS0NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEYXZpZCBGYXJt ZXIgICAgICAgICAgICAgICBFbWFpbDpmYXJtZXJAdW1uLmVkdTxtYWlsdG86RW1haWwlM0FmYXJt ZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcgJiBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlcw0KT2Zm aWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kNClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQoy MjE4IFVuaXZlcnNpdHkgQXZlIFNFICAgICAgICBQaG9uZTogNjEyLTYyNi0wODE1DQpNaW5uZWFw b2xpcywgTU4gNTU0MTQtMzAyOSAgIENlbGw6IDYxMi04MTItOTk1Mg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlzdCB2Nm9wc0BpZXRmLm9y ZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192Nm9wcyZkPUR3UUZhUSZjPUJG cFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAy OXNNUUdRMmtZJm09V1BrN25sN29uR0RGQ0JpZFdUWGpaaVU3dHVaUTJTdnlTeWFwZ2VwamZQcyZz PU94ZnF2enlsbUlRMElHY2tCV2ZncTR6MEpzclBEeVhCUTM0V29RTG1WYUUmZT0+DQoNCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCklQdjQgaXMgb3Zlcg0K QXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQpodHRwOi8vd3d3LnRoZWlwdjZj b21wYW55LmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cC0zQV9fd3d3LnRoZWlwdjZjb21wYW55LmNvbSZkPUR3UUZhUSZjPUJGcFdRdzhic3VLcGwxU2dp Wkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09V1Br N25sN29uR0RGQ0JpZFdUWGpaaVU3dHVaUTJTdnlTeWFwZ2VwamZQcyZzPURsWGFGQVM5RDRpWHdB Q19MOWNqcjNfMWpWR1ZYc18yNXJuNjZUdmo3cjgmZT0+DQpUaGUgSVB2NiBDb21wYW55DQoNClRo aXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBw cml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRv IGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92 ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsIGNvcHlp bmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRp b24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2Uu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkg ZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMg b2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hl ZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3Jp bWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0 byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9wcyBtYWlsaW5nIGxp c3QgdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZv cHMmZD1Ed1FGYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lD cmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUg2THo0SmFNN3VnbDl0aTh0azhoaGVRWHVxQ000 MUlKeUZ6b1JSaVdtbXMmcz1DQ2VlTDdILTc3R21pczRYVjljaVJTdE5EUUZuMVpOSFh5SmVSUjRp S1FZJmU9Pg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQpJUHY0IGlzIG92ZXINCkFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KaHR0 cDovL3d3dy50aGVpcHY2Y29tcGFueS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy50aGVpcHY2Y29tcGFueS5jb20mZD1Ed1FGYVEmYz1C RnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMw MjlzTVFHUTJrWSZtPUg2THo0SmFNN3VnbDl0aTh0azhoaGVRWHVxQ000MUlKeUZ6b1JSaVdtbXMm cz1SZnNWMS1vSHRTY2RNSFN3UVl6Y0ZXTjZHc0s2cXhtTnExZG1sN3E5OGo4JmU9Pg0KVGhlIElQ djYgQ29tcGFueQ0KDQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlv biB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlv biBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBk aXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBv ZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVk IGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBj cmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJl IGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ug b2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBp bmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUg Y29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBv cmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVs ZXRlIGl0Lg0K --_000_DM6PR15MB25065EFFACD414A6F1FE6E9EBBF00DM6PR15MB2506namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FsaWJyaSBMaWdodCI7DQoJcGFub3NlLTE6MiAxNSAzIDIgMiAyIDQgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAy IDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFk aW5nIDIgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglmb250 LXdlaWdodDpub3JtYWw7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAyIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIiOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuVHR1bG8yLCBsaS5U dHVsbzIsIGRpdi5UdHVsbzINCgl7bXNvLXN0eWxlLW5hbWU6IlTDrXR1bG8gMiI7DQoJbXNvLXN0 eWxlLWxpbms6IlTDrXR1bG8gMiBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5UdHVsbzJDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlTDrXR1bG8gMiBDYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJUw610dWxvIDIiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMyRjU0OTY7 fQ0KcC5IVE1MY29uZm9ybWF0b3ByZXZpbywgbGkuSFRNTGNvbmZvcm1hdG9wcmV2aW8sIGRpdi5I VE1MY29uZm9ybWF0b3ByZXZpbw0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBjb24gZm9ybWF0byBw cmV2aW8iOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIGNvbiBmb3JtYXRvIHByZXZpbyBDYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MY29uZm9ybWF0 b3ByZXZpb0Nhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBjb24gZm9ybWF0byBwcmV2aW8gQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgY29uIGZv cm1hdG8gcHJldmlvIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUy NQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDg1 LjA1cHQgNzAuODVwdCA4NS4wNXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 NDIyMTMyMDA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi04OTk1MTIxNjIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6OTY2 ODQ4OTQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0z NzkzMDI4NzQgLTE3NjY4MzMwODAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli cmk7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7 bXNvLWxpc3QtaWQ6MTUxMzE4NjEyODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTgwMDE4NjQyMCAtMTkzNjU3NjQ1NiA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjE2Ow0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1 OS4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwyOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NzcuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MTEzLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTQ5LjI1cHQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjE4NS4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMjEu MjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNTcuMjVwdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MjkzLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMyOS4yNXB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMN Cgl7bXNvLWxpc3QtaWQ6MTc2MDUxNTUyNjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MTU3MzM5OTA3NiAtMTkzNjU3NjQ1NiA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjE2Ow0KCW1zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDouNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMzps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MS43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuMjVpbjsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFy Z2luLWxlZnQ6Mi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozLjI1aW47DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0LjI1 aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQuNzVpbjsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBKb3JkaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBjaGFuZ2VkIHRoZSB0aHJlYWQgdGl0bGUgc2luY2Ugd2UgYXJlIG5vdyBkaXNjdXNzaW5n IDxiPjxpPmRyYWZ0LXBhbGV0LXY2b3BzLTQ2NHhsYXQtb3B0LWNkbi1jYWNoZXMNCjwvaT48L2I+ c29sdXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gRE5TNjQgdHJhbnNsYXRvciBp biB0aGlzIGZpZ3VyZSA8YSBocmVmPSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9JUHY2 X3RyYW5zaXRpb25fbWVjaGFuaXNtIy9tZWRpYS9GaWxlOk5BVDY0LnN2ZyI+DQpodHRwczovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9JUHY2X3RyYW5zaXRpb25fbWVjaGFuaXNtIy9tZWRpYS9GaWxl Ok5BVDY0LnN2ZzwvYT4gc2VuZHMgYSBwYWNrZXQgdG8gMTkyLjAuMi4xLCB0aGUgcGFja2V0IGhh cyB0aGUgc291cmNlIElQdjQgYWRkcmVzcyBvZiBETlM2NC4gSG93IGNhbiBETlMgc2VydmVyIGJl IGNvbmZpZ3VyZWQgdG8gcmV0dXJuIHRoYXQgYWRkcmVzcyBkdXJpbmcgaDIuZXhhbXBsZS5jb20g cmVzb2x1dGlvbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGZpbmQgbW9yZSBjb21t ZW50cyBhbmQgcXVlc3Rpb25zIGlubGluZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkR1c2FuLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBKT1JESSBQQUxFVCBNQVJUSU5FWiAmbHQ7am9y ZGkucGFsZXRAY29uc3VsaW50ZWwuZXMmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg SnVseSA5LCAyMDE5IDQ6MjQgUE08YnI+DQo8Yj5Ubzo8L2I+IE11ZHJpYywgRHVzYW4gKER1c2Fu KSAmbHQ7ZG11ZHJpY0BhdmF5YS5jb20mZ3Q7OyBJUHY2IE9wZXJhdGlvbnMgJmx0O3Y2b3BzQGll dGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gNm1hbiAmbHQ7Nm1hbkBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gTkFUNjQgaW4gUkEsIGRyYWZ0LWlldGYtNm1h bi1yYS1wcmVmNjQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IaSBEdXNhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIElQdjYtb25seSDi gJxyZW1vdGUgc2VydmVy4oCdIGRvbuKAmXQgaGF2ZSBJUHY0IGNvbm5lY3Rpdml0eS4gQWxzbywg aXQgZG9lc27igJl0IGhhdmUgYW4gSVB2NCBhZGRyZXNzLiBMZXTigJlzIHN1cHBvc2UgdGhpcyBp cyBhIHN0cmVhbWluZyBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5UaGUg4oCcbG9jYWzigJ0gSVB2NC1vbmx5IGhvc3QgKGxldOKAmXMgc3VwcG9zZSBp cyBhbiBJUHY0LW9ubHkgU21hcnRUViksIGlzIGNvbm5lY3RlZCB0byBhIENMQVQgKHRoaXMgaXMg aW4gdGhlIENQRSwgYW5kIHRoZSBDUEUgaXMgY29ubmVjdGVkIHZpYSBJUHY2LW9ubHkpIHRvIHRo ZSBzZXJ2aWNlIHByb3ZpZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+VGhlIG9wdGltaXphdGlvbiB0aGF0IHdlIGFyZSBzdWdnZXN0aW5nIGlzIHVzaW5nIEVB TSAoZXhwbGljaXQgbWFwcGluZykgdG8gYXZvaWQgdGhlIElQdjQgZmxvdyBmcm9tIHRoZSBzbWFy dFRWIHRvIGJlIGNvbnZlcnRlZCBiYWNrIHRvIElQdjQsIGJlY2F1c2UgdGhlIENMQVQgYWxyZWFk eSBjb252ZXJ0ZWQgaXQgdG8gSVB2Ni48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPklmIHdlIGNyZWF0ZSBhIOKAnGZha2XigJ0gQSByZWNvcmQgaW4gdGhlIHN0cmVh bWluZyBzZXJ2ZXIsIHRoZSBDTEFUIHdpbGwgY3JlYXRlIGFuIEVBTVQsIHNvIGJlY2F1c2UgaXQg YmVsaWV2ZXMgdGhlIHN0cmVhbWluZyBzZXJ2aWNlIGlzIHJlYWNoYWJsZSB3aXRoIElQdjQgKHdo aWNoIGlzIG5vdCksIGJ1dCB0aGUg4oCcb3B0aW1pemVkIENMQVTigJ0gd2lsbCB0aGVuDQogdXNl IHRoZSBBQUFBLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+U28s IHRoZSBmbG93IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JUHY0IGZyb20gdGhlIHNtYXJ0VFYgdG8g dGhlIENMQVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SVB2NiBmcm9tIHRoZSBDTEFUIHRvIHRoZSBzdHJl YW1pbmcgc2VydmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPltEdXNhbl0gVGhpcyBpcyBhIGRpZmZlcmVudCBzb2x1dGlvbiB0aGF0IGFkZHJlc3Nl cyBhIGRpZmZlcmVudCB1c2UgY2FzZTogSVB2NC1vbmx5IGNsaWVudCBhY2Nlc3NpbmcgSVB2Ni1v bmx5IOKAnHJlbW90ZSBzZXJ2ZXLigJ0gaW4gSVB2NiBvbmx5IG5ldHdvcmsuIElQdjYtb25seSBz ZXJ2ZXIgZG9lcyBub3QgbmVlZCBQTEFUIChidHcsIGZvdW5kIGEgbmljZSBkaWFncmFtIHRoYXQg ZGVwaWN0cyBDTEFULVBMQVQNCjxhIGhyZWY9Imh0dHBzOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRl L3Rtb2lwdjYvNDY0eGxhdCI+aHR0cHM6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvdG1vaXB2Ni80 NjR4bGF0PC9hPiApPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9 IjAiIHdpZHRoPSIxMDMxIiBoZWlnaHQ9IjUxNiIgc3R5bGU9IndpZHRoOjEwLjczOTVpbjtoZWln aHQ6NS4zNzVpbiIgaWQ9IlBpY3R1cmVfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDEucG5nQDAx RDUzNzA4LkU2N0MwMDkwIiBhbHQ9Imh0dHA6Ly9kYW4uZHJvd24ub3JnL2FuZHJvaWQvY2xhdC9D bGF0LVBsYXQucG5nIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SW4gbm9y bWFsIGNvbmRpdGlvbnMsIGlmIHRoZSBzdHJlYW1pbmcgc2VydmljZSBpcyByZWFsbHkgZHVhbC1z dGFjaw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ W0R1c2FuXSBOZWVkIHRvIGJlIG1vcmUgc3BlY2lmaWMuIElzIHRoZSBzdHJlYW1pbmcg4oCccmVt b3RlIHNlcnZlcuKAnSBzZXJ2ZXIgc3VwcG9ydGluZyBkdWFsIHN0YWNrIGFuZCBpcyBpbiBhIGR1 YWwgc3RhY2sgbmV0d29yaz8gSXMgdGhlIGFjY2VzcyBuZXR3b3JrIElQdjYtb25seT88L2k+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+YW5kIHdl IGRvbuKAmXQgaGF2ZSBvcHRpbWl6YXRpb24gKHRoZSDigJxhY3R1YWzigJ0gNDY0WExBVCBwcm90 b2NvbCksIGl0IHdpbGwgYmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5JUHY0IGZyb20gdGhlIHNtYXJ0VFYgdG8gdGhlIENMQVQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ SVB2NiBmcm9tIHRoZSBDTEFUIHRvIHRoZSBOQVQ2NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JUHY0IGZy b20gdGhlIE5BVDY0IHRvIHRoZSBzdHJlYW1pbmcgc2VydmljZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltEdXNhbl0gSWYgdGhlIElQdjQtb255IGNs aWVudCBpcyBzdHJlYW1pbmcgb3ZlciBJUHY2LW9ubHkgbmV0d29yayB0byBhIGR1YWwgc3RhY2sg 4oCccmVtb3RlIHNlcnZlcuKAnSBpbiBhIGR1YWwgc3RhY2sgbmV0d29yaywNCjxvOnA+PC9vOnA+ PC9pPjwvYj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklQdjYgZnJv bSB0aGUgQ0xBVCB0byB0aGUgTkFUNjQ8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklQdjQgZnJvbSB0aGUgTkFU NjQgdG8gdGhlIHN0cmVhbWluZyBzZXJ2aWNlPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+aXMgbm90IG5lZWRlZC4gSVB2NiBhY2Nlc3MgbmV0 d29yayBjYW4gZGlyZWN0bHkgc2VuZCBJUHY2IHBhY2tldHMgb3ZlciBkdWFsIHN0YWNrIG5ldHdv cmsgdG8gdGhlIGR1YWwgc3RhY2sg4oCccmVtb3RlIHNlcnZlcuKAnS48bzpwPjwvbzpwPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JZiB0aGUgc3RyZWFtaW5nIHNlcnZpY2UgaXMg SVB2NiBvbmx5LCB3aXRoIHRoZSBhY3R1YWwgNDY0WExBVCBwcm90b2NvbCwgdGhpcyBjb25uZWN0 aXZpdHkgaXMgbm90IHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPltEdXNhbl0gSWYgdGhlIHN0cmVhbWluZyBzZXJ2aWNlIGlzIElQdjYg b25seSwgbWVhbmluZyB0aGUgSVB2NiBvbmx5IOKAnHJlbW90ZSBzZXJ2ZXLigJ0gaXMgaW4gSVB2 Ni1vbmx5IG5ldHdvcmssIGFmdGVyIElQdjQtdG8tSVB2NiBDTEFUIHRyYW5zbGF0aW9uIHRoZSBw YWNrZXRzIGZyb20gSVB2NC1vbmx5IGhvc3Qgd2lsbCBiZSBhYmxlIHRvIHJlYWNoIHRoZSBJUHY2 IG9ubHkg4oCccmVtb3RlIHNlcnZlcuKAnS48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5Zb3Ugc2VlIHRoZSBwb2ludD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5bRHVzYW5dIE5vdCB5ZXQuIFBsZWFzZSBzZWUgdGhl IGNvbW1lbnRzIGFib3ZlLjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPlBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgZG9jdW1lbnQsIEkgdGhpbmsgaXMgd2VsbCBk ZXNjcmliZWQsIG90aGVyd2lzZSBwcm92aWRlIHN1Z2dlc3Rpb25zIGFib3V0IHdoYXQgeW91IGJl bGlldmUgaXMgbm90IGNsZWFyIGVub3VnaCBhbmQgd2Ugd2lsbCBtYWtlIHN1cmUgdG8gaW1wcm92 ZSB0aGUgdGV4dCBhbmQgZHJhd2luZ3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5CeSB0aGUgd2F5LCBJ4oCZbSB0YWxraW5nIGhlcmUgYWJvdXQg4oCcYXBwcm9h Y2ggMuKAnSwgd2hpY2ggSSB0aGluayBpcyB0aGUgYmVzdCBzb2x1dGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5bRHVzYW5dIFNvcnJ5LCBJIGFt IG5vdCBhYmxlIHRvIGdldCB0aGUgbWFpbiBpZGVhcyBmcm9tIGRyYWZ0LXBhbGV0LXY2b3BzLTQ2 NHhsYXQtb3B0LWNkbi1jYWNoZXMuIEkgZXhwZWN0IGlmIHRoZXJlIGFyZTo8bzpwPjwvbzpwPjwv aT48L2I+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy4yNXB0O21zby1s aXN0OmwyIGxldmVsMSBsZm80Ij4NCjxiPjxpPkEgZGlhZ3JhbSBleHBsYWluaW5nIHRoZSBwcm9i bGVtKHMpIHdpdGggY2FsbCBmbG93cywgPG86cD48L286cD48L2k+PC9iPjwvbGk+PGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuMjVwdDttc28tbGlzdDps MiBsZXZlbDEgbGZvNCI+DQo8Yj48aT5EZXBpY3RlZCBjb21wb25lbnRzIGFuZCB3aGVyZSB0aGV5 IGFyZSAob24gd2hpY2ggZGV2aWNlcyApLCBhbmQ8bzpwPjwvbzpwPjwvaT48L2I+PC9saT48bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy4yNXB0O21zby1s aXN0OmwyIGxldmVsMSBsZm80Ij4NCjxiPjxpPkdsb3NzYXJ5IHdpdGggZGVmaW5pdGlvbnM8bzpw PjwvbzpwPjwvaT48L2I+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+aXQg d2lsbCBiZSBlYXNpZXIgdG8gZ3Jhc3AgdGhlIGlkZWFzLjxvOnA+PC9vOnA+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5bRHVzYW5dIFNlY3Rpb24gNC4yLjIgaXMgbm90 IGNsZWFyLiBXaHkgRE5TIHByb3h5IHJlc29sdmVyIG5lZWRzIHRvIGRvIGFkZGl0aW9uYWwgQUFB QSBxdWVyeT8gV2h5IGlzIHRoaXMgRE5TIHJlc3BvbnNlIG5lZWRlZCBieSBDTEFUPzwvaT48L2I+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+W0R1c2FuXSA8L3NwYW4+PC9pPjwvYj48Yj48aT5TZWN0aW9uIDQu Mi4zIGdvZXMgaW50byBkZXRhaWxzIGFuZCBpdCBpcyBub3QgY2xlYXIgd2hpY2ggcHJvYmxlbSBu ZWVkcyB0byBiZSBzb2x2ZWQgYW5kIHdoYXQgdGhlIHNvbHV0aW9uIGlzLiBJIGNhbm5vdCBmb2xs b3cgdGhlc2UgZGV0YWlscyBiZWNhdXNlIEkgZG9u4oCZdCBrbm93IHdoYXQgdGhleQ0KIGFyZSBm b3IuPC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+W0R1c2FuXSBTZWN0aW9uIDQuMi40 OiBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgRU1UIHRhYmxlIGlzIGluIENQRSByb3V0ZXIgKHNo b3VsZCBiZSBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50IHdoZXJlIHdoaWNoIGNvbXBvbmVudHMg YXJlIGFuZCBzaG91bGQgYmUgYSBnbG9zc2FyeSBmb3IgYWNyb255bXMsIGRlZmluaW5nIGZ1bmN0 aW9uIGJsb2NrcykgLiBQcm9iYWJseSBBIGFuZCBBQUFBIHJlc29sdXRpb25zDQogYXJlIHN0b3Jl ZCBvbiB0aGUgcm91dGVyIGFuZCB3aGVuIElQdjQgcGFja2V0LCBkZXN0aW5lZCB0byBBLXJlc29s dmVkIElQLCBjb21lcyB0byBDUEUsIGRlc3RpbmF0aW9uIElQdjQgYWRkcmVzcyB3aWxsIGJlIG1h cHBlZCB0byBJUHY2IGFkZHJlc3MgZnJvbSBBQUFBIHJlc29sdXRpb24uIFRoaXMgc2hvdWxkIGJl IGV4cGxhaW5lZCBhbmQgZmxvdyBkaWFncmFtIHByb3ZpZGVkLjxvOnA+PC9vOnA+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+UXVlc3Rpb246IFNvIGZhciBJIGNhbiBz ZWUgaG93IHRoaXMgd2lsbCB3b3JrIGlmIGV2ZXJ5dGhpbmcgaXMgc3RhdGljYWxseSBjb25maWd1 cmVkLiBCYXNlZCBvbiBKZW7igJlzIGNhbGwgZmxvdzo8bzpwPjwvbzpwPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+4oCcVGhlIG93bmVyIHdvdWxkIGNyZWF0ZSBhIEROUyBB IFJSIGZvciZuYnNwOyBpcHY2LW9ubHkuZXhhbXBsZS5uZXQuIC0gbGV0J3Mgc2F5LCAxOTIuMC4y LjIgSXB2Ni1vbmx5IHNlcnZlciB3b3VsZCBoYXZlIGFuIElQdjYgYWRkcmVzcyB3aGljaCBoYXMg dGhhdCBJUHY0IGFkZHJlc3MgZW5jb2RlZCAtIGZvciBleGFtcGxlLCAyMDAxOmRiODoxOjoxOTIu MC4yLjIgVGhhdCBJUHY0IGFkZHJlc3MgKG9yIHRoZSBwcmVmaXgNCiBtb3N0IGxpa2VseSkgd2ls bCBiZSByb3V0ZWQgdG8gdGhlIHRyYW5zbGF0b3Iu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT50aGUgSVB2Ni1vbmx5IOKAnHJlbW90ZSBzZXJ2ZXLigJ0gaXMg Y29uZmlndXJlZCB0byBoYXZlIDIwMDE6ZGI4OjE6OjE5Mi4wLjIuMiBhbmQgSVB2NCBwYWNrZXRz IGZyb20gSVB2NC1vbmx5IGNsaWVudCwgZGVzdGluZWQgdG8gMTkyLjAuMi4yLCB3aWxsIGJlIHJv dXRlZCB0byBDUEUgdHJhbnNsYXRvciAoSSBndWVzcyBiZWNhdXNlIGFsbCBkZXZpY2VzIGJlaGlu ZCB0aGUgdHJhbnNsYXRvciBoYXZlIHRvIGJlDQogaW4gdGhlIHNhbWUgc3VibmV0KS4gV2hhdCBp ZiB0aGUgSVB2Ni1vbmx5IGhvc3RzIChvciB0aGUgcmVtb3RlIHNlcnZlciBpbiB0aGlzIGV4YW1w bGUpIHVzZSBTTEFBQz8gSG93IGlzIHRoaXMgZ29pbmcgdG8gd29yaz88bzpwPjwvbzpwPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Kb3JkaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkBqb3JkaXBhbGV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPkVsIDkvNy8xOSAyMjowNSwgJnF1b3Q7djZvcHMgZW4g bm9tYnJlIGRlIE11ZHJpYywgRHVzYW4gKER1c2FuKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmciPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IGVuIG5v bWJyZSBkZQ0KPGEgaHJlZj0ibWFpbHRvOmRtdWRyaWNAYXZheWEuY29tIj5kbXVkcmljQGF2YXlh LmNvbTwvYT4mZ3Q7IGVzY3JpYmnDszo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40 cHQiPjxzcGFuIGxhbmc9IkVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVTIj5IaSBKb3JkaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPkFyZSB5b3Ugc2F5aW5nIHlvdXIgZHJhZnQgJm5i c3A74oCcPC9zcGFuPjxiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ NDY0WExBVCBPcHRpbWl6YXRpb27igJ08L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVTIiBzdHls ZT0iZm9udC1zaXplOjE4LjBwdCI+DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVTIj53aWxsIHBy b3ZpZGUgSVB2NG9ubHkgYXBwIHRvIElQdjZvbmx5IGFwcCBjb21tdW5pY2F0aW9uIGxpa2UgdGhp cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNw YW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40 cHQiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4t LS0tLS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IElQ djYmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsuLS0tLS0uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsgQ0UmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAvJm5ic3A7IElQdjYtJm5ic3A7 IFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi0tLS0tLiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy8gSVB2NC0gXCZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7IG9yJm5ic3A7Jm5ic3A7ICYjNDM7LS0oJm5ic3A7Jm5ic3A7IG9ubHkmbmJzcDsmbmJz cDsmbmJzcDsgKS0tLSggTkFUNjQgKTwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRw dCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyBvbmx5Jm5i c3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsgfCZuYnNwOyBVRSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7IFwmbmJzcDsgQWNjZXNzIC9cJm5ic3A7Jm5ic3A7Jm5ic3A7IGAtLS0tLScmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNw YW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsoJm5ic3A7IFNtYXJ0VFYmbmJzcDsg KS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsgXCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3Bh biBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1wmbmJzcDsmbmJzcDsgU1RC Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsgfCB3aXRoJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYC0tJiM0MzstLScmbmJzcDsmbmJzcDsmbmJzcDsgXCZuYnNwOyZuYnNwOyAuLS0t LS0uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7XCBWb0lQJm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsgfCBOQVQ0NiB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXCAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFw8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9 IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGAtLS0tLScmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCBDTEFUJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0m IzQzOy0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7IElQdjYmbmJzcDsmbmJzcDsg XCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuLS0mIzQzOy0tLjwvc3Bhbj48c3BhbiBs YW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgRE5TLyZuYnNwOyB8Jm5i c3A7Jm5ic3A7ICgmbmJzcDsgSW50ZXJuZXQgKUlQdjYvIElQdjYtIFw8L3NwYW4+PHNwYW4gbGFu Zz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLSYjNDM7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsgRE5TNjQgfCZuYnNwOyZuYnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8tLS0tLyZuYnNwOyBvbmx5ICZu YnNwOyZuYnNwO1w8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJz cDsmbmJzcDsgKCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyApPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3Bh biBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBgLS0tLS0nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsgQVBQ Jm5ic3A7ICZuYnNwOyZuYnNwOy88L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQi PjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1wgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Lzwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRw dCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYC0tLS0tJzwv c3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgJmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBJUHY0IHRvIElQdjYgZmxv dyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFu Zz0iRVMiPldoYXQgZGlkIG5vdCB3b3JrIHNvIGZhciBhbmQgd2hhdCBoYWQgdG8gYmUgYWRkZWQg aW4geW91ciBkcmFmdCB0byBtYWtlIHRoaXMgZmxvdyB3b3JrPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFu IGxhbmc9IkVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+SG93IGNhbiBJ UHY2LW9ubHkgQVBQIGdldCB0aGUgSVBWNCBwdWJsaWMgYWRkcmVzcywgdXNlZCBieSBOQVRfdHJh bnNsYXRvciwgd2hlbiBzZW5kaW5nIGEgcGFja2V0IGZyb20gSVB2Ni1vbnkgQVBQIHRvIElQdjQt b25seSBBUFA/IFRoaXMgSVB2NCBhZGRyZXNzIGlzIHRoZSBzYW1lIGRlc3RpbmF0aW9uIElQdjQg YWRkcmVzcyB0byB3aGljaA0KIElQdjQtb25seSBBUFAgc2VuZHMgYSBwYWNrZXQgdG93YXJkcyBJ UHY2LW9ubHkgQVBQICggMTkyLjAuMi4yLiBhZGRyZXNzIGluIEplbuKAmXMgZXhhbXBsZSkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPkR1c2FuLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxiPjxzcGFu IGxhbmc9IkVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRVMiPiB2Nm9wcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmciPnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5KT1JESSBQQUxFVCBNQVJUSU5FWjxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgOCwgMjAxOSA1OjQwIFBNPGJyPg0KPGI+VG86PC9i PiBJUHY2IE9wZXJhdGlvbnMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZv cHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gNm1hbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOjZtYW5AaWV0Zi5vcmciPjZtYW5AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3Y2b3BzXSBOQVQ2NCBpbiBSQSwgZHJhZnQtaWV0Zi02bWFuLXJhLXByZWY2NDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDozNS40cHQiPg0KPHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5J IHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFsIHBvc3NpYmxlIHNvbHV0aW9ucywgYnV0IHRoZSBzaW1w bGVyIG9uZSBzZWVtcyB0byBiZSB0aGUgZHVhbC1zdGFjayBTSVAgcHJveGllcy4gQW5vdGhlciBv bmUgaXMgZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMsIHdoaWNoIEkgZGlkbuKAmXQga25ldywgdW50 aWwgdG9kYXksIGlzIGFscmVhZHkgaW4gdGhlIElFU0cgZm9yIGFwcHJvdmFsDQogdGhpcyBUaHJ1 c2RheS48L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxh bmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QWxzbyBpdCBjYW4g YmUgZG9uZSB3aXRoIEVBTSBhbmQgYWxzbyBhcyBJIG1lbnRpb24gaW4gYSBwcmV2aW91cyBlbWFp bCB2aWEgdGhlIG9wdGltaXphdGlvbiBmb3IgNDY0WExBVC4gSnVzdCB1cGxvYWRlZCB0aGUgbmV3 IHZlcnNpb246PC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3Bh biBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f ZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEcGFsZXQtMkR2Nm9wcy0yRDQ2NHhsYXQt MkRvcHQtMkRjZG4tMkRjYWNoZXNfLTNGaW5jbHVkZS01RnRleHQtM0QxJmFtcDtkPUR3TUZhUSZh bXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJmFtcDtyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9V V0I4WUxaVTIzMDI5c01RR1Eya1kmYW1wO209V1BrN25sN29uR0RGQ0JpZFdUWGpaaVU3dHVaUTJT dnlTeWFwZ2VwamZQcyZhbXA7cz1tNWJmYnZzcEZzam42dTBjVTllbFVENi0wbktPOXp1UUUyeE1D ampLdnl3JmFtcDtlPSI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXBhbGV0LXY2b3BzLTQ2NHhsYXQtb3B0LWNkbi1jYWNoZXMvP2luY2x1 ZGVfdGV4dD0xPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJFUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjEyLjBwdDttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFy Z2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0 Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjcwLjhwdCI+PHNwYW4gbGFuZz0iRVMiPkVsIDgvNy8xOSAxOTowMSwgJnF1b3Q7djZv cHMgZW4gbm9tYnJlIGRlIERhdmlkIEZhcm1lciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmciPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IGVuIG5vbWJy ZSBkZQ0KPGEgaHJlZj0ibWFpbHRvOmZhcm1lckB1bW4uZWR1Ij5mYXJtZXJAdW1uLmVkdTwvYT4m Z3Q7IGVzY3JpYmnDszo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFu IGxhbmc9IkVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNw YW4gbGFuZz0iRVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNwYW4gbGFuZz0iRVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNwYW4gbGFuZz0iRVMiPk9uIE1v biwgSnVsIDgsIDIwMTkgYXQgMTA6NDkgQU0gTXVkcmljLCBEdXNhbiAoRHVzYW4pICZsdDs8YSBo cmVmPSJtYWlsdG86ZG11ZHJpY0BhdmF5YS5jb20iPmRtdWRyaWNAYXZheWEuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFuIGxhbmc9IkVTIj4mZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBNYW5mcmVkaSAoVVMpLCBBbGJlcnQgRSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFsYmVydC5lLm1hbmZyZWRpQGJvZWluZy5jb20iIHRhcmdldD0iX2Js YW5rIj5hbGJlcnQuZS5tYW5mcmVkaUBib2VpbmcuY29tPC9hPiZndDs8YnI+DQomZ3Q7IDxicj4N CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IGlwdjYgJmx0 OzxhIGhyZWY9Im1haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p cHY2LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhhbGYgT2YgTXVkcmljLCBEdXNhbiAo RHVzYW4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgLSBIb3cgY2FuIEROUzY0IHRlbGwgSVB2 NiBvbmx5IGNsaWVudCB0aGUgSVAgb2YgSVB2NCBvbmx5IGNsaWVudCwgYW5kIHZpY2U8YnI+DQom Z3Q7IHZlcnNhPzxicj4NCiZndDsgPGJyPg0KJmd0OyBJUHY2IHRvIElQdjQgc2hvdWxkIGJlIHN0 cmFpZ2h0Zm9yd2FyZCwgYmVjYXVzZSBpdCdzIGEgb25lLXRvLW9uZTxicj4NCiZndDsgcmVsYXRp b25zaGlwLiBUaGUgb3RoZXIgd2F5IGFyb3VuZCB3b3VsZCBub3JtYWxseSBub3Qgd29yaywgPGJy Pg0KW0R1c2FuXSBUaGVyZSBpcyBubyBzb2x1dGlvbiBmb3IgSVB2NG9ubHkgY2xpZW50IHRvIHJl YWNoIElQdjZvbmx5IGNsaWVudD8gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQi PjxzcGFuIGxhbmc9IkVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3Bh biBsYW5nPSJFUyI+SSBtb3N0bHkgc2F5LCBzbyB3aGF0ISBJdCBpcyBhbiB1bmZvcnR1bmF0ZSBy ZWFsaXR5IG9mIHRvZGF5J3MgSW50ZXJuZXQsIGJlY2F1c2Ugb2YgTkFUNDQgYW5kL29yIHN0YXRl ZnVsIGZpcmV3YWxsIGRlZmF1bHQgZGVueSBpbmJvdW5kIHBvbGljeSwgbWFueSB0aW1lcyBjbGll bnRzIGNhbid0IHNwZWFrIHRvIG90aGVyIGNsaWVudHMsDQogYmUgdGhleSBJUHY0IG9ubHksIElQ djYgb25seSwgb3IgZXZlbiBkdWFsIHN0YWNrLiBTb21ldGltZXMgZmlyZXdhbGwgdHJhdmVyc2Fs IHRlY2hub2xvZ2llcyBjYW4gd29yayBhcm91bmQgdGhpcywgYWxzbyBkZXBlbmRpbmcgb24gdGhl IGZpcmV3YWxsIHRyYXZlcnNhbCBzb2x1dGlvbiB1c2VkIHNvbWV0aW1lcyBJUHY0IG9ubHkgYW5k IElQdjYgb25seSBjbGllbnRzIHdpbGwgYmUgYWJsZSB0byB0YWxrIHRvIGVhY2ggb3RoZXIuJm5i c3A7IE15IGd1ZXNzDQogaXMgdGhhdCBJUHY0IG9ubHkgdG8gSVB2NiBvbmx5IGZpcmV3YWxsIHRy YXZlcnNhbCB3b3VsZCBiZSBsZXNzIGVmZmVjdGl2ZSB0aGFuIE5BVDQ0IGNsaWVudCB0byBOQVQ0 NCBjbGllbnQgZmlyZXdhbGwgdHJhdmVyc2FsLCBidXQgaXQgaXMgc2hvdWxkIHN0aWxsIGJlIHBv c3NpYmxlIGluIHNvbWUgY2FzZXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+ PHNwYW4gbGFuZz0iRVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3BhbiBsYW5nPSJFUyI+Jmd0 OyBidXQgZXZlcnlvbmU8YnI+DQomZ3Q7IGhhcyBiZWVuIGFjY3VzdG9tZWQgdG8gdGhhdCB3aXRo IElQdjQgTkFQVCBhbHJlYWR5LiA8YnI+DQpbRHVzYW5dIEhvdyBJUHY0IG9ubHkgdXNlcnMgKGUu Zy4gQXZheWEgSVB2NCBvbmx5IHBob25lcykgY2FuIGJlIGFjY3VzdG9tZWQgbm90IHRvIGJlIGFi bGUgdG8gY2FsbCBJUHY2b25seSB1c2VycyAobGlrZSBBcHBsZSBJUHY2IG9ubHkgcGhvbmVzKT88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNwYW4gbGFuZz0iRVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFuIGxhbmc9IkVTIj5UaGV5IG1heSBu b3QgYmUgYWJsZSB0byB0YWxrIHBlZXIgdG8gcGVlci4gSG93ZXZlciwgdGhyb3VnaCBhIGR1YWwt c3RhY2sgU0lQIG9yIG90aGVyIHByb3hpZXMvc2Vzc2lvbiBib3JkZXIgY29udHJvbGxlciwgdGhl eSBjb3VsZCBwcm9iYWJseSBjb21wbGV0ZSBhIGNhbGwuJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjcwLjhwdCI+PHNwYW4gbGFuZz0iRVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3BhbiBs YW5nPSJFUyI+Jmd0O1RoZSBjbGllbnQgYmVoaW5kIHRoZTxicj4NCiZndDsgTkFQVCBpbml0aWF0 ZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgSXMgRE5TNjQgc2VydmVyIHJldHVybmluZyBJ UHY0b255IGNsaWVudCBhZGRyZXNzIHRvIElQdjZvbmx5IGNsaWVudCwgdXNpbmc8YnI+DQomZ3Q7 IHRoZSBBIFJSPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgRE5TIHN5bnRoZXNpemVzIHRoZSBJ UHY2IGFkZHJlc3MsIHdoaWNoIGhhcyB0aGUgSVB2NCBhZGRyZXNzPGJyPg0KJmd0OyBlbWJlZGRl ZCBpbiBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAtIEhvdyBjYW4gSVB2NG9ubHkgY2xp ZW50IGdldCB0aGUgYWRkcmVzcyBvZiBJUHY2b25seSBjbGllbnQgKG9yLCBpdCBpczxicj4NCiZn dDsgaW1wb3NzaWJsZSBmb3IgSVB2NG9ubHkgY2xpZW50IHRvIGdldCBJUHY2IGFkZHJlc3Mgb2Yg SVB2Nm9ubHkgY2xpZW50KT88YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhdCdzIGNsZWFybHkgbW9y ZSBkaWZmaWN1bHQsIHdoaWNoIGlzIHdoeSB0aGUgbm9ybWFsIGNvdXJzZSBvZiBhY3Rpb24gaXMg Zm9yPGJyPg0KJmd0OyB0aGUgSVB2NiBjbGllbnQgdG8gaW5pdGlhdGUgdGhlIHNlc3Npb24uLjxi cj4NCltEdXNhbl0gV2hhdCBpZiBJUHY0b25seSBjbGllbnQgbmVlZHMgdG8gaW5pdGlhdGUgdGhl IHNlc3Npb24gdG8gSVB2Nm9ubHkgY2xpZW50PyBXaGF0IGlzIHRoZSBzb2x1dGlvbiBmb3IgdGhh dCB1c2UgY2FzZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNwYW4gbGFu Zz0iRVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFuIGxhbmc9IkVT Ij5NYW55IGZpcmV3YWxsIHRyYXZlcnNhbCBzb2x1dGlvbnMgc2hvdWxkIHdvcmsgaW4gdGhpcyBj YXNlLCBidXQgSVB2NCBvbmx5IGNsaWVudCB0byBjbGllbnQgaXNuJ3QgZ3VhcmFudGVlZCB0byB3 b3JrIGluIGFsbCBjYXNlcyBlaXRoZXIuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhw dCI+PHNwYW4gbGFuZz0iRVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3BhbiBsYW5nPSJFUyI+ Jmd0OyA8YnI+DQomZ3Q7ICZndDsgLSBEbyB0aGVzZSBJUHY0IGFuZCBJUHY2IGNsaWVudCBhZGRy ZXNzZXMgbmVlZCB0byBiZSBwcmUtY29uZmlndXJlZCBvbiB0aGU8YnI+DQomZ3Q7IHRyYW5zbGF0 b3IgYW5kL29yIEROUzY0Pzxicj4NCiZndDsgPGJyPg0KJmd0OyBGb3IgSVB2NCB0byBJUHY2LCBp ZiB5b3UgbXVzdCBhbGxvdyB0aGUgSVB2NCBjbGllbnQgdG8gaW5pdGlhdGUgdGhlIHNlc3Npb24s IHlvdSdkPGJyPg0KJmd0OyBoYXZlIHRvIGhhdmUgcHJlY29uZmlndXJlIHNvbWV0aGluZy48YnI+ DQpbRHVzYW5dIFdoZXJlIGFuZCBob3cgaXMgdGhpcyBjb25maWd1cmF0aW9uIGRvbmU/PGJyPg0K PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlcnQ8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCklF VEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpp cHY2QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQpBZG1p bmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p cHY2JmFtcDtkPUR3TUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJmFtcDtyPVVUM0Jr OWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmYW1wO209V1BrN25sN29uR0RG Q0JpZFdUWGpaaVU3dHVaUTJTdnlTeWFwZ2VwamZQcyZhbXA7cz1LNzY2ZjR3NUVtak9aaTB2ckUz NG1QUkJPaW5kbEhjZzl6bW5ZQi14ZnRzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3BhbiBsYW5nPSJFUyI+PGJy IGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFuIGxhbmc9IkVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFuIGxhbmc9IkVTIj4tLSA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcwLjhwdCI+PHNwYW4gbGFuZz0iRVMiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KRGF2aWQgRmFybWVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpFbWFpbCUzQWZh cm1lckB1bW4uZWR1IiB0YXJnZXQ9Il9ibGFuayI+DQpFbWFpbDpmYXJtZXJAdW1uLmVkdTwvYT48 YnI+DQpOZXR3b3JraW5nICZhbXA7IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzPGJyPg0KT2Zm aWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8YnI+DQpVbml2ZXJzaXR5IG9mIE1pbm5lc290 YSZuYnNwOyZuYnNwOyA8YnI+DQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFBob25lOiA2MTItNjI2LTA4MTU8YnI+DQpNaW5uZWFwb2xpcywgTU4gNTU0 MTQtMzAyOSZuYnNwOyZuYnNwOyBDZWxsOiA2MTItODEyLTk5NTI8YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcwLjhwdCI+PHNwYW4gbGFuZz0iRVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlzdA0KPGEgaHJlZj0ibWFpbHRvOnY2b3Bz QGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb192Nm9wcyZhbXA7ZD1Ed1FGYVEmYW1wO2M9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZh bXA7cj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJmFtcDttPVdQ azdubDdvbkdERkNCaWRXVFhqWmlVN3R1WlEyU3Z5U3lhcGdlcGpmUHMmYW1wO3M9T3hmcXZ6eWxt SVEwSUdja0JXZmdxNHowSnNyUER5WEJRMzRXb1FMbVZhRSZhbXA7ZT0iPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNS40cHQiPg0K PHNwYW4gbGFuZz0iRVMiPjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKio8YnI+DQpJUHY0IGlzIG92ZXI8YnI+DQpBcmUgeW91IHJlYWR5IGZvciB0aGUg bmV3IEludGVybmV0ID88YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LnRoZWlwdjZjb21wYW55LmNvbSZhbXA7ZD1Ed1FG YVEmYW1wO2M9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZhbXA7cj1VVDNCazljYkxlYUp4aGYzaUNy aElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJmFtcDttPVdQazdubDdvbkdERkNCaWRXVFhqWmlVN3R1 WlEyU3Z5U3lhcGdlcGpmUHMmYW1wO3M9RGxYYUZBUzlENGlYd0FDX0w5Y2pyM18xalZHVlhzXzI1 cm42NlR2ajdyOCZhbXA7ZT0iPmh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tPC9hPjxicj4N ClRoZSBJUHY2IENvbXBhbnk8YnI+DQo8YnI+DQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250 YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwu IFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2ls dHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9m DQogdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBp bmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwg YmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlz dHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMNCiBvZiB0aGlzIGluZm9ybWF0aW9uLCBl dmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3Ug bXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNv bW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2 Nm9wcyBtYWlsaW5nIGxpc3QNCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNA aWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmYW1w O2Q9RHdRRmFRJmFtcDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9VVQzQms5Y2JMZWFK eGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZhbXA7bT1INkx6NEphTTd1Z2w5dGk4dGs4 aGhlUVh1cUNNNDFJSnlGem9SUmlXbW1zJmFtcDtzPUNDZWVMN0gtNzdHbWlzNFhWOWNpUlN0TkRR Rm4xWk5IWHlKZVJSNGlLUVkmYW1wO2U9Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHM8L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRVMiPjxicj4N CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpJUHY0 IGlzIG92ZXI8YnI+DQpBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID88YnI+DQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0z QV9fd3d3LnRoZWlwdjZjb21wYW55LmNvbSZhbXA7ZD1Ed1FGYVEmYW1wO2M9QkZwV1F3OGJzdUtw bDFTZ2laSDY0USZhbXA7cj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdR MmtZJmFtcDttPUg2THo0SmFNN3VnbDl0aTh0azhoaGVRWHVxQ000MUlKeUZ6b1JSaVdtbXMmYW1w O3M9UmZzVjEtb0h0U2NkTUhTd1FZemNGV042R3NLNnF4bU5xMWRtbDdxOThqOCZhbXA7ZT0iPmh0 dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tPC9hPjxicj4NClRoZSBJUHY2IENvbXBhbnk8YnI+ DQo8YnI+DQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGlj aCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBp bnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykg bmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9z dXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mDQogdGhlIGNvbnRlbnRzIG9mIHRo aXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmls ZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1p bmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdh cmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0 aGUgY29udGVudHMNCiBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5j bHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNv bnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3Jp Z2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0 ZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DM6PR15MB25065EFFACD414A6F1FE6E9EBBF00DM6PR15MB2506namp_-- --_004_DM6PR15MB25065EFFACD414A6F1FE6E9EBBF00DM6PR15MB2506namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=16932; creation-date="Wed, 10 Jul 2019 14:59:10 GMT"; modification-date="Wed, 10 Jul 2019 14:59:10 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABAcAAAIECAIAAADq4tCBAAAAA3NCSVQICAjb4U/gAAAgAElEQVR4 nO3de3QUVZ7A8eoYBHdkz0ASGAQzyOMkAXkISWhwFAUBg4bAyDgSzwIuKvJwYFd0jjrnOIdFDMKu ohA9gBJegqMigSAEhh0SCIGwgEQlioo6iijDQx7KQEhq/yinpuxHdSXp6r637vfzV3V1dfWvbt2+ fX9163b7dF3XAAAAACgsId4BAD/y+XzxDgEAAEBRZAUAAACA6sgK0AAhL+fH8Ro/wwsAAABRQVYA AAAAqI6sAFGze/fuyZMnX3/99Z07d54zZ86ZM2c0TfP5fCtWrOjevXtycvL999//ySefmNtfvnx5 2bJlGRkZXbp0eemll8z1VVVVo0aNSk5O7tat22uvvaZpWn19fUlJSU5OTkZGRmFh4YULF7R/DBT4 fD5GDABx8HkEAEmRFSBqHnvssREjRuzcuXPr1q0HDx58+eWXjfXLli176aWXqqurW7Ro8eyzz5rb L1++/OWXX16yZMmyZcuKiorM9dOmTRs2bNjHH3+8du3akpISTdOKi4uffvrpJ554ori4ePPmzUuX LtU0zfj5LF3X+R0twCV08QFAHT56VHAuXBchuBZ9/vnn999//5///Gefz7dv374+ffpomvbNN9/0 7Nnz+PHjxjZ5eXkTJ04cPny4pmkbNmwYMWKEsZ++ffvefffd99xzzy9/+Utjy/z8/IkTJw4cOFDT tPfee++RRx7ZsmWLEQ8VGGiEtm3b/vWvf23evLnxcNSoUW+//bax/Pe//z01NfWDDz5ISUlpxJ75 VAKApBgrQMPoQcynPvzww/vuuy8jIyMhIeG6667buXOnsd5ICTRN+8UvfvG3v/3N3L6iosLv9xvL AwYMMNevXLny0KFDN9xwQ//+/cvLyzVN27Zt2y233GLcLNSzZ8/t27e7fJSAx/Xv33/9+vXG8qlT p9avX3/ixAnj4dtvvz1gwIDGpQQAAHmRFSBqZsyY0a1bt5KSkgsXLnz44YcXL160337AgAF79uwx lisrK831GRkZy5YtO378+NSpU6dNm6Zp2qBBg3bs2GHmIZcuXTK2TEhIqK+vd+doAC8bP3788uXL jeVdu3bV19fv2rXLeFhUVDR+/Hhj2To86PP5lixZkp6enpiYqIWZ7WMVboPgiUPhVgIAYomsAFHz zTffJCUlJSUlVVVVTZ06NeL2eXl5s2bNqqysrKysfPrpp831I0eOPHDgwA8//HD58uUWLVpomjZ+ /PhHH310y5YtZ8+e3bt374gRI4wte/TosXv3bpcOB/CwO+64Y9++fcbtfBUVFUOHDq2oqNA07ejR o9XV1XfccUfIV61evbqoqOjy5ctamNk+VuE2CJ44FG4lACCmgm8IAcIJWWHMleXl5UOGDGnZsmVG RoYxezj4JdaHly5dWrJkSVpaWqdOnQoLC82n1q5d26tXr9atW+fl5e3du1fX9fr6+k2bNt17772t WrXKzMxct26dsWVRUVF6ejrVGGiEadOmPffcc7qu33TTTbt27brxxht1XZ89e/a0adPMbawfLk3T ysvLzYdjxozZvn27sVxdXT1kyJCAl4TboE+fPgUFBZ9//rk1mJArAQCxxLQwAFDRu+++e9999+3Z s6dv377vvfdet27dDhw40KtXrzVr1vTu3dvYxjp12Ofz1dXVJST8OMLctm1b85cDNE1r1qyZcWuf +ZJwG9TU1BQUFGzYsCEtLW3OnDk333xzuJUAgFjiDiIAUJHR9S8qKurXr5+maf369VuwYEGLFi3M lCCYmRJo4Wf7RNwgeOJQuJUAFOfkx5Fj8wPKivxMM1kBmsQngHiXASCrcePGPfHEE7fccoumabfc cssf//hHc55xROFm+0TcIHjiULiViDGzORWhXRUhBkA5Mb9nCfKJdyVtvHiXHCC048ePN2vW7Msv v9R1/bPPPmvWrNnx48etG2g/nVdgfSrcbB9zs3AbBE8cCrcSMaZZ/hcy9m/qcH18iRmVhwU0QcuX L+/WrVtSUtKECRM+/vhj/af9E2Ozurq6DRs23H777enp6QsXLvzhhx/Mly9evDgtLe2KK64It7dw L1enX+Hxw0NDydjtljFmAHDbl19+mZ+f37Fjx3/913+98cYbN27caL99xKzAaEJ9Pl92dvazzz57 +vTpKEccKpjGOX/+/P/8z/+MHDkyJSWlQ4cOo0eP3rlzZ7RiQ8wEZAWDBw8uKys7evTolClTHnjg geBtdF1fu3at3+8vLy//6KOPcnNzFy5caG42aNCgyspK+73ZvNzVIxWEEgeJcDzfjfb8AQJASEeP Hv3FL36Rn5+/devW7777rqysbNiwYfYvcZIV6LpeX19fWVk5bNiwOXPmRDfmkME0zq9//eu8vLzy 8vIzZ8589tlnK1eu7NevX7RiQ8wEZAX79u0zlo8dO5aSkhK8jW7782jWX1ELt7eIv67mbUocJEz0 j3UKAYACJkyYMG7cuJBP2dxiEbAQwLp+//79PXr00INuzLh06dKKFSuys7Ozs7NXrFhx6dKlkydP Jicnnzp1ynztyZMn27RpY6wx91lbW2v82HTnzp2tv1UdLuCA9w2QnJxs3hPi8NiNvWma5iTay5cv v/nmm0OGDGnXrp15OTnczvfs2TNy5MikpKSMjIxVq1aFLFuEFJAVhHwqYH2bNm2sX+jNmjUzN6ur q4u4N5uXR+eQxKbEQaqM7q8TlBIAj+natevbb78d8qmI90g0NCuw3pjx6quv+v3+nTt37ty5Mzs7 e+nSpbquP/TQQwUFBeZrn3nmmenTpwfs85VXXrG+0PpeIQMOeN8AkydPHj58+DvvvPP99987PHZz b06iXb16dWZmZmlp6ddffz1p0iT7nfv9/pdeeunUqVM1NTVjxowJGTBCcpIVJCQkWLv799xzj/XX zyK+POBhuJcHvItX0ePxIDq4TUQBAg3Fp0M0V1111YkTJ0I+FfEeiYhZQVVVVU5OjtF11n56Y8aI ESPMCQzr16/Py8vTdb2mpiY1NbW2tlbX9dra2o4dO37xxRcB+wx4oTWGkAEHvG+A8+fPL1q0yO/3 t2jRomfPngsWLDh37pz9sZt7cxLtXXfdVVxcHPCmDfrnPjjhJCvo1atXRUWFuX7z5s1+v7+0tPTM mTNVVVW5ubn2Lw94GO7lAe/iVbTjHkEv1j2ULRRkkxtHS7wP0eO6du1q/u5TgIj3SIQ7O+ZLMjMz Z8+ebd5UY72GmpSUdPLkSWP5xIkTSUlJxnJOTs6aNWt0XV+9enV+fr51nyFfaI0hZMAB7xtOXV3d jh078vLyjD/tdnh7ScRok5OTg5OucDs/dOjQ2LFjW7Vq5ff7y8rKIsYMk+YgKzBuPDMfRvx5NPuH 4V4e8C5e5fHD8za+a2OPMof3hKvVDRLF/SAqJkyYMH78+JBPRbzFItyJCLk+YGXIsQJd10tLS/v3 76/rut/v379/f/DLc3Nz33nnHWN5w4YN1t2GDLhBteXw4cOpqanhdhW8t4jRhhwrCLdzQ21t7cqV K3v37u08bCDG+Bcz+YT89y7rSY1XYCoIV878pRok4uR/ABv6XdK4lzQuNjgxc+bM0tLSsWPH/u// /u+ZM2d27NiRk5NjPBXxH+iaIi8v77/+67927dpVUVExa9asvLw8Y/3QoUPPnj27YMGCq6+++oYb bgj5wlmzZlVWVlZWVj799NPWpxoRsN/vX7ly5ZEjR86fP19ZWfn73/9+4sSJzncVMdrRo0fPmjVr 69atx44dmzx5sn2c/EkfpNHQdhzxwukTFqcGgpPoW0CiUMX35Zdfjhkz5pe//GXLli1/9atfmVfi I95iEa6oQ64PWHnx4sWioqKsrKysrKyioqKLFy+aTy1evDghIaG0tDTkyy9durRkyZK0tLROnToF /AZRyIDt60NFRcXdd9/dvn37pKSknJycmTNnGtOOHd5eEjHa2tra119/feDAge3atSssLLSJU+dP +iAPn86lZYGFvFTGKRMZpwyCsLnQLlGF9MZRAIAUyApERM/SAziJiAubO4JiHEnUefjQYC+695JR YYBwyArEEtz2cYJkxzlFDKiWhap2vEqJ/XwSao7U3KgwylYJsgIh0HFUAWcZUUel0igET7Dv2EX3 hMbyveAG8kb3kBXEE19mauK8o4moQiFRLNIR4a4wEWKAvdgncsqmjmQF8RH8u6LxigRxRDVAQ1Fn nKCUBCdy/iZybKoRJ2ETJxK3kRXEFN9VCImKAXvUkMah3IQiV4dbrmi9RPBZQ4KH10RkBTHClxMi opIgGLWi6SjDuJP6FEgdvERkTMNkjNkeWYG7aE3QCFQbaFSDaKM8Y89jZe6xwxGENzrW3jgKjazA PTQfaCKqkJo4726jhGPAw4Xs4UOLMU+WpOwHRVYQfbLXCQiF6qQOznUsUdouUaRgFTlMl3i+9OQ9 QLKCaLLWAwoW0UXt8jbOb1xQ7FEkb0+o0RQ85CZS7RMn3fGSFUQB7QJihsrmPdJ9bXgPp6DpVC5D lY/dOZVLSaJjJytoErpoiAsqnjdI9FWhAk5H41BuBsohHErGIEU5kBU0Et0yxB2VUF5SfD2oiVPj HGUVjDKxojSCCV4mZAUNRlcMQqFCykXwrwQYOE0RmUVE+QSjcDQKwZawhUNW0AB0vyAsKqcU6GtK hJMVDiXjhMqlpPKxOydmKZEVOCXm+QOsqKXC4tRIihMXQNhrnGJSrbj4vDSUaCVGVhCZaOcMsEeN FY1qPQPv4QwaKIdGUKfQ+OppHKHKjazAjlCnCmgQaq8IOAueofipVPzwm0iF0lMn+XGJIAVIVhCa Cp9hqICaHEeCtPKIIjXPqZpHHXVeLUa+ZaJFhJIkKwgkwlkBootaHWMUuIepdnK92peNC+8VpveO KO7iW6RkBT+hWnMPdVC3Y4avSRUocpYVOcxY8lKReulYhBLHgiUr+BF9JqiAeu4qilcp3u4SUZnd 44Gy9cAhCC5eJUxWQOWGcqjzbqBUFeTVk+7thEcQ8hayvJFLJ/ZFrXpW4NU2HbBHzY8uviZV5rGz 77HDEZmMRS1jzFKLcYGrmxXQKwL4FEQFX5PwTB3wzIHIQq4Clytaz4hlsSuaFVCzARMfh0YjrYLJ A5WBpiAuZCl2WeL0pJgVvnJZgQcabiDq+Fw0At+RCCZvrZA3cg8Qv/DFj9DzYnMK1MoKqNaADT4g zlFWCEfGuiFjzB4j8ikQOTalxOBEJLi0X9H4fD6qNWDP/GhYPy8IRmMCG9bPUXwjaSjqcxwJW/g0 d+KIQduixFgBdRpoED4yNigcOCFRPTFCFT9OFYh2LiSqxupw9aR4fKyAIQKgERg0CIf2BA7JMmIg eHhqEuSk0NyJydW2xctjBVRooIn4EFlRGmgoweuM4OGpSZCTIkgYCMelE+TNrIAfVAGihU+TQbSR fUhEzMpDt09YcT81cQ8ATrhxmjx4B5G1mKjQQBNZP0eCjGvHnpi9OsjCqDlifnyo1QJilABOuPHV 7LWsgNoMuEHlxICUAE0nWmJArRZc3CsMdUMKUT9N3skKmFgMuErNKch0nhAtce/nmUSIAQ7F+GTR 4kknug2LR7IC7hoCYkC1u4n4gkR0iZAYcPlMFrFvbFVo1T0sKqfPC1kBbRwQS4okBqQEcIMIiYFG xZZELE8TXSl5RfFLWe6sgLuGgLjw/N1EpARwTxwTAyq2dGJcW6gbkorWiZM4K+CuISCOPHw3ET0n uC0uiYHHPqeqcfX00eh5QFRaFVmzAoYIABF4LzHwzIFACrGvb3xpSsftU0aj5zFNOaFSZgWkBIA4 vJQY0LYgZmL8weFisNTcG1yi0fOSprcqkmUFTCQABOSNaQa0LYgxL2XUkBqNnmc08VTKlBUwkQAQ luzTDEgJEBex+dQwUOABbgwXyNhWw6HGnVxpsgK+swHxSZoY0Lwgjtz+1Mj1YUREUT+htHse05QT KkdWwHc2IAtJEwON5gXxE4O6R/X2gOieREaQPKzRI0sSZAWkBIBc5EoM+GqECFyaTirFZxAN1fTT SsVQRENPtOhZASkBICNZEgPBw4OC3KiTfIF6RnRPJRXDwxp3cn3C1gnyAcADRP4gixwb1BTdOkkN 96Smn1YGSNXR0HMt6FgBbRngDcIOGtDIQEBu1EZquMdwQuEeEbMCvq0BLxE2MdBoZCCeaE0wEPDj huhq3ClmoEApDW1PhMsKSAkA7xEtMRAkDMBGVGop36SexGmFS8TKCkgJAK8SJzGgnYHgxPmwwGMY KFBQg4YLBMoK+KoGvE2ovg7tDETWxPpJ58/zXPopWyhOlKyAlABQQdwTA3pLkAXdPkQXrZ+ynDcm QmQFpASAOuKYGNDBgowaWm/p/CmCvBFRF/+sgJQAUE18RwxoaiAL6iqihVxRcQ5zyDhnBaQEgJpi nxjwpQgZcT0YQMzEMysgJQBUFsvEgE4VZOewDpP9KsVh0kgDCJN9ZYhbVkBKACDGIwa0NpAR9RZR QUVSnJMKEJ+sgJQAgCEGiQFXTyE77iMCEANxyApICQBYuZoY0JGCl9jXZxJgBUXMGKkVMEWsLbHO CkgJAARze8SABgeyow4DcFtMswJSAgDhuJEYMFAA76FWA3BJ7LICUgIA9lwaMaDNgTfY12RuFFGW zW0h1AoEsL+JKEZZASkBACeimBjwdQjvYdoxAPfEIisgJQDgXHz/+RgAADW5nhWQEgBoqKYnBgwU wKsYLoBDNIMIyaYNcTcrICUA0DiMGADO8TGBRjVAk8XiDiJSAgCN0Oimgytk8LZwl/qo88ri1CMq XMwK+GIG0ESNuFmCq2VQB7Ud4VA3EFFwJXErKyAlABAVjbuLmsYH3kYNhxPUE4QUrmK4lRVQEQFE l5PEgMtjUA11HkC0uHgHEYkBgKho6MxjGh+ogHoOILpi99/GANBo/CQREA637ELjJ2sRDWQFAOQQ MTGgbwTVUNsREo0hIgqZRpIVAJAGX3JAAD4UAKLFR4MCQC4hL4NxbQwATD4fHTxEEPy9yVgBAClx +ywAhENKgEYgKwAgmeAJBmQIAAA0EVkBAPmEnHnMtTEAABwKnnBMVgBAStYcgHwAAIBGsH6BMhkF AAAAUB1jBQAAAIDqyAoAAAAA1ZEVAAAAAKojKwAAAABUR1YAAAAAqI6sAAAAAFAdWQEAAACgOnez Ap/PZ/5lGssss8wyyyyzzDLLLLMs5rKLWYH5HgAAAABE5uJ/GxtZAf+dDAAAAAjOxawAAAAAgBSY bQwAAACozt15BUwtAAAAAMTHWAEAAACgOuYVAAAAAKpjrAAAAABQHfMKAAAAANVJPFbgvZTDe0cE AAAAKbiYFei6HrNJC1HpT8emU07XHwAAAKKJz1jB3LlzExMT586dG60dNi79COigxyaHsb6LSxmC zW6N27oSExOvvfba/v37FxQUnDt3zvrs7bffHlAOxt6+//775557btSoUW3atLn22mt/85vfVFRU GBscOXJk5MiRbdu27dKly6pVq6yvPXHiRGpqquCJUBTDE/xIAQAAwonDvIL6+vqXXnrpueeee/nl l+vr690LACHpul5bW7tv377nn3/+8OHD119//alTp8xnW7duvXDhwuBXjR07tqys7D//8z8/+eST HTt2jBw58pFHHtE07auvvho4cGB6enpZWdnGjRs3btxofdVTTz01adIkt48IACAXrqEAItJdE27/ JSUlffr00XU9Kytr48aN1u0XLlzYqVOnjIyMoqKi2traiOutrzUWLl++/Oabbw4ZMqRdu3YLFy40 VlZWVk6aNKl79+6dOnUqKCj47rvv9J9eDg/e4aVLl1asWJGdnZ2dnb1ixYpLly4ZGyxfvrxbt25J SUkTJkz4+OOPg4+uc+fO77//vrFcVFRkLLz//vudO3cOeJeQAYTcf8hgAgI2H9qf3OCV06ZNu//+ +81nT58+nZaWVlNTE/CS5OTkkMf77//+7w8//HDwel3XDx061Llz5wsXLrhazZouYnjO4xf8SAFA ELSWgIDi8LEcPnz4q6++quv60qVLhw8f/s9QNM3v9+/cuXPnzp39+vUztrFfb32tsbB69erMzMzS 0tKvv/560qRJxsqbbrpp06ZNp0+f/vTTT8eMGVNQUBC8h4CHr776qvmm2dnZS5cuNTYYPHhwWVnZ 0aNHp0yZ8sADDwQf3eTJkwsLC3Vd//LLL1u2bHn27Fld1xcuXDhlyhSbsM2HIfcfMhib+G1a2+Cn Pvjgg4yMDOuzf/nLXzIzMwNyj8mTJw8fPvydd975/vvvrS/v0qXLtGnTunTp0q1bt7lz5xrHaxg+ fPiqVavs4xEBWQEAxJiT1pIWFYixWH/kPv3005SUlAsXLui6fuHChZSUlCNHjvwYiqaZQwclJSV5 eXkR15u7NZfvuuuu4uJimwA+++yzwYMHB+8h4OGIESPMN12/fr3xppqm7du3z1h57NixlJSU4P0X Fxf/9re/1XW9oKAgJSVl8eLFuq7ffffd69evtwnbfBhy/yGDsYm/QVnB999//y//8i8Bzz766KOP P/64deX58+cXLVrk9/tbtGjRs2fPBQsWnDt3Ttf15s2b5+bmHjx48N133x0+fPi8efOMV23ZsiU7 O7u+vt4+nhgLOZRkDS94WMl+7KW2traoqCg9Pb1z586FhYX2u9J1va6ubsOGDbfffnt6evrChQt/ +OEHM4aVK1def/31V1999YABA6qrq9etW9e3b9/WrVtPmDDB/IzYjBpFHMUCAHGQFQACivUdRDNm zAi4henRRx81tz958qSxfPLkyaSkpIjrre9lLCQnJ584cSLgTWtqasaPH5+enm7cyNi8efPgPQQ8 TEpKMt/0xIkTxpvabG86d+5camqqrus9evQoKSkZMGCAruupqannz5+3Cdv+YchgbLZvUFbw/vvv d+vWLeDZixcv9u3bd8eOHcEvqaur27FjR15e3rRp03Rdb9eu3cGDB42nDhw40LNnT2O5R48exsvt 44mxkENJ1vBCDivZxP/KK69Yh3Ei7mrt2rV+v7+8vPyjjz7Kzc21ZiY333zztm3bjh49+rvf/a5V q1aDBw/+y1/+8vXXX//ud7978MEHjc1sRo0ijmIBQOxpDu4BdniXr9WePXtGjhyZlJSUkZFhDErb XHNZvHhxWlqapmnJycmnTp0yd3Ly5Mk2bdoYayK+/IorrnClgACRxDQrMAYHPvvsM3PNkSNHzKED TdPeeecdY/3GjRtHjBhh7ifceut7GQshxwruuOOOZ5999pNPPvn73//+4YcfmhsnJCTU1dUF70QP P1YQcIAhD/yWW255/fXXs7OzdV3Pzs5et27drbfeGvJVNgFYH4YbK0hOTj527JixvHfv3nDHZR+z tdNpfda4s+js2bMhD/Pw4cNG8nPrrbeGzAq0ICHjibGQ1SNcbOawkk3wAacm4q7GjBmzfft2Y2V1 dfWQIUPMGPbu3Wssf/PNN5qm/d///Z/50MmoUcRRLACIPc3BPcAO7/K18vv9L7300qlTp2pqasaM GaPbXnMZNGhQZWWlrusPPfSQuXNd15955pnp06cby05eDnheTPtqS5cuvfPOOwNW5uTkGLNyNU0b MGDArl27du3aNWDAgFdeeeXHEMOvN3diLq9evTorK2vLli3Wi8F9+/Z95ZVXTp8+XV5eftttt5kb 9+rVq6KiIngn+j+uAVdUVBgXZY2GzGFWUFBQ0L59+xdeeEHX9fnz53fo0GHOnDkhX2UTgPVhyGB0 XZ8wYcLUqVO//vrrsrKyW2+9Ndxxhdzn8ePH9+zZc99996WmpprXTgICmD9//rhx44yV/fr1W7Fi xaeffnru3Lldu3aNGjXq6aef1nV9zZo1d95558GDBw8ePGi9g8hJQcVeyKEka3ghh5Vs4g8Yxom4 qzZt2lgzpWbNmgXHYPOwoaNGABBfmoN7gK1s7vK16tOnT0FBweeff26usbnmUl5ebizX1NSkpqYa 4xW1tbUdO3b84osvnL8c8LyY9h4yMzPNq/6m9evXZ2Vl6f8YZ7zuuuvS09OXLFlivWc63HpzJ+Zy bW3t66+/PnDgwHbt2hmzfnVdLy8vHzJkSMuWLY0RTHNj447wkDfeXLx4saioKCsrKysrq6io6OLF i7rjvteBAwcSExOPHz+u6/q3336bmJj47rvvhnyVTQDWhyGD0XX98OHDEyZMMIZQly9fHu64Avap adoVV1zRvn17v98/e/bsM2fOhDui+vr6YcOGGSsrKiruvvvu9u3bJyUl5eTkzJw505x2PG/evOuu uy4tLW3OnDnW2cYRCyr2Io4VhBxWshl7yc3NNav0hg0bIu7qnnvuMW+sCheDzcOGzjABgPjSHNwD 7PAuX6tDhw6NHTu2VatWfr+/rKxMt73mYm3Ac3Jy1qxZo+v66tWr8/PzzfUOXw54W6znFdhv36D1 QEOFHEqyVrCQw0o2Yy9LliwxB7L8fn/EXW3evNnv95eWlp45c6aqqio3Nzc4BpuH4UaNyAoAiElz cA+ww7t8g9XW1q5cubJ3796642supaWl/fv313Xd7/fv37/fXO/w5YC3kRVAISGHkqwVLOSwks3Y y6VLl5YsWZKWltapU6eA3yAKuav6+vpNmzbde++9rVq1yszMXLduXXAMNg/DjRqRFQAQk+bgHmCH d/la5eXl7d+//8yZM0VFRX6/X3d8zUXX9e7du7/44ou33XabdaXzlwMeJlB1j1ZWoKHhonECAQD4 Cc3BPcAO7/K1Wrt2ba9evVq3bp2Xl2f8VIPDay66ri9evDghIaG0tNS60vnL0SBx7NjIIt6n6Cd8 uufOGf+j3gjeqwYAgLjz+TzYzYBzdMkiEuoDkujero2qEK+jFaqUReaNT6w3jiL2+JgAANzGd01I AnZdXMwKAACAjKLYXxGw6xNH9I8hMhezAqo+Yowq5xzf0wAAwIqxApG0z/EAACAASURBVAAAEAKX WqKIazEQX4J7u/b5fHwGAAAAAPG5mBUAAAAAkALzCgAAAADVMVYAAAAAqI55BQAAAIDqGCsAAAAA VMe8AgAAAEB1jBUAAAAAqmNeAQAAAKA6xgoAAAAA1TGvAAAAAFAdYwUAAACA6phXAAAAAKiOsQIA AABAdcwrAAAAAFTHWAEAAACgOuYVAAAAAKpjrAAAAABQHfMKAAAAANUxVgAAAACojnkFAAAAQASe 79YyVgChef4TCACAmqxf8cal5ISEhH79+s2dO/e7776L+PITJ06kpqbGsp/g+XvjXcwKdF33fPHB bbquM+gEAIDn6bpeV1c3f/78bdu2LVq0KOL2Tz311KRJk2IQmDoYK4AcyA0AAELhWynqfD6f3+9/ 5plnXnjhhZSUlNOnT5tPnTp1qm3btuaampqa0tLS//iP/wi3q6qqqlGjRiUnJ3fr1u21114zVtbX 15eUlOTk5GRkZBQWFl64cMF83yVLlqSnp/t8Ppv3Nc94XV3dW2+9NXTo0GuuuaawsNB+5xJhXgFE Zx1xolIBAASh8mi22wfeunXr0aNHW0cMFi1alJ+f36pVK+PhjBkzZs6c2aJFi3B7mDZt2rBhwz7+ +OO1a9eWlJQYK4uLi59++uknnniiuLh48+bNS5cuNbdfvXp1UVGRruv272t44403CgoKZsyYsW/f vvfffz/izqWhu8bt/Yv2vpKSpbjsq64sRyEOSgyADZoIh5x3qDxWpA4P3H4D61PmclVVVU5OTkFB QU1NTWpqam1tra7rtbW1HTt2/OKLL4xttmzZkp2dXV9fH7ATqz59+hQUFHz++efWlWPGjNm+fbux XF1dPWTIEPPdy8vLjWWb9zXf66677iouLg54x3A7tzl80aoE8wogK2Wv0AAABKGrOpodfOBNP3Zj J5MnT77pppsefPDB9PT07t27v/XWW5qmvfnmmwMGDEhNTTW2fOSRR/77v//b/h1Xrlx56NChG264 oX///uXl5cbKbdu23XLLLcYb9ezZc/v27eb2N954o7Fg876msrIyc3uTzc6loQflapqm+Xy+7Ozs Z5999vTp0xETi7/97W/XXnutJky6Yx4XnIhXxXNDvMtSJpQYABs0EQ3i5PvIk0Ua8bvY/qi1UGMF VqWlpf3799d13e/379+/3+Z9w71FbW3typUre/fubTy85557duzYYR+J/fsaCyHHCsLtPBwBq0SI sQI9SnPAlUqaAQAADCp3gaI1dKBp2tChQ8+ePbtgwYKrr776hhtuMNdbO7JamB8MHTly5IEDB374 4YfLly+b0w/Gjx//6KOPbtmy5ezZs3v37h0xYkSD3tc0evToWbNmbd269dixY5MnT27QzoWmh8/V 9u/f3759++Tk5FOnTpkrT5482aZNG3PNoUOHOnfubMyzDkg4zP3HWLzeV1ISFVccPh7RE+/CCyRm VAAEIVETEb923SlrnFIEHHU25y7kstXixYsTEhJKS0ud7MRq7dq1vXr1at26dV5e3t69e42V9fX1 mzZtuvfee1u1apWZmblu3bpwOwn5vuZmtbW1r7/++sCBA9u1a1dYWGi/c5vIbQonLny6rvt8Pt1y 75C5fODAgXHjxt14440dO3b8/e9/b6wsKCj49ttvn3vuOePhHXfcce+99+bn51tfGF9GeipIMOKT pbhkv+giWgnLct4BxIVETYRc3w5GpyveUcSIebBSVKTYE7BwwmYFe/fufeqppwYOHJiXlzds2LBP P/00MTHx8uXLXbt2LSsrMyZebN269Q9/+MPu3buNoSJBDkzAUhaZLMUV3IxaYxb5KMSMTcyoAAhC oiZCkFBt+vpGbILEGXUhD9zaq9S8eNRRIWDhhJhXEK054CrfVIfoCqhIxjhXvIIBAMAqXG/H899W IS/YefuQvc3uDiLTli1b/vjHP+7atat///6FhYXmxAsxL98KmHuJTPzislazcHGKfBRixiZmVAAE IVETIUKo9t0h6zZSFKlzwdfsQm7gsaOOFgELx9H/FTRuDjj5IqKI6gQAEJCyo9kB1+wUOWpvS3S4 3fTp0ydOnLhp0yZXowECiDNfBQCAAE5Gsz3JPHCljtrzXOxycQeRFLxRXCIfhZixiRkVAEFI1ETE N1Tn7y5RkTrh8HA8dtTRJWDhOB0rAAAAgEnZ0WxlD9zzXMwKqDEAAMCrlO3nKHvgnudotjEAAAAA D3MxK+D/CgAAAAApMFYAAAAAqI55BQAAAIDqGCsAAAAAVMe8AgAAAEB1jBUAAAAAqmNeAQAAAKA6 xgoAAAAA1TGvAAAAAFAdYwUAAACA6phXAAAAAKiOsQIAAABAdcwrAAAAAFTHWAEAAACgOuYVAAAA AKpjrAAAAABQHfMKAAAAANUxVgAAAACozrPzChimAAAAABxirAAAAABQnYtjBcbV+tiPGPDbRwAA AECDMFYAAAAAqM6z8woAAAAAOORiVgAAAADF8QMwsuD/CgAAAADVMVYAAACA6ONmcrkwrwAAAABQ Hb9BBAAAAKiOeQUAAACA6hgrAAAAAFTHvAIAAABAdYwVAAAAAKpjXgEAAACgOsYKAAAAANUxrwAA AABQHWMFAAAAgOqYVwAAAACojrECAAAAQHXMKwAAAABUx1gBAAAAoDrmFQAAAACqY6wAAAAAUB3z CgAAAADVMVYAAAAAqI55BQAAAIDqGCsAAAAAVMe8AgAAAEB1jBUAAAAAqmNeAQAAAKA6xgoAAAAA 1TGvAAAAAFCdi1mBpmnGHURGesAyy+4toynEOY8ss8yyOMtwgzjnl2WWg5e5gwgAAABQnc9IDgCp WTNd0YgZm5hRARCERE2ELKHKEidUxlgBAAAAoDqyAgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACq IysAAAAAVEdWAAAAAKiOrAAAAABQHVkBAAAAoDqyAgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACq IysAAAAAVEdWAESZz+fz+XxN2QAAACDGEuMdAOBNRr9f1/XglQAAAKJhrACIMmsmYKYBAeMDAdkC AABAfJEVAAAAAKojKwCiz34ogIECAAAgGrICAAAAQHVkBYArwg0IMFAAAAAERFYAAAAAqI6sAHBL 8LAAAwUAAEBMZAUAAACA6sgKABdZBwcYKAAAAMIiKwAAAABUlxjvAID4sP7TsGfekeEIAADQOGQF AAAgymJ85SU2b8eVF3gbWQGU5pkmPvZDHwAAwEvICgAAgCu48gJIhNnGAAAAgOrICgAAAADVkRUA AAAAqiMrAAAAAFRHVgAAAACojqwAAAAAUB1ZAQAAAKA6sgIAAABAdWQFAAAAgOrICgAAAADVkRUA AAAAqiMrAAAAAFRHVgAAAACojqwAAAAAUB1ZAQAAAKA6sgIAAABAdWQFAAAAgOrICgAAAADVkRUA AAAAqiMrAAAAAFRHVgAAAACojqwAAAAAUB1ZAQAAAKA6sgLgJ3w+3+23367resBK+5fY7/PEiROp qakRN7N35MiRkSNHtm3btkuXLqtWrWrKrgAgLqLewEaxYYxKQw1IjawACNS6deuFCxdGcYdPPfXU pEmTbDbo3bv3888/f/z48XAbfPXVVwMHDkxPTy8rK9u4cePGjRujGB4AxEwUG1iHDWPEBtYQsaEG PM8XkLIDMjKu7jSoMod7ic/nO336tN/vX7duXXp6urnS2HL37t3Lly8vLy+/cOHCgw8++NBDD/38 5z83XxsygJqamtzc3Pfff/+qq64KF+G2bduWLVu2fv36m2++edy4cbm5uVdeeaV1gwkTJvzsZz97 4YUXGno40doegFKa3kSE3EN0G9iIDaMhYgOrOWioXSoQQCiMFQCBfv7zn7/88sv/9m//VltbG/DU Y489NmLEiJ07d27duvXgwYMvv/yy0cTruh6urZ8xY8bMmTNbtGhh846DBw9evnz5V1999etf/3rB ggXXXHPNlClT9uzZY25QXl6ekJDQtWvX7t27z5s379y5c00+SgCIgyg2sA4bxogNrOasoQY8j7EC eEF0xwqMlY899lhiYuLs2bOtK60+//zz+++//89//nPIZw1bt279wx/+sHv3bp/PZ7NZgB07duTn 53/11Vfm9i1atBg6dOisWbN0XX/iiScGDRr0yCOPODmccLhqBcCGe2MFUWxgIzaMIQU3sE4aasYK oAQdkF8jKnO4l5grL1682Ldv3x07dlhX1tTUjB8/Pj093Wjfmzdvbn02WI8ePYw9BG8W/Bk8d+5c UVHRrbfempSUNGnSpN27d5tPtWvX7uDBg8bygQMHevbs6fBwwuHjD8BG05uIkHuIbgNr0zA2qIG1 aajtD6dBaHUhPu4gAkK78sorly9f/uCDD1pHpWfMmNGtW7eSkpILFy58+OGHFy9e1DQtISGhvr4+ 5E7ee++9m266ybj+pP30xzTMD6Gmadu2bRs3blyHDh3efPPNyZMnHz16tLCwsF+/fubG5g24AOAB UWlgbRrGBjWwNg01oBSyAiCsbt26PfTQQw8//LC55ptvvklKSkpKSqqqqpo6daqxskePHrt37w65 B2sKroUfO37kkUd69+59+PDhDRs2jB49unnz5gEbTJw48cknn6yurq6urn7yySfHjh0bhcMDgPhp egPrsGGM2MA6bKgB73N3KAKIiUZU5nAvCVhZX18/bNgwc2V5efmQIUNatmyZkZFRVFRkrC8qKjIu WUV8xwZFGGDevHnXXXddWlranDlzzp49G7zzBu2fjz8AG01vIkLuIeoNrH3D2Liww613o0AAoTDb GF4QxdnGkmK2MYAoYnJtAAoEKuAOIgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACqIysAAAAAVEdW AAAAAKiOrAAAAABQHVkBAAAAoDqyAgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACqIysAAAAAVEdW AAAAAKiOrAAAAABQHVkBAAAAoDqyAgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACqIysAAAAAVEdW AAAAAKiOrAAAAABQHVkBAAAAoDqyAgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACqIysAAAAAVEdW AAAAAKiOrAAAAABQHVkBAAAAoLrEeAcAxJPP54t3CAAAAPFHVgAAAFzBlRdAImQFUJSu6zF7L+N7 MZbvCAAA0CBkBQAAIMpidh3E5/NxzQWICmYbAwAAKRkjsdynBEQFWQEAAACgOrICAAAgH+sQAcMF QNORFQAAAACqIysAAACSCR4cYLgAaCKyAgAAAEB1ZAUAAEAm4YYFGC4AmoKsAAAAAFAdWQEAAJCG /YAAwwVAo7mbFfh8PvPzyTLLbi+jcUQ4dyyzzLJQy5pUJPpvY0HOL8ssh1x2MSsw3wMAAKDpzK6F ruvWZMD6kO4H0Dg+9zJs42MpUQYPeQle2QQMT8CQAIhD2CYiILDgOGWJHBBQonu7puoDAIBo8fki X8o0NnCyJYAAzDYGAAAScN7RJyUAGsHdeQXc2wcAAACIj7ECAAAAQHXMKwAAAABUx1gBAAAAoDrm FQAAAACqY6wAAAAAUB3zCgAAAADVMVYAAAAAqI55BQAAAIDqGCsAAAAAVMe8AgCAnYefX9DQl7w4 faobkQAA3OOj7w4PMO5VE7YyCxiegCFBECFzgAb18gP2QIYgI1maCFni1KQKFcpyMSvgA4CYEbyy CRiegCEh7szefBT78WQIkpKliZAlTk2qUKEssgJ4geCVTcDwBAwJ8WLtuLvaaydDkIgsTYQscWpS hQplcQcRvEDw1lbA8AQMCbFndNPj0jt3Y1wCUSRLEyFLnJpUoUJZZAXwAsFbWwHDEzAkxJIgnfI4 piWwJ0sTIUucmlShQlncQQQvELyyCRiegCEhZkTri4sWDzR5mghZ4tSkChXKIiuAFwhe2QQMT8CQ EAPC9r+FDUxZsjQRssSpSRUqlMUdRPACwVtbAcMTMCS4Tfyet/gRqkOWJkKWODWpQoWyyArgBYK3 tgKGJ2BIcI9EvW2JQvU2WZoIWeLUpAoVyuIOIniB4JVNwPAEDAkukbGfLWPMHiNLEyFLnJpUoUJZ ZAXwAsErm4DhCRgSok7qvrXUwXuALE2ELHFqUoUKZXEHEbxA8NZWwPAEDAnR5Y1e9cPPL5D9ECQl SxMhS5yaVKFCWQnxDgAAEGVGZ9ob/emAf0QGALjExazA5/MZmTEAIGa81I32RmIDAFJgrAAAvMZL nekXp0/1Up4DAMJiXgG8QPD7NQUMT8CQVOa81xuxu+/VG/G9elzCkqWJkCVOTapQoazEeAcAAIoy kwHn/d2A/CHghd7uOptHFzKJ8vCBA0Bs8Muk8ALBK5uA4QkYkjoakQzY7MfciTd+dCiYkxyAPCHq ZGkiZIlTkypUKIusAF4geGUTMDwBQ1JE1C/nWzvE3usHNzrViVbqpSxZmghZ4tSkChXKYl4BvEDw 1lbA8AQMydti0En19u1DjUZ60DiyNBGyxKlJFSqURVYALxC8tRUwPAFD8rCY9de9ehNRVJAeNIgs TYQscWpShQplcQcRvEDwyiZgeAKG5FUxvoRPYmCP8nFIliZCljg1qUKFssgK4AWCVzYBwxMwJO+h AyosTk1EsjQRssSpSRUqlMUdRPACwVtbAcMTMCSPod8pPmZi2JCliZAlTk2qUKEssgJ4geCtrYDh CRiSl9DdlAVnKhwpmggpgjTJFS3UlODern0+n/EZAAB10NGUyIvTpzr/Y2kA8DYXswIAUA1dTOmQ GACAwcWsQNd1RsoAqIaBAumQGACAxlgBAEQL9w7Ji8QAAJhXAAAAAKiOsQIAiAKuNMuO4QIAimNe AQBEB7cPyY7EAIDKGCsAgKZiRgEAQHbMKwCAJiEl8BiGCwCoibECAAB+RIIHQFmJ7u2aSQUAAACA FBgrAIDG4/YhAIA3MK8AAIB/4peIAKiJsQIAAABAdcwrAAAAAFTHWAEANBL3mQAAPIN5BQDQeEw1 BgB4A2MFAAAAgOqYVwAAAACojrECAAD+if+gAKAm5hUAAAAAqmOsAAAAAFAd8woAAPgRvzYLQFmM FQAA8E9MKgCgJuYVAACgacwzBqA2xgoAoJHoQXoJ9w4BUBzzCgCgwaw9SHIDz+BUAlCZi1kBAHiM mQzQffQYBgoAwOfeFX1jUgEjBogBwSubgOEJGJLgjF4jyYCHcYqtpGgipAjSJFe0UBNZAbxA8Mom YHgChiQyJqGqg9zAIEUTIUWQJrmihZpczAqAmBG8tRUwPAFDEhN9RDVx3qVoIqQI0iRXtFATv0EE AHZU7hoqyzjpTDYAoBTuIIIXCF7ZBAxPwJAExI1DULYOSNFESBGkSa5ooSbGCgAgBGW7gwjggRED /lEUgBMuZgW6rpMTA3GkeFegKYdPSgCDN6qBrus+n0/xBgFARIwVAJ6leFeg0YdPSgCrF6dP9cBw gUHlBgFARC5mBbQ+gCAU/zAqfvhoOg8kBtahez4RAEJirADwMsW7Ao04fA8PFLh39q17FrmOiRxb DATc06tggwDAXoIW1KD7fL6EhIR+/frNnTv3u+++s3/9kSNHRo4c2bZt2y5duqxatcr6FPMKABEo 3hVo0OF7OCVA08k+XBCSag0CABshxgp0Xa+rq5s/f/62bdsWLVpk8+Kvvvpq4MCB6enpZWVlGzdu 3Lhxo2txAkDUxKwn5NI1FxWI1lU10kWf5MIdnc2z8Q3YnlsnG1BV6DuIfD6f3+9/5plnXnjhhZSU lNOnT5tPnTp1qm3btsaap556atSoUQUFBenp6Wlpaa+99lrATvjQAiIIN2oX1y/02AlXLAHPxmCg gGsuEJn95wWA50WYV9C6devRo0dbv70WLVqUn5/fqlUrTdPKy8sTEhK6du3avXv3efPmnTt3zt1g AQmZ37Jx6xTzTW8rxuXji8Y1F0Ntbe3KlSv79evXr1+/lStX1tbWmm+xYsWK7t27Jycn33///Z98 8knAC2+++eY1a9aYD//6179ec801Z86csW5TV1f31ltvDR069JprriksLDRW1tfXl5SU5OTkZGRk FBYWXrhwoUEHHjKqkPs0zoh5arp06fLBBx8Y2y9btsxY+OCDD7p06RKxKJYsWZKenp6YmGgNZt++ fR06dJg/f77z+DVNe3H61KnPvahLzuYAQ24Q32idaNBJBGDH+ERZP13GQlVVVU5OTkFBQU1NTWpq am1tra7rtbW1HTt2/OKLL4xtmjdvnpube/DgwXfffXf48OHz5s2LeWsA6Po/vhXiHUVo8fx4OxPv EooFJ4fvRodPC9W66rq+f//+Hj16PPTQQwUFBebKZ555Zvr06cZyly5dpk2b1qVLl27dus2dO/fs 2bPBO3/11Vf9fv/OnTt37tyZnZ29dOlS840GDx5cVlZ29OjRKVOmPPDAAwEBbN68OSMjo66uzng4 YcIEaxiG1atXZ2ZmlpaWfv3115MmTTJWrl271u/3l5eXf/TRR7m5uQsXLrQ/zICiCBmVk31Onjy5 sLBQ1/Uvv/yyZcuWRmksXLhwypQpEYti0KBBlZWV1n1u2LAhJSVl3bp1IeO0J3tW4LwRUKdxiBmK FOILkRUYMjMzZ8+eferUKV3Xc3Jy1qxZo+v66tWr8/PzzY3btWt38OBBY/nAgQM9e/aMaezAP9Da 2lM5H9CdHb5Lvb2Q3eVoXXMZMWLExo0bjeX169fn5eWZb7Rv3z5j+dixYykpKcHBZGVlrVq1Stf1 w4cPd+jQ4fvvvw/Y+V133VVcXBywcsyYMdu3bzeWq6urhwwZYnOYwUURMion+ywuLv7tb3+r63pB QUFKSsrixYt1Xb/77rvXr18fsSjKy8utMSxYsOCaa66pqqoKGWRE3ssK7LeMZWyeR5FCfGHHCqxK S0v79++v67rf79+/f7+5/tZbb7XJCvgAIGaobPbICiIeeGyyAkO0rrkkJSWdPHnSWD5x4kRSUlLw m1ofWtevW7cuLS3t8uXLY8aMeeGFF4J3npycfOLEiYCVbdq0sRZjs2bNQh5mxKKwPnSyz3PnzqWm puq63qNHj5KSkgEDBui6npqaev78+YhFYQ6JGA87der0+OOPh4zQCamzggZ9/JVqImKDIoX4HP1f wdChQ8+ePbtgwYKrr776hhtuMNdPnDjxySefrK6urq6ufvLJJ8eOHetkbwBiKeCmeeOTH69gYk+o wzfefe/evY8//rgxO2v69OnG3e3z58+fMWOGuWV6enrEvd144427d+82lnft2vWrX/3KeSQjRoy4 8sorH3/88crKyokTJwZvMHDgwIqKioCVgwYN2rFjh/n9cenSJefvGE64fSYkJNTX1xvLV199dadO nf70pz9dddVVd9xxx+XLl4uLizt37vyzn/3M2MCmKBISfvI1V1ZW9sYbb8ydO7fpkcvF+kFQrREA 4JTu7DLP4sWLExISSktLA9bPmzfvuuuuS0tLmzNnTsg7X4EYMCszAgR82APWxyuqmAl3+MFieQdR gO7du7/44ou33XabdeWaNWvuvPPOgwcPHjx4MNwdRK+88orf76+oqDBupn/11VdDvpEWaqzAeAtN 05YsWRIyqtWrV2dlZW3ZssU6r2Dz5s1+v7+0tPTMmTNVVVW5ubnODzNcVOH22atXr4qKCnP7goKC 9u3bG8Ma8+fP79Chw5w5cxpXFEePHk1LS5s9e3bIOO3JO1bQ0I+8Ik1ELFGkEB8VFF5AaxtOuJJR pMScH2Ycs4JGX3O5ePFiUVFRVlZWVlZWUVHRxYsXQ75RuKzgjTfe6Nq1qzGrIVhtbe3rr78+cODA du3aGTN9dV2vr6/ftGnTvffe26pVq8zMTHPCblOygnD7LCoqMgZMjIcHDhxITEw8fvy4ruvffvtt YmLiu+++2+iiOHbsWEZGxsyZM0OGakPSrKARH3ZFmohYokghPp/u2jCiMV7p3v4BE5UtJJ8v7Adc hRKzOfwAav6lcW5ubn5+/pgxY+IdiEzUqSoqNBExRpFCfImRNwEgJ8W/fhQ/fBuXL19esGDB6dOn 77nnnnjHAgAQhYtZAV/JACCgZs2a9enTZ/ny5fy9HQDAxFgBAKiFSzYAgGCOfpm0ccw/qwcAQHbq TCoAoCYXswIAAAAAUnAxKzB+5Mi9/QNAtDz8/IJ4hwChUUMAeB5jBQBUx20hcIJ6AsDbmFcAAAAA qI6xAgAA7DDPGIAK+L8CAADCIiUAoAjGCgBAe3H6VKaTIhgpAQB1MK8AAIAQSAkAKIWxAgAAAEB1 zCsAAAAAVMdYAQBoGlMLAABqY14BAPyIxAAAoCzGCgAACI0sEYA6XMwKdF1nagEAuTBcABM/QARA KYwVAAAAAKpjXgG8wwfH4n2uhMZwAQBAQYwVAEAgEgMAgGr4vwJ4AZUNUWcmBtxcDgBQAWMFABAa +QAAQB3MKwCAsIwRA+4mAgB4HmMFAGDnxelTmWYAAPA85hUAAIAQGPAHlMJYAQAAAKA6F8cKjGsM jBgAACAXvrsBBTFWAACRMbVAQZxxAEphXgEAAKHx67QA1MFYAQAAAKA6/q8AAAAAUB1jBQDgCFML AAAexrwCAAAAQHWMFQAAEIhxIQCqYV4BADjFTURK4QeIACiFsQIAAABAdS5mBbquM7UAgMcwXAAA 8CTGCgCgwUgMvI3zC0BBzCsAgIbhdnMVcJYBqIaxAgAA/omBAgBqYl4BADQYswu8jYECAApirAAA GoPEAADgJcwrAIBGIjHwHk4oAGUxVgAAjWckBnQlvYTbhwCoiXkFANAkRicyZokBGYh7KFsAKmOs AACa6sXpU7mbyBsYKACgLOYVAEB0kBhI7eHnF5ASAFBZYrwDAADvsCYGdDElQjoHAD5u/QcANxgd zajnBi7tVnEMFAAAWQEAuMV6BToqnc6o7xAaKQEAaJrm6h1EtNevtQAAAcRJREFUxqQCsg4AyjL7 mtZfL21QBzTgzhbrDqMRIChJAPgR8woAwHUh04OGvhZWUbyTihIGAI07iABAUorf9xKVw1e8DAHA iv8rAABZKXv3S9N788agDSkBAJj4vwIAkJKyPdqopASawgUIACExVgAAslLwf9OafrxGUkFKAAAB mFcAAHJT6sp3UwYKlCooAGgosgIAkJ4K/d0mHqMKRQQATeFiVsD/FQBAzHi719uUo/N2yQBAtJAV AIBHePJHdcw+fUM79/wPNAA0CHcQAYB3eOy6eMDhhJxqbDxr8xQAwAmyAgDwFLN/LHWf2GF6w4AA AEQLdxABgAfJO2jgjawGAKRDVgAAniVdbiBdwADgGdxBBABeJsuld/IBAIgvsgIA8L6AybhCdb5l yVsAwNu4gwgA1CJOL1ycSAAAZAUAoKJ4jR6IPGoBACrjDiIAUJ3b1+zJBABAfGQFAABNC/NHYFoD O/H8mxgASIo7iAAAYYVLFWyQAwCAjMgKAAAAANVxBxEAAACguoR4BwAAAAAgzhLd27VxB5H2j5uI rDcUscwyyyyzzDLLLLPMMsviLLs4VmC8AQAAAADBMa8AAAAAUN3/A8aFGW7TM9pHAAAAAElFTkSu QmCC --_004_DM6PR15MB25065EFFACD414A6F1FE6E9EBBF00DM6PR15MB2506namp_-- From nobody Wed Jul 10 09:26:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0306912027F for ; Wed, 10 Jul 2019 09:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=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=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 n8Q6L5M5c_rj for ; Wed, 10 Jul 2019 09:26:02 -0700 (PDT) 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 3EB82120187 for ; Wed, 10 Jul 2019 09:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562775956; x=1563380756; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=LuDRTtgkuyzhKw9gr+PAqMnAfyTCWtwv5R l2EPYz/ZA=; b=kICX0bgHvqHCEgErCzfcLat24doGkqsJ/IHVmJpQ3RQ81WBVWp 81pdR/8S7mvf1Hg/NjS55iKGYUsgUtuMLX4cM9hPCPTy6ZrCIancxZ5pjxRlvGlJ IW7wISLVgrepRbXXjhJnJvsqujUwWzCnb0MQos+epTxfdAL5P/0Xco3ZQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 10 Jul 2019 18:25:56 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 10 Jul 2019 18:25:54 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006321590.msg for ; Wed, 10 Jul 2019 18:25:53 +0200 X-MDRemoteIP: 2001:470:1f09:495:d491:2afc:e0ba:a59f X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 10 Jul 2019 18:25:53 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1094617358=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Wed, 10 Jul 2019 18:25:51 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3645627951_2109962198" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 16:26:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3645627951_2109962198 Content-type: multipart/alternative; boundary="B_3645627951_441077661" --B_3645627951_441077661 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Dusan, =20 Responding below in-line (removed 6man). =20 Regards, Jordi @jordipalet =20 =20 =20 El 10/7/19 16:59, "Mudric, Dusan (Dusan)" escribi=C3=B3= : =20 Hi Jordi, =20 I changed the thread title since we are now discussing draft-palet-v6ops-46= 4xlat-opt-cdn-caches solution. =20 When DNS64 translator in this figure https://en.wikipedia.org/wiki/IPv6_tra= nsition_mechanism#/media/File:NAT64.svg sends a packet to 192.0.2.1, the pa= cket has the source IPv4 address of DNS64. How can DNS server be configured= to return that address during h2.example.com resolution? =20 I guess you mean the NAT64, because the DNS64 is not the translator. =20 The query for h2.example.com will return 192.0.2.1. The DNS64 in turn will = synthetize 64:ff9b::c000:200 and return that to the host that want to talk = to 192.0.2.1, so when this communication flow actually starts, will use the= NAT64 translator. =20 Please find more comments and questions inlined. =20 Thanks, Dusan. =20 From: JORDI PALET MARTINEZ =20 Sent: Tuesday, July 9, 2019 4:24 PM To: Mudric, Dusan (Dusan) ; IPv6 Operations Cc: 6man <6man@ietf.org> Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 =20 Hi Dusan, =20 The problem is that the IPv6-only =E2=80=9Cremote server=E2=80=9D don=E2=80= =99t have IPv4 connectivity. Also, it doesn=E2=80=99t have an IPv4 address.= Let=E2=80=99s suppose this is a streaming server. =20 The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is an IPv= 4-only SmartTV), is connected to a CLAT (this is in the CPE, and the CPE is= connected via IPv6-only) to the service provider. =20 The optimization that we are suggesting is using EAM (explicit mapping) to = avoid the IPv4 flow from the smartTV to be converted back to IPv4, because = the CLAT already converted it to IPv6. =20 If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming server, the= CLAT will create an EAMT, so because it believes the streaming service is = reachable with IPv4 (which is not), but the =E2=80=9Coptimized CLAT=E2=80= =9D will then use the AAAA. =20 So, the flow is: IPv4 from the smartTV to the CLAT IPv6 from the CLAT to the streaming service [Dusan] This is a different solution that addresses a different use case: I= Pv4-only client accessing IPv6-only =E2=80=9Cremote server=E2=80=9D in IPv6= only network. IPv6-only server does not need PLAT (btw, found a nice diagr= am that depicts CLAT-PLAT https://sites.google.com/site/tmoipv6/464xlat ) =20 =C3=A8 Yes, as explained already, 464XLAT was meant to allow IPv4-only de= vices to use NAT64 (the PLAT), by means of the CLAT daemon. The optimizatio= n is to avoid a double translation if the destination is already dual-stack= . =20 =20 In normal conditions, if the streaming service is really dual-stack=20 [Dusan] Need to be more specific. Is the streaming =E2=80=9Cremote server= =E2=80=9D server supporting dual stack and is in a dual stack network? Is t= he access network IPv6-only? =20 =C3=A8 Never mind, in our optimization, the streaming is dual-stack and a= ttached with dual-stack. The idea is to avoid a dual-translation. =20 and we don=E2=80=99t have optimization (the =E2=80=9Cactual=E2=80=9D 464XLA= T protocol), it will be: =20 IPv4 from the smartTV to the CLAT IPv6 from the CLAT to the NAT64 IPv4 from the NAT64 to the streaming service [Dusan] If the IPv4-ony client is streaming over IPv6-only network to a dua= l stack =E2=80=9Cremote server=E2=80=9D in a dual stack network,=20 =20 =C3=A8 Again. Yes, the optimization was originally designed to allow IPv4= -only devices to avoid dual-translation if the destination service is alrea= dy IPv6 enables. To work without the optimization needs to be dual-stack, j= ust think in a CDN (they are today dual-stack, typically). But then we disc= overed that this will actually work as well even if the CDN is IPv6-only bu= t has an A record (even if it is a fake one). =20 =C2=B7 IPv6 from the CLAT to the NAT64 =C2=B7 IPv4 from the NAT64 to the streaming service is not needed. IPv6 access network can directly send IPv6 packets over dual= stack network to the dual stack =E2=80=9Cremote server=E2=80=9D. =20 =C3=A8 NO. Without the optimization, the flow is forced to be as I=E2=80= =99ve described, because the NAT64 prefix will force the path to the NAT64.= Unless you go for approach 1 in the document but then this will only work = if 1) the CDN interfaces have NAT64 WKP addresses (and that means they are = =E2=80=9Clocally=E2=80=9D connected, because it is non routable in Internet= ), or 2), an NSP prefix is used and the CDN is configured with them. =20 If the streaming service is IPv6 only, with the actual 464XLAT protocol, th= is connectivity is not possible. [Dusan] If the streaming service is IPv6 only, meaning the IPv6 only =E2=80= =9Cremote server=E2=80=9D is in IPv6-only network, after IPv4-to-IPv6 CLAT = translation the packets from IPv4-only host will be able to reach the IPv6 = only =E2=80=9Cremote server=E2=80=9D. =20 =C3=A8 No, read my previous explanation, because the NAT64 prefix disallo= ws that. =20 You see the point? [Dusan] Not yet. Please see the comments above. =20 =C3=A8 I=E2=80=99ve the feeling that you still didn=E2=80=99t understand = how NAT64 works. You need to understand that before getting here! =20 Please take a look at the document, I think is well described, otherwise pr= ovide suggestions about what you believe is not clear enough and we will ma= ke sure to improve the text and drawings! =20 By the way, I=E2=80=99m talking here about =E2=80=9Capproach 2=E2=80=9D, wh= ich I think is the best solution. [Dusan] Sorry, I am not able to get the main ideas from draft-palet-v6ops-4= 64xlat-opt-cdn-caches. I expect if there are: - A diagram explaining the problem(s) with call flows,=20 - Depicted components and where they are (on which devices ), and - Glossary with definitions it will be easier to grasp the ideas. [Dusan] Section 4.2.2 is not clear. Why DNS proxy resolver needs to do addi= tional AAAA query? Why is this DNS response needed by CLAT? [Dusan] Section 4.2.3 goes into details and it is not clear which problem n= eeds to be solved and what the solution is. I cannot follow these details b= ecause I don=E2=80=99t know what they are for. [Dusan] Section 4.2.4: my understanding is that EMT table is in CPE router = (should be described in the document where which components are and should = be a glossary for acronyms, defining function blocks) . Probably A and AAAA= resolutions are stored on the router and when IPv4 packet, destined to A-r= esolved IP, comes to CPE, destination IPv4 address will be mapped to IPv6 a= ddress from AAAA resolution. This should be explained and flow diagram prov= ided. =20 Question: So far I can see how this will work if everything is statically c= onfigured. Based on Jen=E2=80=99s call flow: =20 =C3=A8 Exactly, SIIT-DC means some static configuration at the server sid= e for the EAMT entries for each host. And this forces the double translatio= n and then a new translation at the SIIT-DC border relay. Our optimization = avoids this multiple translation and create in the CE the EAMT entries auto= matically. =20 =E2=80=9CThe owner would create a DNS A RR for ipv6-only.example.net. - le= t's say, 192.0.2.2 Ipv6-only server would have an IPv6 address which has th= at IPv4 address encoded - for example, 2001:db8:1::192.0.2.2 That IPv4 addr= ess (or the prefix most likely) will be routed to the translator.=E2=80=9D the IPv6-only =E2=80=9Cremote server=E2=80=9D is configured to have 2001:db= 8:1::192.0.2.2 and IPv4 packets from IPv4-only client, destined to 192.0.2.= 2, will be routed to CPE translator (I guess because all devices behind the= translator have to be in the same subnet). What if the IPv6-only hosts (or= the remote server in this example) use SLAAC? How is this going to work? =20 =20 =C3=A8 You need to first understand very well NAT64, then 464XLAT, then y= ou will catch it. =20 Regards, Jordi @jordipalet =20 =20 =20 El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: =20 Hi Jordi, =20 Are you saying your draft =E2=80=9C464XLAT Optimization=E2=80=9D will prov= ide IPv4only app to IPv6only app communication like this? =20 =20 +-------+ .-----. =20 | IPv6 | / \ =20 .-----. | CE | / IPv6- \ .-----. =20 / IPv4- \ | or +--( only )---( NAT64 ) / only \ | UE | \ Access /\ `-----' =20 ( SmartTV )--+ | \ / \ =20 \ STB / | with | `--+--' \ .-----. =20 \ VoIP / | NAT46 | | \ / \ `-----' | CLAT | +---+----+ / IPv6 \ .--+--. | | | DNS/ | ( Internet )IPv6/ IPv6- \ +-------+ | DNS64 | \ /----/ only \ +--------+ \ / ( ) `-----' \ APP / \ / `-----' <------------------------ IPv4 to IPv6 flow ------------------------> =20 What did not work so far and what had to be added in your draft to make thi= s flow work? =20 How can IPv6-only APP get the IPV4 public address, used by NAT_translator, = when sending a packet from IPv6-ony APP to IPv4-only APP? This IPv4 address= is the same destination IPv4 address to which IPv4-only APP sends a packet= towards IPv6-only APP ( 192.0.2.2. address in Jen=E2=80=99s example). =20 Thanks, Dusan. =20 From: v6ops On Behalf Of JORDI PALET MARTINEZ Sent: Monday, July 8, 2019 5:40 PM To: IPv6 Operations Cc: 6man <6man@ietf.org> Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64 =20 I think there are several possible solutions, but the simpler one seems to = be the dual-stack SIP proxies. Another one is draft-ietf-tram-turnbis, whic= h I didn=E2=80=99t knew, until today, is already in the IESG for approval t= his Thrusday. Also it can be done with EAM and also as I mention in a previous email via = the optimization for 464XLAT. Just uploaded the new version: =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?= include_text=3D1 =20 =20 =20 =20 =20 El 8/7/19 19:01, "v6ops en nombre de David Farmer" escribi=C3=B3: =20 =20 =20 On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) w= rote: > -----Original Message----- > From: Manfredi (US), Albert E >=20 > -----Original Message----- > From: ipv6 On Behalf Of Mudric, Dusan (Dusan) >=20 > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and v= ice > versa? >=20 > IPv6 to IPv4 should be straightforward, because it's a one-to-one > relationship. The other way around would normally not work,=20 [Dusan] There is no solution for IPv4only client to reach IPv6only client?= =20 =20 I mostly say, so what! It is an unfortunate reality of today's Internet, be= cause of NAT44 and/or stateful firewall default deny inbound policy, many t= imes clients can't speak to other clients, be they IPv4 only, IPv6 only, or= even dual stack. Sometimes firewall traversal technologies can work around= this, also depending on the firewall traversal solution used sometimes IPv= 4 only and IPv6 only clients will be able to talk to each other. My guess = is that IPv4 only to IPv6 only firewall traversal would be less effective t= han NAT44 client to NAT44 client firewall traversal, but it is should still= be possible in some cases.=20 =20 > but everyone > has been accustomed to that with IPv4 NAPT already.=20 [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed= not to be able to call IPv6only users (like Apple IPv6 only phones)? =20 They may not be able to talk peer to peer. However, through a dual-stack SI= P or other proxies/session border controller, they could probably complete = a call.=20 =20 >The client behind the > NAPT initiates. >=20 > > Is DNS64 server returning IPv4ony client address to IPv6only client, us= ing > the A RR? >=20 > The DNS synthesizes the IPv6 address, which has the IPv4 address > embedded in it. >=20 > > - How can IPv4only client get the address of IPv6only client (or, it is > impossible for IPv4only client to get IPv6 address of IPv6only client)? >=20 > That's clearly more difficult, which is why the normal course of action i= s for > the IPv6 client to initiate the session.. [Dusan] What if IPv4only client needs to initiate the session to IPv6only c= lient? What is the solution for that use case? =20 Many firewall traversal solutions should work in this case, but IPv4 only c= lient to client isn't guaranteed to work in all cases either.=20 =20 >=20 > > - Do these IPv4 and IPv6 client addresses need to be pre-configured on = the > translator and/or DNS64? >=20 > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the sessi= on, you'd > have to have preconfigure something. [Dusan] Where and how is this configuration done? >=20 > Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. ********************************************** 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. --B_3645627951_441077661 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Dusan,=

 

Responding below in-line (removed 6man).

 

Regards,

=

Jordi

@jordipalet

 

<= o:p> 

 

<= div>
<= p class=3DMsoNormal style=3D'margin-left:35.4pt'> 

Hi Jordi,

=

 

I changed the thread title si= nce we are now discussing draft-palet-v6ops-464xlat-opt-cdn-caches solution.

 

When DNS64 translator in this figure https://en.wikipedia.o= rg/wiki/IPv6_transition_mechanism#/media/File:NAT64.svg sends a packet = to 192.0.2.1, the packet has the source IPv4 address of DNS64. How can DNS = server be configured to return that address during h2.example.com resolutio= n?

&nb= sp;

I guess you mean the NAT64, because the DNS64 is not the translator.

 

The query for h2.example.com will return 19= 2.0.2.1. The DNS64 in turn will synthetize 64:ff9b::c000:200 and return tha= t to the host that want to talk to 192.0.2.1, so when this communication fl= ow actually starts, will use the NAT64 translator.

 

Please= find more comments and questions inlined.

 

Thanks,

Dusan.

 

From: JORDI PALET MARTINEZ <= ;jordi.palet@consulintel.es>
Sent: Tuesday, July 9, 2019 4:24= PM
To: Mudric, Dusan (Dusan) <dmudric@avaya.com>; IPv6 Ope= rations <v6ops@ietf.org>
Cc: 6man <6man@ietf.org>
Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-r= a-pref64

 

Hi Dusan,

 

The problem is that the IPv6-only = =E2=80=9Cremote server=E2=80=9D don=E2=80=99t have IPv4 connectivity. Also,= it doesn=E2=80=99t have an IPv4 address. Let=E2=80=99s suppose this is a s= treaming server.

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>The =E2=80=9Clocal=E2=80=9D IPv4-only host (let=E2=80=99s suppose is= an IPv4-only SmartTV), is connected to a CLAT (this is in the CPE, and the= CPE is connected via IPv6-only) to the service provider.=

 

The optimization that we ar= e suggesting is using EAM (explicit mapping) to avoid the IPv4 flow from th= e smartTV to be converted back to IPv4, because the CLAT already converted = it to IPv6.

 

If we create a =E2=80=9Cfake=E2=80=9D A record in the streaming server, t= he CLAT will create an EAMT, so because it believes the streaming service i= s reachable with IPv4 (which is not), but the =E2=80=9Coptimized CLAT=E2=80= =9D will then use the AAAA.

 =

So, the flow is:

IPv4 from t= he smartTV to the CLAT

IPv6 from the CLAT to t= he streaming service

[Dusan] This is a different solution that addresses = a different use case: IPv4-only client accessing IPv6-only =E2=80=9Cremote = server=E2=80=9D in IPv6 only network. IPv6-only server does not need PLAT (= btw, found a nice diagram that depicts CLAT-PLAT https://sites.google.com/site/tmoipv6/464xl= at )

 

=C3=A8   Yes, as explained already, 464XLAT was meant to allow IP= v4-only devices to use NAT64 (the PLAT), by means of the CLAT daemon. The o= ptimization is to avoid a double translation if the destination is already = dual-stack.

 

3D"http://dan.drown.org/android/clat/Clat-=

=  

In nor= mal conditions, if the streaming service is really dual-stack <= /o:p>

[Dusan] Need to be more specific. Is the streaming =E2=80=9Cremo= te server=E2=80=9D server supporting dual stack and is in a dual stack netw= ork? Is the access network IPv6-only?

 

=C3=A8   Never mind, in our optimiz= ation, the streaming is dual-stack and attached with dual-stack. The idea i= s to avoid a dual-translation.

 

and we don=E2=80=99t have optimization (the =E2=80=9Cactu= al=E2=80=9D 464XLAT protocol), it will be:

 

IPv4 from the smartTV to the CLAT<= /p>

IPv6 from the CLAT to the NAT64

IPv= 4 from the NAT64 to the streaming service

[Dusan] If the IPv4-ony client = is streaming over IPv6-only network to a dual stack =E2=80=9Cremote server= =E2=80=9D in a dual stack network,

 

=C3=A8   Again. Yes, the optimizati= on was originally designed to allow IPv4-only devices to avoid dual-transla= tion if the destination service is already IPv6 enables. To work without th= e optimization needs to be dual-stack, just think in a CDN (they are today = dual-stack, typically). But then we discovered that this will actually work= as well even if the CDN is IPv6-only but has an A record (even if it is a = fake one).

 

=C2=B7 &n= bsp;       IPv6 from the CLAT to the NAT64

=C2=B7         IPv4 from the = NAT64 to the streaming service

is not needed. IPv6 access network can dir= ectly send IPv6 packets over dual stack network to the dual stack =E2=80=9C= remote server=E2=80=9D.

 

=C3= =A8   NO. Without the optimization, the flow is force= d to be as I=E2=80=99ve described, because the NAT64 prefix will force the = path to the NAT64. Unless you go for approach 1 in the document but then th= is will only work if 1) the CDN interfaces have NAT64 WKP addresses (and th= at means they are =E2=80=9Clocally=E2=80=9D connected, because it is non ro= utable in Internet), or 2), an NSP prefix is used and the CDN is configured= with them.

 

If the streaming service is IPv6 o= nly, with the actual 464XLAT protocol, this connectivity is not possible.

[Dusan] If the streaming service is IPv6 only, meaning the IPv6 only =E2= =80=9Cremote server=E2=80=9D is in IPv6-only network, after IPv4-to-IPv6 CL= AT translation the packets from IPv4-only host will be able to reach the IP= v6 only =E2=80=9Cremote server=E2=80=9D.

 

=C3=A8 &nb= sp; No, read my previous explanation, because the NAT64 prefix disallows = that.

 

You see the point?

=

[Dusan] Not yet. Pl= ease see the comments above.

 

=C3=A8   I=E2=80= =99ve the feeling that you still didn=E2=80=99t understand how NAT64 works.= You need to understand that before getting here!

 

Please take a look at the document, I think is well described, otherwis= e provide suggestions about what you believe is not clear enough and we wil= l make sure to improve the text and drawings!

=  

By the way, I=E2=80=99m talking here ab= out =E2=80=9Capproach 2=E2=80=9D, which I think is the best solution.

[Du= san] Sorry, I am not able to get the main ideas from draft-palet-v6ops-464x= lat-opt-cdn-caches. I expect if there are:

-     &n= bsp;    A diagram explaining t= he problem(s) with call flows,

-&nb= sp;         Depicted components and where they are (on which devices ), and<= /b>

- =          Glossary with definitions

it will be easier to grasp the ideas.<= /b>

[= Dusan] Section 4.2.2 is not clear. Why DNS proxy resolver needs to do addit= ional AAAA query? Why is this DNS response needed by CLAT?

[Dusan] Section 4.2.3 goes into details and it= is not clear which problem needs to be solved and what the solution is. I = cannot follow these details because I don=E2=80=99t know what they are for.=

[Dusan] Section 4.2.4: my understanding is that EMT table is in CPE rou= ter (should be described in the document where which components are and sho= uld be a glossary for acronyms, defining function blocks) . Probably A and = AAAA resolutions are stored on the router and when IPv4 packet, destined to= A-resolved IP, comes to CPE, destination IPv4 address will be mapped to IP= v6 address from AAAA resolution. This should be explained and flow diagram = provided.

 

Question: So far I can see how this will work if eve= rything is statically configured. Based on Jen=E2=80=99s call flow:

&= nbsp;

=C3=A8  = Exactly, SIIT-DC means some static configuration at the server side for = the EAMT entries for each host. And this forces the double translation and = then a new translation at the SIIT-DC border relay. Our optimization avoids= this multiple translation and create in the CE the EAMT entries automatica= lly.

 =

=E2=80=9CThe owner= would create a DNS A RR for  ipv6-only.example.net. - let's say, 192.= 0.2.2 Ipv6-only server would have an IPv6 address which has that IPv4 addre= ss encoded - for example, 2001:db8:1::192.0.2.2 That IPv4 address (or the p= refix most likely) will be routed to the translator.=E2=80=9D

the IPv6-only =E2= =80=9Cremote server=E2=80=9D is configured to have 2001:db8:1::192.0.2.2 an= d IPv4 packets from IPv4-only client, destined to 192.0.2.2, will be routed= to CPE translator (I guess because all devices behind the translator have = to be in the same subnet). What if the IPv6-only hosts (or the remote serve= r in this example) use SLAAC? How is this going to work?=

 

=

 

=C3=A8   You need to first understand very well NAT64, then 464XLAT,= then you will catch it.

<= span lang=3DEN-US> 

Rega= rds,

Jordi

@jordipa= let

 

=  

 

<= p class=3DMsoNormal style=3D'margin-left:70.8pt'>El 9/7/19 22:05, "v6o= ps en nombre de Mudric, Dusan (Dusan)" <v6ops-bounces@ietf.org en nombre de dmudric@avaya.com> escribi=C3=B3:

 =

Hi Jordi,=

 

Are you saying= your draft  =E2=80=9C464XLAT Opti= mization=E2=80=9D will provide IPv4only app to IPv6only app communication like this?

 <= /p>

 

        &= nbsp;         +-------+  =    .-----.         &= nbsp;        

      &nbs= p;           | IPv6&= nbsp; |    /       \ &nbs= p;            &= nbsp;

  &= nbsp;   .-----.     |  CE &nbs= p; |   /  IPv6-  \     .-----. = ;  

 = ;    / IPv4- \    |  or  = +--(   only    )---( NAT64 )

    /  only &nb= sp; \   |  UE   |   \  Access /\&nb= sp;   `-----'    

   (  SmartTV  )--+&n= bsp;      |    \   &= nbsp;   /  \        =     

    \=    STB   /   | with  |   =   `--+--'    \   .-----.   &nb= sp; 

 &nb= sp;   \ VoIP  /    | NAT46 |  =       |        = \ /       \

      `-----'  &nb= sp;  | CLAT  |    +---+----+    /&n= bsp; IPv6   \      .--+--.

     &nb= sp;            |&nbs= p;      |    |  DNS/  |&n= bsp;  (  Internet )IPv6/ IPv6- \

        &nbs= p;         +-------+  &nb= sp; |  DNS64 |    \      =    /----/  only   \

        &= nbsp;           &nbs= p;          +--------+ &n= bsp;   \       /    = (           )=

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    `-----'      \  APP = ;   /

&nbs= p;            &= nbsp;            &nb= sp;            =             &nb= sp;         \   &nbs= p;   /

   <-= ----------------------- IPv4 to IPv6 flow ------------------------>

 

What did not= work so far and what had to be added in your draft to make this flow work?=

 

How can IPv6-only APP get the IPV4 public address, = used by NAT_translator, when sending a packet from IPv6-ony APP to IPv4-onl= y APP? This IPv4 address is the same destination IPv4 address to which IPv4= -only APP sends a packet towards IPv6-only APP ( 192.0.2.2. address in Jen= =E2=80=99s example).

 

Thanks,

Dusan.

&= nbsp;

From: v6ops <v6ops-bounces@ietf.org> On Behalf Of JORDI PALET MARTIN= EZ
Sent: Monday, July 8, 2019 5:40 PM
To: IPv6 Operatio= ns <v6ops@ietf.org>
Cc: 6man <6man@ietf.org>
Su= bject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64

 <= /o:p>

I think there are several possible solutions, but the simpler one seems = to be the dual-stack SIP proxies. Another one is draft-ietf-tram-turnbis, w= hich I didn=E2=80=99t knew, until today, is already in the IESG for approva= l this Thrusday.

<= span style=3D'font-size:12.0pt;color:black'>Also it can be done with EAM an= d also as I mention in a previous email via the optimization for 464XLAT. J= ust uploaded the new version:

 =

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn= -caches/?include_text=3D1

 =

 

 <= /p>

 

 

=

El 8/7/19 19:0= 1, "v6ops en nombre de David Farmer" <v6ops-bounces@ietf.org en nombre de farmer@umn.edu> escribi=C3=B3:

=

 

=  

 

On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) <dmudric@avay= a.com> wrote:

> -----Original Message-----
> From= : Manfredi (US), Albert E <albert.e.manfredi@boeing.com>
>
> = -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf O= f Mudric, Dusan (Dusan)
>
> > - How can DNS64 tell IPv6 onl= y client the IP of IPv4 only client, and vice
> versa?
>
&g= t; IPv6 to IPv4 should be straightforward, because it's a one-to-one
>= ; relationship. The other way around would normally not work,
[Dusan] T= here is no solution for IPv4only client to reach IPv6only client?

=  

I mostly say, so what! It is an unfortunate reality of today's Inte= rnet, because of NAT44 and/or stateful firewall default deny inbound policy= , many times clients can't speak to other clients, be they IPv4 only, IPv6 = only, or even dual stack. Sometimes firewall traversal technologies can wor= k around this, also depending on the firewall traversal solution used somet= imes IPv4 only and IPv6 only clients will be able to talk to each other.&nb= sp; My guess is that IPv4 only to IPv6 only firewall traversal would be les= s effective than NAT44 client to NAT44 client firewall traversal, but it is= should still be possible in some cases. 

 

=

> but e= veryone
> has been accustomed to that with IPv4 NAPT already.
[Du= san] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed no= t to be able to call IPv6only users (like Apple IPv6 only phones)?

=  

They may not be able to talk peer to peer. However, through a dual-= stack SIP or other proxies/session border controller, they could probably c= omplete a call. 

 

>The client behind the
>= ; NAPT initiates.
>
> > Is DNS64 server returning IPv4ony c= lient address to IPv6only client, using
> the A RR?
>
> = The DNS synthesizes the IPv6 address, which has the IPv4 address
> em= bedded in it.
>
> > - How can IPv4only client get the addre= ss of IPv6only client (or, it is
> impossible for IPv4only client to = get IPv6 address of IPv6only client)?
>
> That's clearly more = difficult, which is why the normal course of action is for
> the IPv6= client to initiate the session..
[Dusan] What if IPv4only client needs = to initiate the session to IPv6only client? What is the solution for that u= se case?

 

Many firewall traversal solutions should work in t= his case, but IPv4 only client to client isn't guaranteed to work in all ca= ses either. 

 

>
> > - Do these IPv4 and IPv6 client addresses need to be = pre-configured on the
> translator and/or DNS64?
>
> For= IPv4 to IPv6, if you must allow the IPv4 client to initiate the session, y= ou'd
> have to have preconfigure something.
[Dusan] Where and how = is this configuration done?

>
> Bert

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


=

 

--

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farme= r               Email:farmer@umn.edu
Networ= king & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota  
2218 University Ave SE  &nbs= p;     Phone: 612-626-0815
Minneapolis, MN 55414-3029 &nb= sp; Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

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


****************************************= ******
IPv4 is over
Are you ready for the new Internet ?
http://= www.theipv6company.com
The IPv6 Company

This electronic messa= ge contains information which may be privileged or confidential. The inform= ation is intended to be for the exclusive use of the individual(s) named ab= ove and further non-explicilty authorized disclosure, copying, distribution= or use of the contents of this information, even if partially, including a= ttached files, is strictly prohibited and will be considered a criminal off= ense. If you are not the intended recipient be aware that any disclosure, c= opying, distribution or use of the contents of this information, even if pa= rtially, including attached files, is strictly prohibited, will be consider= ed a criminal offense, so you must reply to the original sender to inform a= bout this communication and delete it.

_________________________________________= ______ v6ops mailing list v6ops@ietf.org<= /a> https://www.ietf= .org/mailman/listinfo/v6ops


**********************************************
IPv4 is ove= r
Are you ready for the new Internet ?
http://www.theipv6company.com<= /a>
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-exp= licilty authorized disclosure, copying, distribution or use of the contents= of this information, even if partially, including attached files, is stric= tly prohibited and will be considered a criminal offense. If you are not th= e intended recipient be aware that any disclosure, copying, distribution or= use of the contents of this information, even if partially, including atta= ched 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.


*****************************= *****************
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.

--B_3645627951_441077661-- --B_3645627951_2109962198 Content-type: image/png; name="image001.png"; x-mac-creator="4F50494D"; x-mac-type="504E4766" Content-ID: Content-disposition: inline; filename="image001.png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAABAcAAAIECAIAAADq4tCBAAAAA3NCSVQICAjb4U/gAAAgAElE QVR4nO3de3QUVZ7A8eoYBHdkz0ASGAQzyOMkAXkISWhwFAUBg4bAyDgSzwIuKvJwYFd0jjrn OIdFDMKuohA9gBJegqMigSAEhh0SCIGwgEQlioo6iijDQx7KQEhq/yinpuxHdSXp6r637vfz V3V1dfWvbt2+fX9163b7dF3XAAAAACgsId4BAD/y+XzxDgEAAEBRZAUAAACA6sgK0AAhL+fH 8Ro/wwsAAABRQVYAAAAAqI6sAFGze/fuyZMnX3/99Z07d54zZ86ZM2c0TfP5fCtWrOjevXty cvL999//ySefmNtfvnx52bJlGRkZXbp0eemll8z1VVVVo0aNSk5O7tat22uvvaZpWn19fUlJ SU5OTkZGRmFh4YULF7R/DBT4fD5GDABx8HkEAEmRFSBqHnvssREjRuzcuXPr1q0HDx58+eWX jfXLli176aWXqqurW7Ro8eyzz5rbL1++/OWXX16yZMmyZcuKiorM9dOmTRs2bNjHH3+8du3a kpISTdOKi4uffvrpJ554ori4ePPmzUuXLtU0zfj5LF3X+R0twCV08QFAHT56VHAuXBchuBZ9 /vnn999//5///Gefz7dv374+ffpomvbNN9/07Nnz+PHjxjZ5eXkTJ04cPny4pmkbNmwYMWKE sZ++ffvefffd99xzzy9/+Utjy/z8/IkTJw4cOFDTtPfee++RRx7ZsmWLEQ8VGGiEtm3b/vWv f23evLnxcNSoUW+//bax/Pe//z01NfWDDz5ISUlpxJ75VAKApBgrQMPoQcynPvzww/vuuy8j IyMhIeG6667buXOnsd5ICTRN+8UvfvG3v/3N3L6iosLv9xvLAwYMMNevXLny0KFDN9xwQ//+ /cvLyzVN27Zt2y233GLcLNSzZ8/t27e7fJSAx/Xv33/9+vXG8qlTp9avX3/ixAnj4dtvvz1g wIDGpQQAAHmRFSBqZsyY0a1bt5KSkgsXLnz44YcXL160337AgAF79uwxlisrK831GRkZy5Yt O378+NSpU6dNm6Zp2qBBg3bs2GHmIZcuXTK2TEhIqK+vd+doAC8bP3788uXLjeVdu3bV19fv 2rXLeFhUVDR+/Hhj2To86PP5lixZkp6enpiYqIWZ7WMVboPgiUPhVgIAYomsAFHzzTffJCUl JSUlVVVVTZ06NeL2eXl5s2bNqqysrKysfPrpp831I0eOPHDgwA8//HD58uUWLVpomjZ+/PhH H310y5YtZ8+e3bt374gRI4wte/TosXv3bpcOB/CwO+64Y9++fcbtfBUVFUOHDq2oqNA07ejR o9XV1XfccUfIV61evbqoqOjy5ctamNk+VuE2CJ44FG4lACCmgm8IAcIJWWHMleXl5UOGDGnZ smVGRoYxezj4JdaHly5dWrJkSVpaWqdOnQoLC82n1q5d26tXr9atW+fl5e3du1fX9fr6+k2b Nt17772tWrXKzMxct26dsWVRUVF6ejrVGGiEadOmPffcc7qu33TTTbt27brxxht1XZ89e/a0 adPMbawfLk3TysvLzYdjxozZvn27sVxdXT1kyJCAl4TboE+fPgUFBZ9//rk1mJArAQCxxLQw AFDRu+++e9999+3Zs6dv377vvfdet27dDhw40KtXrzVr1vTu3dvYxjp12Ofz1dXVJST8OMLc tm1b85cDNE1r1qyZcWuf+ZJwG9TU1BQUFGzYsCEtLW3OnDk333xzuJUAgFjiDiIAUJHR9S8q KurXr5+maf369VuwYEGLFi3MlCCYmRJo4Wf7RNwgeOJQuJUAFOfkx5Fj8wPKivxMM1kBmsQn gHiXASCrcePGPfHEE7fccoumabfccssf//hHc55xROFm+0TcIHjiULiViDGzORWhXRUhBkA5 Mb9nCfKJdyVtvHiXHCC048ePN2vW7Msvv9R1/bPPPmvWrNnx48etG2g/nVdgfSrcbB9zs3Ab BE8cCrcSMaZZ/hcy9m/qcH18iRmVhwU0QcuXL+/WrVtSUtKECRM+/vhj/af9E2Ozurq6DRs2 3H777enp6QsXLvzhhx/Mly9evDgtLe2KK64It7dwL1enX+Hxw0NDydjtljFmAHDbl19+mZ+f 37Fjx3/913+98cYbN27caL99xKzAaEJ9Pl92dvazzz57+vTpKEccKpjGOX/+/P/8z/+MHDky JSWlQ4cOo0eP3rlzZ7RiQ8wEZAWDBw8uKys7evTolClTHnjggeBtdF1fu3at3+8vLy//6KOP cnNzFy5caG42aNCgyspK+73ZvNzVIxWEEgeJcDzfjfb8AQJASEePHv3FL36Rn5+/devW7777 rqysbNiwYfYvcZIV6LpeX19fWVk5bNiwOXPmRDfmkME0zq9//eu8vLzy8vIzZ8589tlnK1eu 7NevX7RiQ8wEZAX79u0zlo8dO5aSkhK8jW7782jWX1ELt7eIv67mbUocJEz0j3UKAYACJkyY MG7cuJBP2dxiEbAQwLp+//79PXr00INuzLh06dKKFSuys7Ozs7NXrFhx6dKlkydPJicnnzp1 ynztyZMn27RpY6wx91lbW2v82HTnzp2tv1UdLuCA9w2QnJxs3hPi8NiNvWma5iTay5cvv/nm m0OGDGnXrp15OTnczvfs2TNy5MikpKSMjIxVq1aFLFuEFJAVhHwqYH2bNm2sX+jNmjUzN6ur q4u4N5uXR+eQxKbEQaqM7q8TlBIAj+natevbb78d8qmI90g0NCuw3pjx6quv+v3+nTt37ty5 Mzs7e+nSpbquP/TQQwUFBeZrn3nmmenTpwfs85VXXrG+0PpeIQMOeN8AkydPHj58+DvvvPP9 9987PHZzb06iXb16dWZmZmlp6ddffz1p0iT7nfv9/pdeeunUqVM1NTVjxowJGTBCcpIVJCQk WLv799xzj/XXzyK+POBhuJcHvItX0ePxIDq4TUQBAg3Fp0M0V1111YkTJ0I+FfEeiYhZQVVV VU5OjtF11n56Y8aIESPMCQzr16/Py8vTdb2mpiY1NbW2tlbX9dra2o4dO37xxRcB+wx4oTWG kAEHvG+A8+fPL1q0yO/3t2jRomfPngsWLDh37pz9sZt7cxLtXXfdVVxcHPCmDfrnPjjhJCvo 1atXRUWFuX7z5s1+v7+0tPTMmTNVVVW5ubn2Lw94GO7lAe/iVbTjHkEv1j2ULRRkkxtHS7wP 0eO6du1q/u5TgIj3SIQ7O+ZLMjMzZ8+ebd5UY72GmpSUdPLkSWP5xIkTSUlJxnJOTs6aNWt0 XV+9enV+fr51nyFfaI0hZMAB7xtOXV3djh078vLyjD/tdnh7ScRok5OTg5OucDs/dOjQ2LFj W7Vq5ff7y8rKIsYMk+YgKzBuPDMfRvx5NPuH4V4e8C5e5fHD8za+a2OPMof3hKvVDRLF/SAq JkyYMH78+JBPRbzFItyJCLk+YGXIsQJd10tLS/v376/rut/v379/f/DLc3Nz33nnHWN5w4YN 1t2GDLhBteXw4cOpqanhdhW8t4jRhhwrCLdzQ21t7cqVK3v37u08bCDG+Bcz+YT89y7rSY1X YCoIV878pRok4uR/ABv6XdK4lzQuNjgxc+bM0tLSsWPH/u///u+ZM2d27NiRk5NjPBXxH+ia Ii8v77/+67927dpVUVExa9asvLw8Y/3QoUPPnj27YMGCq6+++oYbbgj5wlmzZlVWVlZWVj79 9NPWpxoRsN/vX7ly5ZEjR86fP19ZWfn73/9+4sSJzncVMdrRo0fPmjVr69atx44dmzx5sn2c /EkfpNHQdhzxwukTFqcGgpPoW0CiUMX35Zdfjhkz5pe//GXLli1/9atfmVfiI95iEa6oQ64P WHnx4sWioqKsrKysrKyioqKLFy+aTy1evDghIaG0tDTkyy9durRkyZK0tLROnToF/AZRyIDt 60NFRcXdd9/dvn37pKSknJycmTNnGtOOHd5eEjHa2tra119/feDAge3atSssLLSJU+dP+iAP n86lZYGFvFTGKRMZpwyCsLnQLlGF9MZRAIAUyApERM/SAziJiAubO4JiHEnUefjQYC+695JR YYBwyArEEtz2cYJkxzlFDKiWhap2vEqJ/XwSao7U3KgwylYJsgIh0HFUAWcZUUel0igET7Dv 2EX3hMbyveAG8kb3kBXEE19mauK8o4moQiFRLNIR4a4wEWKAvdgncsqmjmQF8RH8u6LxigRx RDVAQ1FnnKCUBCdy/iZybKoRJ2ETJxK3kRXEFN9VCImKAXvUkMah3IQiV4dbrmi9RPBZQ4KH 10RkBTHClxMiopIgGLWi6SjDuJP6FEgdvERkTMNkjNkeWYG7aE3QCFQbaFSDaKM8Y89jZe6x wxGENzrW3jgKjazAPTQfaCKqkJo4726jhGPAw4Xs4UOLMU+WpOwHRVYQfbLXCQiF6qQOznUs UdouUaRgFTlMl3i+9OQ9QLKCaLLWAwoW0UXt8jbOb1xQ7FEkb0+o0RQ85CZS7RMn3fGSFUQB 7QJihsrmPdJ9bXgPp6DpVC5DlY/dOZVLSaJjJytoErpoiAsqnjdI9FWhAk5H41BuBsohHErG IEU5kBU0Et0yxB2VUF5SfD2oiVPjHGUVjDKxojSCCV4mZAUNRlcMQqFCykXwrwQYOE0RmUVE +QSjcDQKwZawhUNW0AB0vyAsKqcU6GtKhJMVDiXjhMqlpPKxOydmKZEVOCXm+QOsqKXC4tRI ihMXQNhrnGJSrbj4vDSUaCVGVhCZaOcMsEeNFY1qPQPv4QwaKIdGUKfQ+OppHKHKjazAjlCn CmgQaq8IOAueofipVPzwm0iF0lMn+XGJIAVIVhCaCp9hqICaHEeCtPKIIjXPqZpHHXVeLUa+ ZaJFhJIkKwgkwlkBootaHWMUuIepdnK92peNC+8VpveOKO7iW6RkBT+hWnMPdVC3Y4avSRUo cpYVOcxY8lKReulYhBLHgiUr+BF9JqiAeu4qilcp3u4SUZnd44Gy9cAhCC5eJUxWQOWGcqjz bqBUFeTVk+7thEcQ8hayvJFLJ/ZFrXpW4NU2HbBHzY8uviZV5rGz77HDEZmMRS1jzFKLcYGr mxXQKwL4FEQFX5PwTB3wzIHIQq4Clytaz4hlsSuaFVCzARMfh0YjrYLJA5WBpiAuZCl2WeL0 pJgVvnJZgQcabiDq+Fw0At+RCCZvrZA3cg8Qv/DFj9DzYnMK1MoKqNaADT4gzlFWCEfGuiFj zB4j8ikQOTalxOBEJLi0X9H4fD6qNWDP/GhYPy8IRmMCG9bPUXwjaSjqcxwJW/g0d+KIQdui xFgBdRpoED4yNigcOCFRPTFCFT9OFYh2LiSqxupw9aR4fKyAIQKgERg0CIf2BA7JMmIgeHhq EuSk0NyJydW2xctjBVRooIn4EFlRGmgoweuM4OGpSZCTIkgYCMelE+TNrIAfVAGihU+TQbSR fUhEzMpDt09YcT81cQ8ATrhxmjx4B5G1mKjQQBNZP0eCjGvHnpi9OsjCqDlifnyo1QJilABO uPHV7LWsgNoMuEHlxICUAE0nWmJArRZc3CsMdUMKUT9N3skKmFgMuErNKch0nhAtce/nmUSI AQ7F+GTR4kknug2LR7IC7hoCYkC1u4n4gkR0iZAYcPlMFrFvbFVo1T0sKqfPC1kBbRwQS4ok BqQEcIMIiYFGxZZELE8TXSl5RfFLWe6sgLuGgLjw/N1EpARwTxwTAyq2dGJcW6gbkorWiZM4 K+CuISCOPHw3ET0nuC0uiYHHPqeqcfX00eh5QFRaFVmzAoYIABF4LzHwzIFACrGvb3xpSsft U0aj5zFNOaFSZgWkBIA4vJQY0LYgZmL8weFisNTcG1yi0fOSprcqkmUFTCQABOSNaQa0LYgx L2XUkBqNnmc08VTKlBUwkQAQluzTDEgJEBex+dQwUOABbgwXyNhWw6HGnVxpsgK+swHxSZoY 0Lwgjtz+1Mj1YUREUT+htHse05QTKkdWwHc2IAtJEwON5gXxE4O6R/X2gOieREaQPKzRI0sS ZAWkBIBc5EoM+GqECFyaTirFZxAN1fTTSsVQRENPtOhZASkBICNZEgPBw4OC3KiTfIF6RnRP JRXDwxp3cn3C1gnyAcADRP4gixwb1BTdOkkN96Smn1YGSNXR0HMt6FgBbRngDcIOGtDIQEBu 1EZquMdwQuEeEbMCvq0BLxE2MdBoZCCeaE0wEPDjhuhq3ClmoEApDW1PhMsKSAkA7xEtMRAk DMBGVGop36SexGmFS8TKCkgJAK8SJzGgnYHgxPmwwGMYKFBQg4YLBMoK+KoGvE2ovg7tDETW xPpJ58/zXPopWyhOlKyAlABQQdwTA3pLkAXdPkQXrZ+ynDcmQmQFpASAOuKYGNDBgowaWm/p /CmCvBFRF/+sgJQAUE18RwxoaiAL6iqihVxRcQ5zyDhnBaQEgJpinxjwpQgZcT0YQMzEMysg JQBUFsvEgE4VZOewDpP9KsVh0kgDCJN9ZYhbVkBKACDGIwa0NpAR9RZRQUVSnJMKEJ+sgJQA gCEGiQFXTyE77iMCEANxyApICQBYuZoY0JGCl9jXZxJgBUXMGKkVMEWsLbHOCkgJAARze8SA Bgeyow4DcFtMswJSAgDhuJEYMFAA76FWA3BJ7LICUgIA9lwaMaDNgTfY12RuFFGWzW0h1AoE sL+JKEZZASkBACeimBjwdQjvYdoxAPfEIisgJQDgXHz/+RgAADW5nhWQEgBoqKYnBgwUwKsY LoBDNIMIyaYNcTcrICUA0DiMGADO8TGBRjVAk8XiDiJSAgCN0Oimgytk8LZwl/qo88ri1CMq XMwK+GIG0ESNuFmCq2VQB7Ud4VA3EFFwJXErKyAlABAVjbuLmsYH3kYNhxPUE4QUrmK4lRVQ EQFEl5PEgMtjUA11HkC0uHgHEYkBgKho6MxjGh+ogHoOILpi99/GANBo/CQREA637ELjJ2sR DWQFAOQQMTGgbwTVUNsREo0hIgqZRpIVAJAGX3JAAD4UAKLFR4MCQC4hL4NxbQwATD4fHTxE EPy9yVgBAClx+ywAhENKgEYgKwAgmeAJBmQIAAA0EVkBAPmEnHnMtTEAABwKnnBMVgBAStYc gHwAAIBGsH6BMhkFAAAAUB1jBQAAAIDqyAoAAAAA1ZEVAAAAAKojKwAAAABUR1YAAAAAqI6s AAAAAFAdWQEAAACgOnezAp/PZ/5lGssss8wyyyyzzDLLLLMs5rKLWYH5HgAAAABE5uJ/GxtZ Af+dDAAAAAjOxawAAAAAgBSYbQwAAACozt15BUwtAAAAAMTHWAEAAACgOuYVAAAAAKpjrAAA AABQHfMKAAAAANVJPFbgvZTDe0cEAAAAKbiYFei6HrNJC1HpT8emU07XHwAAAKKJz1jB3Llz ExMT586dG60dNi79COigxyaHsb6LSxmCzW6N27oSExOvvfba/v37FxQUnDt3zvrs7bffHlAO xt6+//775557btSoUW3atLn22mt/85vfVFRUGBscOXJk5MiRbdu27dKly6pVq6yvPXHiRGpq quCJUBTDE/xIAQAAwonDvIL6+vqXXnrpueeee/nll+vr690LACHpul5bW7tv377nn3/+8OHD 119//alTp8xnW7duvXDhwuBXjR07tqys7D//8z8/+eSTHTt2jBw58pFHHtE07auvvho4cGB6 enpZWdnGjRs3btxofdVTTz01adIkt48IACAXrqEAItJdE27/JSUlffr00XU9Kytr48aN1u0X LlzYqVOnjIyMoqKi2traiOutrzUWLl++/Oabbw4ZMqRdu3YLFy40VlZWVk6aNKl79+6dOnUq KCj47rvv9J9eDg/e4aVLl1asWJGdnZ2dnb1ixYpLly4ZGyxfvrxbt25JSUkTJkz4+OOPg4+u c+fO77//vrFcVFRkLLz//vudO3cOeJeQAYTcf8hgAgI2H9qf3OCV06ZNu//++81nT58+nZaW VlNTE/CS5OTkkMf77//+7w8//HDwel3XDx061Llz5wsXLrhazZouYnjO4xf8SAFAELSWgIDi 8LEcPnz4q6++quv60qVLhw8f/s9QNM3v9+/cuXPnzp39+vUztrFfb32tsbB69erMzMzS0tKv v/560qRJxsqbbrpp06ZNp0+f/vTTT8eMGVNQUBC8h4CHr776qvmm2dnZS5cuNTYYPHhwWVnZ 0aNHp0yZ8sADDwQf3eTJkwsLC3Vd//LLL1u2bHn27Fld1xcuXDhlyhSbsM2HIfcfMhib+G1a 2+CnPvjgg4yMDOuzf/nLXzIzMwNyj8mTJw8fPvydd975/vvvrS/v0qXLtGnTunTp0q1bt7lz 5xrHaxg+fPiqVavs4xEBWQEAxJiT1pIWFYixWH/kPv3005SUlAsXLui6fuHChZSUlCNHjvwY iqaZQwclJSV5eXkR15u7NZfvuuuu4uJimwA+++yzwYMHB+8h4OGIESPMN12/fr3xppqm7du3 z1h57NixlJSU4P0XFxf/9re/1XW9oKAgJSVl8eLFuq7ffffd69evtwnbfBhy/yGDsYm/QVnB 999//y//8i8Bzz766KOPP/64deX58+cXLVrk9/tbtGjRs2fPBQsWnDt3Ttf15s2b5+bmHjx4 8N133x0+fPi8efOMV23ZsiU7O7u+vt4+nhgLOZRkDS94WMl+7KW2traoqCg9Pb1z586FhYX2 u9J1va6ubsOGDbfffnt6evrChQt/+OEHM4aVK1def/31V1999YABA6qrq9etW9e3b9/WrVtP mDDB/IzYjBpFHMUCAHGQFQACivUdRDNmzAi4henRRx81tz958qSxfPLkyaSkpIjrre9lLCQn J584cSLgTWtqasaPH5+enm7cyNi8efPgPQQ8TEpKMt/0xIkTxpvabG86d+5camqqrus9evQo KSkZMGCAruupqannz5+3Cdv+YchgbLZvUFbw/vvvd+vWLeDZixcv9u3bd8eOHcEvqaur27Fj R15e3rRp03Rdb9eu3cGDB42nDhw40LNnT2O5R48exsvt44mxkENJ1vBCDivZxP/KK69Yh3Ei 7mrt2rV+v7+8vPyjjz7Kzc21ZiY333zztm3bjh49+rvf/a5Vq1aDBw/+y1/+8vXXX//ud797 8MEHjc1sRo0ijmIBQOxpDu4BdniXr9WePXtGjhyZlJSUkZFhDErbXHNZvHhxWlqapmnJycmn Tp0yd3Ly5Mk2bdoYayK+/IorrnClgACRxDQrMAYHPvvsM3PNkSNHzKEDTdPeeecdY/3GjRtH jBhh7ifceut7GQshxwruuOOOZ5999pNPPvn73//+4YcfmhsnJCTU1dUF70QPP1YQcIAhD/yW W255/fXXs7OzdV3Pzs5et27drbfeGvJVNgFYH4YbK0hOTj527JixvHfv3nDHZR+ztdNpfda4 s+js2bMhD/Pw4cNG8nPrrbeGzAq0ICHjibGQ1SNcbOawkk3wAacm4q7GjBmzfft2Y2V1dfWQ IUPMGPbu3Wssf/PNN5qm/d///Z/50MmoUcRRLACIPc3BPcAO7/K18vv9L7300qlTp2pqasaM GaPbXnMZNGhQZWWlrusPPfSQuXNd15955pnp06cby05eDnheTPtqS5cuvfPOOwNW5uTkGLNy NU0bMGDArl27du3aNWDAgFdeeeXHEMOvN3diLq9evTorK2vLli3Wi8F9+/Z95ZVXTp8+XV5e ftttt5kb9+rVq6KiIngn+j+uAVdUVBgXZY2GzGFWUFBQ0L59+xdeeEHX9fnz53fo0GHOnDkh X2UTgPVhyGB0XZ8wYcLUqVO//vrrsrKyW2+9Ndxxhdzn8ePH9+zZc99996WmpprXTgICmD9/ /rhx44yV/fr1W7Fixaeffnru3Lldu3aNGjXq6aef1nV9zZo1d95558GDBw8ePGi9g8hJQcVe yKEka3ghh5Vs4g8Yxom4qzZt2lgzpWbNmgXHYPOwoaNGABBfmoN7gK1s7vK16tOnT0FBweef f26usbnmUl5ebizX1NSkpqYa4xW1tbUdO3b84osvnL8c8LyY9h4yMzPNq/6m9evXZ2Vl6f8Y Z7zuuuvS09OXLFlivWc63HpzJ+ZybW3t66+/PnDgwHbt2hmzfnVdLy8vHzJkSMuWLY0RTHNj 447wkDfeXLx4saioKCsrKysrq6io6OLFi7rjvteBAwcSExOPHz+u6/q3336bmJj47rvvhnyV TQDWhyGD0XX98OHDEyZMMIZQly9fHu64AvapadoVV1zRvn17v98/e/bsM2fOhDui+vr6YcOG GSsrKiruvvvu9u3bJyUl5eTkzJw505x2PG/evOuuuy4tLW3OnDnW2cYRCyr2Io4VhBxWshl7 yc3NNav0hg0bIu7qnnvuMW+sCheDzcOGzjABgPjSHNwD7PAuX6tDhw6NHTu2VatWfr+/rKxM t73mYm3Ac3Jy1qxZo+v66tWr8/PzzfUOXw54W6znFdhv36D1QEOFHEqyVrCQw0o2Yy9Lliwx B7L8fn/EXW3evNnv95eWlp45c6aqqio3Nzc4BpuH4UaNyAoAiElzcA+ww7t8g9XW1q5cubJ3 796642supaWl/fv313Xd7/fv37/fXO/w5YC3kRVAISGHkqwVLOSwks3Yy6VLl5YsWZKWltap U6eA3yAKuav6+vpNmzbde++9rVq1yszMXLduXXAMNg/DjRqRFQAQk+bgHmCHd/la5eXl7d+/ /8yZM0VFRX6/X3d8zUXX9e7du7/44ou33XabdaXzlwMeJlB1j1ZWoKHhonECAQD4Cc3BPcAO 7/K1Wrt2ba9evVq3bp2Xl2f8VIPDay66ri9evDghIaG0tNS60vnL0SBx7NjIIt6n6Cd8uufO Gf+j3gjeqwYAgLjz+TzYzYBzdMkiEuoDkujero2qEK+jFaqUReaNT6w3jiL2+JgAANzGd01I AnZdXMwKAACAjKLYXxGw6xNH9I8hMhezAqo+Yowq5xzf0wAAwIqxApG0z/EAACAASURBVAAA EAKXWqKIazEQX4J7u/b5fHwGAAAAAPG5mBUAAAAAkALzCgAAAADVMVYAAAAAqI55BQAAAIDq GCsAAAAAVMe8AgAAAEB1jBUAAAAAqmNeAQAAAKA6xgoAAAAA1TGvAAAAAFAdYwUAAACA6phX AAAAAKiOsQIAAABAdcwrAAAAAFTHWAEAAACgOuYVAAAAAKpjrAAAAABQHfMKAAAAANUxVgAA AACojnkFAAAAQASe79YyVgChef4TCACAmqxf8cal5ISEhH79+s2dO/e7776L+PITJ06kpqbG sp/g+XvjXcwKdF33fPHBbbquM+gEAIDn6bpeV1c3f/78bdu2LVq0KOL2Tz311KRJk2IQmDoY K4AcyA0AAELhWynqfD6f3+9/5plnXnjhhZSUlNOnT5tPnTp1qm3btuaampqa0tLS//iP/wi3 q6qqqlGjRiUnJ3fr1u21114zVtbX15eUlOTk5GRkZBQWFl64cMF83yVLlqSnp/t8Ppv3Nc94 XV3dW2+9NXTo0GuuuaawsNB+5xJhXgFEZx1xolIBAASh8mi22wfeunXr0aNHW0cMFi1alJ+f 36pVK+PhjBkzZs6c2aJFi3B7mDZt2rBhwz7++OO1a9eWlJQYK4uLi59++uknnniiuLh48+bN S5cuNbdfvXp1UVGRruv272t44403CgoKZsyYsW/fvvfffz/izqWhu8bt/Yv2vpKSpbjsq64s RyEOSgyADZoIh5x3qDxWpA4P3H4D61PmclVVVU5OTkFBQU1NTWpqam1tra7rtbW1HTt2/OKL L4xttmzZkp2dXV9fH7ATqz59+hQUFHz++efWlWPGjNm+fbuxXF1dPWTIEPPdy8vLjWWb9zXf 66677iouLg54x3A7tzl80aoE8wogK2Wv0AAABKGrOpodfOBNP3ZjJ5MnT77pppsefPDB9PT0 7t27v/XWW5qmvfnmmwMGDEhNTTW2fOSRR/77v//b/h1Xrlx56NChG264oX///uXl5cbKbdu2 3XLLLcYb9ezZc/v27eb2N954o7Fg876msrIyc3uTzc6loQflapqm+Xy+7OzsZ5999vTp0xET i7/97W/XXnutJky6Yx4XnIhXxXNDvMtSJpQYABs0EQ3i5PvIk0Ua8bvY/qi1UGMFVqWlpf37 99d13e/379+/3+Z9w71FbW3typUre/fubTy85557duzYYR+J/fsaCyHHCsLtPBwBq0SIsQI9 SnPAlUqaAQAADCp3gaI1dKBp2tChQ8+ePbtgwYKrr776hhtuMNdbO7JamB8MHTly5IEDB374 4YfLly+b0w/Gjx//6KOPbtmy5ezZs3v37h0xYkSD3tc0evToWbNmbd269dixY5MnT27QzoWm h8/V9u/f3759++Tk5FOnTpkrT5482aZNG3PNoUOHOnfubMyzDkg4zP3HWLzeV1ISFVccPh7R E+/CCyRmVAAEIVETEb923SlrnFIEHHU25y7kstXixYsTEhJKS0ud7MRq7dq1vXr1at26dV5e 3t69e42V9fX1mzZtuvfee1u1apWZmblu3bpwOwn5vuZmtbW1r7/++sCBA9u1a1dYWGi/c5vI bQonLny6rvt8Pt1y75C5fODAgXHjxt14440dO3b8/e9/b6wsKCj49ttvn3vuOePhHXfcce+9 9+bn51tfGF9GeipIMOKTpbhkv+giWgnLct4BxIVETYRc3w5GpyveUcSIebBSVKTYE7BwwmYF e/fufeqppwYOHJiXlzds2LBPP/00MTHx8uXLXbt2LSsrMyZebN269Q9/+MPu3buNoSJBDkzA UhaZLMUV3IxaYxb5KMSMTcyoAAhCoiZCkFBt+vpGbILEGXUhD9zaq9S8eNRRIWDhhJhXEK05 4CrfVIfoCqhIxjhXvIIBAMAqXG/H899WIS/YefuQvc3uDiLTli1b/vjHP+7atat///6FhYXm xAsxL98KmHuJTPzislazcHGKfBRixiZmVAAEIVETIUKo9t0h6zZSFKlzwdfsQm7gsaOOFgEL x9H/FTRuDjj5IqKI6gQAEJCyo9kB1+wUOWpvS3S43fTp0ydOnLhp0yZXowECiDNfBQCAAE5G sz3JPHCljtrzXOxycQeRFLxRXCIfhZixiRkVAEFI1ETEN1Tn7y5RkTrh8HA8dtTRJWDhOB0r AAAAgEnZ0WxlD9zzXMwKqDEAAMCrlO3nKHvgnudotjEAAAAAD3MxK+D/CgAAAAApMFYAAAAA qI55BQAAAIDqGCsAAAAAVMe8AgAAAEB1jBUAAAAAqmNeAQAAAKA6xgoAAAAA1TGvAAAAAFAd YwUAAACA6phXAAAAAKiOsQIAAABAdcwrAAAAAFTHWAEAAACgOuYVAAAAAKpjrAAAAABQHfMK AAAAANUxVgAAAACozrPzChimAAAAABxirAAAAABQnYtjBcbV+tiPGPDbRwAAAECDMFYAAAAA qM6z8woAAAAAOORiVgAAAADF8QMwsuD/CgAAAADVMVYAAACA6ONmcrkwrwAAAABQHb9BBAAA AKiOeQUAAACA6hgrAAAAAFTHvAIAAABAdYwVAAAAAKpjXgEAAACgOsYKAAAAANUxrwAAAABQ HWMFAAAAgOqYVwAAAACojrECAAAAQHXMKwAAAABUx1gBAAAAoDrmFQAAAACqY6wAAAAAUB3z CgAAAADVMVYAAAAAqI55BQAAAIDqGCsAAAAAVMe8AgAAAEB1jBUAAAAAqmNeAQAAAKA6xgoA AAAA1TGvAAAAAFCdi1mBpmnGHURGesAyy+4toynEOY8ss8yyOMtwgzjnl2WWg5e5gwgAAABQ nc9IDgCpWTNd0YgZm5hRARCERE2ELKHKEidUxlgBAAAAoDqyAgAAAEB1ZAUAAACA6sgKAAAA ANWRFQAAAACqIysAAAAAVEdWAAAAAKiOrAAAAABQHVkBAAAAoDqyAgAAAEB1ZAUAAACA6sgK AAAAANWRFQAAAACqIysAAAAAVEdWAESZz+fz+XxN2QAAACDGEuMdAOBNRr9f1/XglQAAAKJh rACIMmsmYKYBAeMDAdkCAABAfJEVAAAAAKojKwCiz34ogIECAAAgGrICAAAAQHVkBYArwg0I MFAAAAAERFYAAAAAqI6sAHBL8LAAAwUAAEBMZAUAAACA6sgKABdZBwcYKAAAAMIiKwAAAABU lxjvAID4sP7TsGfekeEIAADQOGQFAAAgymJ85SU2b8eVF3gbWQGU5pkmPvZDHwAAwEvICgAA gCu48gJIhNnGAAAAgOrICgAAAADVkRUAAAAAqiMrAAAAAFRHVgAAAACojqwAAAAAUB1ZAQAA AKA6sgIAAABAdWQFAAAAgOrICgAAAADVkRUAAAAAqiMrAAAAAFRHVgAAAACojqwAAAAAUB1Z AQAAAKA6sgIAAABAdWQFAAAAgOrICgAAAADVkRUAAAAAqiMrAAAAAFRHVgAAAACojqwAAAAA UB1ZAQAAAKA6sgLgJ3w+3+23367resBK+5fY7/PEiROpqakRN7N35MiRkSNHtm3btkuXLqtW rWrKrgAgLqLewEaxYYxKQw1IjawACNS6deuFCxdGcYdPPfXUpEmTbDbo3bv3888/f/z48XAb fPXVVwMHDkxPTy8rK9u4cePGjRujGB4AxEwUG1iHDWPEBtYQsaEGPM8XkLIDMjKu7jSoMod7 ic/nO336tN/vX7duXXp6urnS2HL37t3Lly8vLy+/cOHCgw8++NBDD/385z83XxsygJqamtzc 3Pfff/+qq64KF+G2bduWLVu2fv36m2++edy4cbm5uVdeeaV1gwkTJvzsZz974YUXGno40doe gFKa3kSE3EN0G9iIDaMhYgOrOWioXSoQQCiMFQCBfv7zn7/88sv/9m//VltbG/DUY489NmLE iJ07d27duvXgwYMvv/yy0cTruh6urZ8xY8bMmTNbtGhh846DBw9evnz5V1999etf/3rBggXX XHPNlClT9uzZY25QXl6ekJDQtWvX7t27z5s379y5c00+SgCIgyg2sA4bxogNrOasoQY8j7EC eEF0xwqMlY899lhiYuLs2bOtK60+//zz+++//89//nPIZw1bt279wx/+sHv3bp/PZ7NZgB07 duTn53/11Vfm9i1atBg6dOisWbN0XX/iiScGDRr0yCOPODmccLhqBcCGe2MFUWxgIzaMIQU3 sE4aasYKoAQdkF8jKnO4l5grL1682Ldv3x07dlhX1tTUjB8/Pj093Wjfmzdvbn02WI8ePYw9 BG8W/Bk8d+5cUVHRrbfempSUNGnSpN27d5tPtWvX7uDBg8bygQMHevbs6fBwwuHjD8BG05uI kHuIbgNr0zA2qIG1aajtD6dBaHUhPu4gAkK78sorly9f/uCDD1pHpWfMmNGtW7eSkpILFy58 +OGHFy9e1DQtISGhvr4+5E7ee++9m266ybj+pP30xzTMD6Gmadu2bRs3blyHDh3efPPNyZMn Hz16tLCwsF+/fubG5g24AOABUWlgbRrGBjWwNg01oBSyAiCsbt26PfTQQw8//LC55ptvvklK SkpKSqqqqpo6daqxskePHrt37w65B2sKroUfO37kkUd69+59+PDhDRs2jB49unnz5gEbTJw4 8cknn6yurq6urn7yySfHjh0bhcMDgPhpegPrsGGM2MA6bKgB73N3KAKIiUZU 5nAvCVhZX18/ bNgwc2V5efmQIUNatmyZkZFRVFRkrC8qKjIuWUV8xwZFGGDevHnXXXddWlranDlzzp49G7zz Bu2fjz8AG01vIkLuIeoNrH3D2Liww613o0AAoTDbGF4QxdnGkmK2MYAoYnJtAAoEKuAOIgAA AEB1ZAUAAACA6sgKAAAAANWRFQAAAACqIysAAAAAVEdWAAAAAKiOrAAAAABQHVkBAAAAoDqy AgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACqIysAAAAAVEdWAAAAAKiOrAAAAABQHVkBAAAA oDqyAgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACqIysAAAAAVEdWAAAAAKiOrAAAAABQHVkB AAAAoDqyAgAAAEB1ZAUAAACA6sgKAAAAANWRFQAAAACqIysAAAAAVEdWAAAAAKiOrAAAAABQ HVkBAAAAoLrEeAcAxJPP54t3CAAAAPFHVgAAAFzBlRdAImQFUJSu6zF7L+N7MZbvCAAA0CBk BQAAIMpidh3E5/NxzQWICmYbAwAAKRkjsdynBEQFWQEAAACgOrICAAAgH+sQAcMFQNORFQAA AACqIysAAACSCR4cYLgAaCKyAgAAAEB1ZAUAAEAm4YYFGC4AmoKsAAAAAFAdWQEAAJCG/YAA wwVAo7mbFfh8PvPzyTLLbi+jcUQ4dyyzzLJQy5pUJPpvY0HOL8ssh1x2MSsw3wMAAKDpzK6F ruvWZMD6kO4H0Dg+9zJs42MpUQYPeQle2QQMT8CQAIhD2CYiILDgOGWJHBBQonu7puoDAIBo 8fkiX8o0NnCyJYAAzDYGAAAScN7RJyUAGsHdeQXc2wcAAACIj7ECAAAAQHXMKwAAAABUx1gB AAAAoDrmFQAAAACqY6wAAAAAUB3zCgAAAADVMVYAAAAAqI55BQAAAIDqGCsAAAAAVMe8AgCA nYefX9DQl7w4faobkQAA3OOj7w4PMO5VE7YyCxiegCFBECFzgAb18gP2QIYgI1maCFni1KQK FcpyMSvgA4CYEbyyCRiegCEh7szefBT78WQIkpKliZAlTk2qUKEssgJ4geCVTcDwBAwJ8WLt uLvaaydDkIgsTYQscWpShQplcQcRvEDw1lbA8AQMCbFndNPj0jt3Y1wCUSRLEyFLnJpUoUJZ ZAXwAsFbWwHDEzAkxJIgnfI4piWwJ0sTIUucmlShQlncQQQvELyyCRiegCEhZkTri4sWDzR5 mghZ4tSkChXKIiuAFwhe2QQMT8CQEAPC9r+FDUxZsjQRssSpSRUqlMUdRPACwVtbAcMTMCS4 Tfyet/gRqkOWJkKWODWpQoWyyArgBYK3tgKGJ2BIcI9EvW2JQvU2WZoIWeLUpAoVyuIOIniB 4JVNwPAEDAkukbGfLWPMHiNLEyFLnJpUoUJZZAXwAsErm4DhCRgSok7qvrXUwXuALE2ELHFq UoUKZXEHEbxA8NZWwPAEDAnR5Y1e9cPPL5D9ECQlSxMhS5yaVKFCWQnxDgAAEGVGZ9ob/emA f0QGALjExazA5/MZmTEAIGa81I32RmIDAFJgrAAAvMZLnekXp0/1Up4DAMJiXgG8QPD7NQUM T8CQVOa81xuxu+/VG/G9elzCkqWJkCVOTapQoazEeAcAAIoykwHn/d2A/CHghd7uOptHFzKJ 8vCBA0Bs8Muk8ALBK5uA4QkYkjoakQzY7MfciTd+dCiYkxyAPCHqZGkiZIlTkypUKIusAF4g eGUTMDwBQ1JE1C/nWzvE3usHNzrViVbqpSxZmghZ4tSkChXKYl4BvEDw1lbA8AQMydti0En1 9u1DjUZ60DiyNBGyxKlJFSqURVYALxC8tRUwPAFD8rCY9de9ehNRVJAeNIgsTYQscWpShQpl cQcRvEDwyiZgeAKG5FUxvoRPYmCP8nFIliZCljg1qUKFssgK4AWCVzYBwxMwJO+hAyosTk1E sjQRssSpSRUqlMUdRPACwVtbAcMTMCSPod8pPmZi2JCliZAlTk2qUKEssgJ4geCtrYDhCRiS l9DdlAVnKhwpmggpgjTJFS3UlODern0+n/EZAAB10NGUyIvTpzr/Y2kA8DYXswIAUA1dTOmQ GACAwcWsQNd1RsoAqIaBAumQGACAxlgBAEQL9w7Ji8QAAJhXAAAAAKiOsQIAiAKuNMuO4QIA imNeAQBEB7cPyY7EAIDKGCsAgKZiRgEAQHbMKwCAJiEl8BiGCwCoibECAAB+RIIHQFmJ7u2a SQUAAACAFBgrAIDG4/YhAIA3MK8AAIB/4peIAKiJsQIAAABAdcwrAAAAAFTHWAEANBL3mQAA PIN5BQDQeEw1BgB4A2MFAAAAgOqYVwAAAACojrECAAD+if+gAKAm5hUAAAAAqmOsAAAAAFAd 8woAAPgRvzYLQFmMFQAA8E9MKgCgJuYVAACgacwzBqA2xgoAoJHoQXoJ9w4BUBzzCgCgwaw9 SHIDz+BUAlCZi1kBAHiMmQzQffQYBgoAwOfeFX1jUgEjBogBwSubgOEJGJLgjF4jyYCHcYqt pGgipAjSJFe0UBNZAbxA8MomYHgChiQyJqGqg9zAIEUTIUWQJrmihZpczAqAmBG8tRUwPAFD EhN9RDVx3qVoIqQI0iRXtFATv0EEAHZU7hoqyzjpTDYAoBTuIIIXCF7ZBAxPwJAExI1DULYO SNFESBGkSa5ooSbGCgAgBGW7gwjggRED/lEUgBMuZgW6rpMTA3GkeFegKYdPSgCDN6qBrus+ n0/xBgFARIwVAJ6leFeg0YdPSgCrF6dP9cBwgUHlBgFARC5mBbQ+gCAU/zAqfvhoOg8kBtah ez4RAEJirADwMsW7Ao04fA8PFLh39q17FrmOiRxbDATc06tggwDAXoIW1KD7fL6EhIR+/frN nTv3u+++s3/9kSNHRo4c2bZt2y5duqxatcr6FPMKABEo3hVo0OF7OCVA08k+XBCSag0CABsh xgp0Xa+rq5s/f/62bdsWLVpk8+Kvvvpq4MCB6enpZWVlGzdu3Lhxo2txAkDUxKwn5NI1FxWI 1lU10kWf5MIdnc2z8Q3YnlsnG1BV6DuIfD6f3+9/5plnXnjhhZSUlNOnT5tPnTp1qm3btsaa p556atSoUQUFBenp6Wlpaa+99lrATvjQAiIIN2oX1y/02AlXLAHPxmCggGsuEJn95wWA50WY V9C6devRo0dbv70WLVqUn5/fqlUrTdPKy8sTEhK6du3avXv3efPmnTt3zt1gAQmZ37Jx6xTz TW8rxuXji8Y1F0Ntbe3KlSv79evXr1+/lStX1tbWmm+xYsWK7t27Jycn33///Z988knAC2++ +eY1a9aYD//6179ec801Z86csW5TV1f31ltvDR069JprriksLDRW1tfXl5SU5OTkZGRkFBYW XrhwoUEHHjKqkPs0zoh5arp06fLBBx8Y2y9btsxY+OCDD7p06RKxKJYsWZKenp6YmGgNZt++ fR06dJg/f77z+DVNe3H61KnPvahLzuYAQ24Q32idaNBJBGDH+ERZP13GQlVVVU5OTkFBQU1N TWpqam1tra7rtbW1HTt2/OKLL4xtmjdvnpube/DgwXfffXf48OHz5s2LeWsA6Po/vhXiHUVo 8fx4OxPvEooFJ4fvRodPC9W66rq+f//+Hj16PPTQQwUFBebKZ555Zvr06cZyly5dpk2b1qVL l27dus2dO/fs2bPBO3/11Vf9fv/OnTt37tyZnZ29dOlS840GDx5cVlZ29OjRKVOmPPDAAwEB bN68OSMjo66uzng4YcIEaxiG1atXZ2ZmlpaWfv3115MmTTJWrl271u/3l5eXf/TRR7m5uQsX LrQ/zICiCBmVk31Onjy5sLBQ1/Uvv/yyZcuWRmksXLhwypQpEYti0KBBlZWV1n1u2LAhJSVl 3bp1IeO0J3tW4LwRUKdxiBmKFOILkRUYMjMzZ8+eferUKV3Xc3Jy1qxZo+v66tWr8/PzzY3b tWt38OBBY/nAgQM9e/aMaezAP9Da2lM5H9CdHb5Lvb2Q3eVoXXMZMWLExo0bjeX169fn5eWZ b7Rv3z5j+dixYykpKcHBZGVlrVq1Stf1w4cPd+jQ4fvvvw/Y+V133VVcXBywcsyYMdu3bzeW q6urhwwZYnOYwUURMion+ywuLv7tb3+r63pBQUFKSsrixYt1Xb/77rvXr18fsSjKy8utMSxY sOCaa66pqqoKGWRE3ssK7LeMZWyeR5FCfGHHCqxKS0v79++v67rf79+/f7+5/tZbb7XJCvgA IGaobPbICiIeeGyyAkO0rrkkJSWdPHnSWD5x4kRSUlLwm1ofWtevW7cuLS3t8uXLY8aMeeGF F4J3npycfOLEiYCVbdq0sRZjs2bNQh5mxKKwPnSyz3PnzqWmpuq63qNHj5KSkgEDBui6npqa ev78+YhFYQ6JGA87der0+OOPh4zQCamzggZ9/JVqImKDIoX4HP1fwdChQ8+ePbtgwYKrr776 hhtuMNdPnDjxySefrK6urq6ufvLJJ8eOHetkbwBiKeCmeeOTH69gYk+owzfefe/evY8//rgx O2v69OnG3e3z58+fMWOGuWV6enrEvd144427d+82lnft2vWrX/3KeSQjRoy48sorH3/88crK yokTJwZvMHDgwIqKioCVgwYN2rFjh/n9cenSJefvGE64fSYkJNTX1xvLV199dadOnf70pz9d ddVVd9xxx+XLl4uLizt37vyzn/3M2MCmKBISfvI1V1ZW9sYbb8ydO7fpkcvF+kFQrREA4JTu 7DLP4sWLExISSktLA9bPmzfvuuuuS0tLmzNnTsg7X4EYMCszAgR82APWxyuqmAl3+MFieQdR gO7du7/44ou33XabdeWaNWvuvPPOgwcPHjx4MNwdRK+88orf76+oqDBupn/11VdDvpEWaqzA eAtN05YsWRIyqtWrV2dlZW3ZssU6r2Dz5s1+v7+0tPTMmTNVVVW5ubnODzNcVOH22atXr4qK CnP7goKC9u3bG8Ma8+fP79Chw5w5cxpXFEePHk1LS5s9e3bIOO3JO1bQ0I+8Ik1ELFGkEB8V FF5AaxtOuJJRpMScH2Ycs4JGX3O5ePFiUVFRVlZWVlZWUVHRxYsXQ75RuKzgjTfe6Nq1qzGr IVhtbe3rr78+cODAdu3aGTN9dV2vr6/ftGnTvffe26pVq8zMTHPCblOygnD7LCoqMgZMjIcH DhxITEw8fvy4ruvffvttYmLiu+++2+iiOHbsWEZGxsyZM0OGakPSrKARH3ZFmohYokghPp/u 2jCiMV7p3v4BE5UtJJ8v7AdchRKzOfwAav6lcW5ubn5+/pgxY+IdiEzUqSoqNBExRpFCfImR NwEgJ8W/fhQ/fBuXL19esGDB6dOn77nnnnjHAgAQhYtZAV/JACCgZs2a9enTZ/ny5fy9HQDA xFgBAKiFSzYAgGCOfpm0ccw/qwcAQHbqTCoAoCYXswIAAAAAUnAxKzB+5Mi9/QNAtDz8/IJ4 hwChUUMAeB5jBQBUx20hcIJ6AsDbmFcAAAAAqI6xAgAA7DDPGIAK+L8CAADCIiUAoAjGCgBA e3H6VKaTIhgpAQB1MK8AAIAQSAkAKIWxAgAAAEB1zCsAAAAAVMdYAQBoGlMLAABqY14BAPyI xAAAoCzGCgAACI0sEYA6XMwKdF1nagEAuTBcABM/QARAKYwVAAAAAKpjXgG8wwfH4n2uhMZw AQBAQYwVAEAgEgMAgGr4vwJ4AZUNUWcmBtxcDgBQAWMFABAa+QAAQB3MKwCAsIwRA+4mAgB4 HmMFAGDnxelTmWYAAPA85hUAAIAQGPAHlMJYAQAAAKA6F8cKjGsMjBgAACAXvrsBBTFWAACR MbVAQZxxAEphXgEAAKHx67QA1MFYAQAAAKA6/q8AAAAAUB1jBQDgCFMLAAAexrwCAAAAQHWM FQAAEIhxIQCqYV4BADjFTURK4QeIACiFsQIAAABAdS5mBbquM7UAgMcwXAAA8CTGCgCgwUgM vI3zC0BBzCsAgIbhdnMVcJYBqIaxAgAA/omBAgBqYl4BADQYswu8jYECAApirAAAGoPEAADg JcwrAIBGIjHwHk4oAGUxVgAAjWckBnQlvYTbhwCoiXkFANAkRicyZokBGYh7KFsAKmOsAACa 6sXpU7mbyBsYKACgLOYVAEB0kBhI7eHnF5ASAFBZYrwDAADvsCYGdDElQjoHAD5u/QcANxgd zajnBi7tVnEMFAAAWQEAuMV6BToqnc6o7xAaKQEAaJrm6h1EtNevtQAAAcRJREFUxqQCsg4A yjL7mtZfL21QBzTgzhbrDqMRIChJAPgR8woAwHUh04OGvhZWUbyTihIGAI07iABAUorf9xKV w1e8DAHAiv8rAABZKXv3S9N788agDSkBAJj4vwIAkJKyPdqopASawgUIACExVgAAslLwf9Oa frxGUkFKAAABmFcAAHJT6sp3UwYKlCooAGgosgIAkJ4K/d0mHqMKRQQATeFiVsD/FQBAzHi7 19uUo/N2yQBAtJAVAIBHePJHdcw+fUM79/wPNAA0CHcQAYB3eOy6eMDhhJxqbDxr8xQAwAmy AgDwFLN/LHWf2GF6w4AAAEQLdxABgAfJO2jgjawGAKRDVgAAniVdbiBdwADgGdxBBABeJsul d/IBAIgvsgIA8L6AybhCdb5lyVsAwNu4gwgA1CJOL1ycSAAAZAUAoKJ4jR6IPGoBACrjDiIA UJ3b1+zJBABAfGQFAABNC/NHYFoDO/H8mxgASIo7iAAAYYVLFWyQAwCAjMgKAAAAANVxBxEA AACguoR4BwAAAAAgzhLd27VxB5H2j5uIrDcUscwyyyyzzDLLLLPMMsviLLs4VmC8AQAAAADB Ma8AAAAAUN3/A8aFGW7TM9pHAAAAAElFTkSuQmCCAA== --B_3645627951_2109962198-- From nobody Wed Jul 10 10:33:03 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AFF120494; Wed, 10 Jul 2019 10:32:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson , v6ops-chairs@ietf.org, swmike@swm.pp.se, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156277997381.15131.10075465420984202818.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 10:32:53 -0700 Archived-At: Subject: [v6ops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-v6ops-nat64-deployment-07=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 17:32:54 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The use of normative language in section 5 doesn't very consequent. While it is okay for informational document to have normative language, I have the feeling that the recommendation given in this document aren't very "strong" and therefore it might be more suitable to not use any normative language at all. Just a thing to consider before publication. Minor comment: STUN ([RFC5389]) and TURN ([RFC5766]) have recently been bis'ed. Please update to the new RFC/draft. From nobody Wed Jul 10 12:07:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978BA1202E5; Wed, 10 Jul 2019 12:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 vXWAY4DufZtL; Wed, 10 Jul 2019 12:07:35 -0700 (PDT) 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 845891202D6; Wed, 10 Jul 2019 12:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562785650; x=1563390450; 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=B1i64eFVmYsn5+B+c9Wp5bW89Hu/AVHXZm0rvx+AAKY=; b=wnMeC08n49bQk iw9ogs+nU4HNF2pK659DH4ObjeFofVfcID63jrw857JaUhcPKSceAw+0SvUVLOxS OclzPjXITQBy2X2PRGUPERjGCTyiqqalYcmppncinBE0D8t0eCvRUHI0YzwEzkH6 mOUG/+BTk4QFUAg4gmEydXdHJ3n5iY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 10 Jul 2019 21:07:30 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 10 Jul 2019 21:07:30 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006321712.msg; Wed, 10 Jul 2019 21:07:29 +0200 X-MDRemoteIP: 2001:470:1f09:495:59f6:b12c:6a50:389d X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 10 Jul 2019 21:07:29 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1094617358=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Wed, 10 Jul 2019 21:07:27 +0200 From: JORDI PALET MARTINEZ To: Mirja =?UTF-8?B?S8O8aGxld2luZA==?= , The IESG CC: , , Message-ID: Thread-Topic: [v6ops] Mirja =?UTF-8?B?S8O8aGxld2luZCdz?= No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) References: <156277997381.15131.10075465420984202818.idtracker@ietfa.amsl.com> In-Reply-To: <156277997381.15131.10075465420984202818.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-v6ops-nat64-deployment-07=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 19:07:38 -0000 Hi Mirja, Thanks a lot for the inputs. I'm happy to remove the normative language, but I've heard contradictory op= inions in previuos similar documents from the IESG. For example we tried to= use RFC7084 language for RFC8585, and we were told to change it to normati= ve ... and no "special". For TURN, I already added a reference to the bis document in v07, according= to one of the inputs from Eric. For STUN, I was not aware of that. I will = keep that in a -v08 document, in case I need to update anything else. Other= wise, I can inform the RFC Editor to update them I guess? Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 10/7/19 19:33, "v6ops en nombre de Mirja K=C3=BChlewind via Dat= atracker" escribi=C3= =B3: Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Objection =20 When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) =20 =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 The use of normative language in section 5 doesn't very consequent. Whi= le it is okay for informational document to have normative language, I have the = feeling that the recommendation given in this document aren't very "strong" and therefore it might be more suitable to not use any normative language a= t all. Just a thing to consider before publication. =20 Minor comment: STUN ([RFC5389]) and TURN ([RFC5766]) have recently been= bis'ed. Please update to the new RFC/draft. =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Wed Jul 10 12:24:40 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDA0120147; Wed, 10 Jul 2019 12:24:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson , v6ops-chairs@ietf.org, swmike@swm.pp.se, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156278667869.15337.6477997869342089073.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 12:24:38 -0700 Archived-At: Subject: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 19:24:39 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It is strange to me that this document interleaves figures that are numbered and figures that are lettered. = Section 4.4.2 = "A new trend is for ..." This will not age well, probably better to phrase this in a timeless fashion. From nobody Wed Jul 10 13:15:36 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6051203FD; Wed, 10 Jul 2019 13:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=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=theipv6company.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 eB2oMxvTWNnB; Wed, 10 Jul 2019 13:15:25 -0700 (PDT) Received: from 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 CEF89120433; Wed, 10 Jul 2019 13:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1562789720; x=1563394520; i=jordi.palet@theipv6company.com; 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=+YTZSPuRyBmAeUrKhg6/VVdJPuvnO+YhTW1DzAZQ36Y=; b=DEvxFuUvVvfP+ LnHNh5nxCBloJOL/7onzwGXWYMAt3avz/DGfLyPCWuIF56j5jg0rBg/gqziVRyCm M70oXi9FbtnEEtUXUK7VO+xf8DILnxh4dd10KVvITWo/ePRFGJfZP1haryu8Y79z nICpp8q3Y/dTNR3RaprSk4G5VgM43s= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Wed, 10 Jul 2019 22:15:20 +0200 X-Spam-Processed: consulintel.es, Wed, 10 Jul 2019 22:15:20 +0200 Received: from [10.10.10.130] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006321754.msg; Wed, 10 Jul 2019 22:15:19 +0200 X-MDRemoteIP: 2001:470:1f09:495:4daf:cd3c:df68:2ae7 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Wed, 10 Jul 2019 22:15:19 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=10942701d6=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Wed, 10 Jul 2019 22:15:14 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: Alissa Cooper , The IESG CC: , Mikael Abrahamsson , , Message-ID: Thread-Topic: Alissa Cooper's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) References: <156278667869.15337.6477997869342089073.idtracker@ietfa.amsl.com> In-Reply-To: <156278667869.15337.6477997869342089073.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 20:15:28 -0000 Hi Alisa, Thanks for the inputs. Responses below, in-line. Regards, Jordi @jordipalet =20 =EF=BB=BFEl 10/7/19 21:24, "Alissa Cooper via Datatracker" escribi=C3=B3: Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Objection =20 When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) =20 =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 It is strange to me that this document interleaves figures that are num= bered and figures that are lettered. I want to make sure that the figures that will take part of the table in fi= gure 13 are numbered consecutively, so the only way I was able to find was = using letters for the figures in that part of text that don't belong to tha= t table. =20 =3D Section 4.4.2 =3D =20 "A new trend is for ..." =20 This will not age well, probably better to phrase this in a timeless fa= shion. =20 I will find a better way. I will keep this for a couple of days in case there are more inputs, so I c= an accommodate all them in a single version. =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 Wed Jul 10 17:44:33 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B65F120024; Wed, 10 Jul 2019 17:44:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson , v6ops-chairs@ietf.org, swmike@swm.pp.se, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156280587243.15387.3448756354265835528.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 17:44:32 -0700 Archived-At: Subject: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 00:44:33 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Section 5. Is there an informative reference that can be made about the successful deployment on cellular networks? (2) Section 7. Consider adding an explicit statement such as the following after the intro sentence that “no new security considerations are added”: As noted in the relevant sections above, the NAT64 and DNS64 technologies can impact the efficacy or functionality of key security (i.e., DNSSEC and VPNs) and privacy preserving (i.e., DNS-over-TLS and DNS-over-HTTP) technologies. (3) Editorial Nits ** Section 1. Editorial. s/today unrealistic/unrealistic today/ ** Section 5. Typo. s/learn he/learn the/ ** Section 5. Editorial. “Hundreds of millions of users” mentioned twice. OLD: NAT64/464XLAT has demonstrated to be a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions of users, being the predominant mechanism in the majority of the cellular networks (which account for hundreds of millions of users). NEW: NAT64/464XLAT has demonstrated to be a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4) in cellular networks which account for hundreds of millions of users. From nobody Wed Jul 10 23:40:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42EC12015A; Wed, 10 Jul 2019 23:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=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=theipv6company.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 iwjpttOXRdoB; Wed, 10 Jul 2019 23:40:42 -0700 (PDT) Received: from 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 8E2C512012A; Wed, 10 Jul 2019 23:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1562827238; x=1563432038; i=jordi.palet@theipv6company.com; 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=828x4pJFG1HVaZ9lBDdr1sQzWT6z7rbO0tnZjDIYxQ4=; b=r5IecIJPrMo1H wuwf6ApfVjfQjRac9PFd36FMEy/P/Fo18SaH2agNeYZLs0rvmr97Xu/zwNQXI8EO 8exxAoUT/2CzWcbuVDTLKdUcWC8oIu+Imq6x5X+nUZ8Bfd7eHQlVtAEf0HRMDtYc ZPoWBJbkx2b2sK35zu6kVFvPOlHeDc= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Thu, 11 Jul 2019 08:40:38 +0200 X-Spam-Processed: consulintel.es, Thu, 11 Jul 2019 08:40:38 +0200 Received: from [10.10.10.130] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006322090.msg; Thu, 11 Jul 2019 08:40:38 +0200 X-MDRemoteIP: 2001:470:1f09:495:4daf:cd3c:df68:2ae7 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 11 Jul 2019 08:40:38 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=1095f3ff43=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Thu, 11 Jul 2019 08:40:33 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: Roman Danyliw , The IESG CC: , Mikael Abrahamsson , , Message-ID: Thread-Topic: Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) References: <156280587243.15387.3448756354265835528.idtracker@ietfa.amsl.com> In-Reply-To: <156280587243.15387.3448756354265835528.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 06:40:45 -0000 Hi Roman, Thanks a lot for your inputs. See below, in-line. Regards, Jordi @jordipalet =20 =EF=BB=BFEl 11/7/19 2:44, "Roman Danyliw via Datatracker" escribi=C3=B3: Roman Danyliw has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Objection =20 When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) =20 =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 (1) Section 5. Is there an informative reference that can be made abou= t the successful deployment on cellular networks? Do you mean citing specific operators? I can name several in almost every c= ontinent, but I'm not convinced this is correct in an IETF document ... =20 (2) Section 7. Consider adding an explicit statement such as the follo= wing after the intro sentence that =E2=80=9Cno new security considerations a= re added=E2=80=9D: =20 As noted in the relevant sections above, the NAT64 and DNS64 technologi= es can impact the efficacy or functionality of key security (i.e., DNSSEC and = VPNs) and privacy preserving (i.e., DNS-over-TLS and DNS-over-HTTP) technolog= ies. -> I will need to reword it. This is right in the reference to DNSSEC. Howe= ver VPNs and DNS privacy, the point is on the other way around (those techn= ologies can avoid the DNS64 performing correctly, and thus, break NAT64). =20 (3) Editorial Nits =20 ** Section 1. Editorial. s/today unrealistic/unrealistic today/ =20 ** Section 5. Typo. s/learn he/learn the/ =20 ** Section 5. Editorial. =E2=80=9CHundreds of millions of users=E2=80= =9D mentioned twice. =20 OLD: NAT64/464XLAT has demonstrated to be a valid choice in several scenario= s (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions of users, bei= ng the predominant mechanism in the majority of the cellular networks (which a= ccount for hundreds of millions of users). =20 NEW: NAT64/464XLAT has demonstrated to be a valid choice in several scenario= s (IPv6-IPv4 and IPv4-IPv6-IPv4) in cellular networks which account for h= undreds of millions of users. =20 Noted and corrected all those nits in my internal version. I will wait a co= uple of days before publishing it, in case there are any further inputs. = =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 Thu Jul 11 00:05:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBFD12010E; Thu, 11 Jul 2019 00:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 I-7iqXFcZaYr; Thu, 11 Jul 2019 00:05:34 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79826120045; Thu, 11 Jul 2019 00:05:34 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 45knBh5s2lz4wYk; Thu, 11 Jul 2019 09:05:32 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 45knBh52qnzDq7S; Thu, 11 Jul 2019 09:05:32 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([fe80::f04d:ad3c:61de:a175%21]) with mapi id 14.03.0439.000; Thu, 11 Jul 2019 09:05:32 +0200 From: To: =?utf-8?B?Sm9yZGkgUGFsZXQgTWFydMOtbmV6?= , Roman Danyliw , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) Thread-Index: AQHVN7OhRYkMnYJXqkWdPuDIt+5vYKbE/Upw Date: Thu, 11 Jul 2019 07:05:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAC9D83@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <156280587243.15387.3448756354265835528.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:05:36 -0000 SGkgSm9yZGksIGFsbCwNCg0KT25lIGNvbW1lbnQgYmVsb3cuDQoNCkNoZWVycywNCk1lZA0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB2Nm9wcyBbbWFpbHRvOnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9yZGkgUGFsZXQNCj4gTWFydMOtbmV6 DQo+IEVudm95w6nCoDogamV1ZGkgMTEganVpbGxldCAyMDE5IDA4OjQxDQo+IMOAwqA6IFJvbWFu IERhbnlsaXc7IFRoZSBJRVNHDQo+IENjwqA6IHY2b3BzQGlldGYub3JnOyBkcmFmdC1pZXRmLXY2 b3BzLW5hdDY0LWRlcGxveW1lbnRAaWV0Zi5vcmc7IHY2b3BzLQ0KPiBjaGFpcnNAaWV0Zi5vcmcN Cj4gT2JqZXTCoDogUmU6IFt2Nm9wc10gUm9tYW4gRGFueWxpdydzIE5vIE9iamVjdGlvbiBvbiBk cmFmdC1pZXRmLXY2b3BzLQ0KPiBuYXQ2NC1kZXBsb3ltZW50LTA3OiAod2l0aCBDT01NRU5UKQ0K PiANCj4gSGkgUm9tYW4sDQo+IA0KPiBUaGFua3MgYSBsb3QgZm9yIHlvdXIgaW5wdXRzLg0KPiAN Cj4gU2VlIGJlbG93LCBpbi1saW5lLg0KPiANCj4gUmVnYXJkcywNCj4gSm9yZGkNCj4gQGpvcmRp cGFsZXQNCj4gDQo+IA0KPiDvu79FbCAxMS83LzE5IDI6NDQsICJSb21hbiBEYW55bGl3IHZpYSBE YXRhdHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+DQo+IGVzY3JpYmnDszoNCj4gDQo+ICAgICBS b21hbiBEYW55bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZv cg0KPiAgICAgZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1kZXBsb3ltZW50LTA3OiBObyBPYmplY3Rp b24NCj4gDQo+ICAgICBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gICAgIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiB0aGlzDQo+ICAg ICBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiAgICAgUGxlYXNl IHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+ IGNyaXRlcmlhLmh0bWwNCj4gICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gICAgIFRoZSBkb2N1bWVudCwg YWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4g ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtbmF0 NjQtZGVwbG95bWVudC8NCj4gDQo+IA0KPiANCj4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgIENP TU1FTlQ6DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAgICAgKDEpIFNlY3Rpb24gNS4gIElz IHRoZXJlIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0aGF0IGNhbiBiZSBtYWRlDQo+IGFib3V0 IHRoZQ0KPiAgICAgc3VjY2Vzc2Z1bCBkZXBsb3ltZW50IG9uIGNlbGx1bGFyIG5ldHdvcmtzPw0K PiANCj4gRG8geW91IG1lYW4gY2l0aW5nIHNwZWNpZmljIG9wZXJhdG9ycz8gSSBjYW4gbmFtZSBz ZXZlcmFsIGluIGFsbW9zdCBldmVyeQ0KPiBjb250aW5lbnQsIGJ1dCBJJ20gbm90IGNvbnZpbmNl ZCB0aGlzIGlzIGNvcnJlY3QgaW4gYW4gSUVURiBkb2N1bWVudCAuLi4NCj4gDQoNCltNZWRdIE5v IG5lZWQgdG8gYmUgZXhoYXVzdGl2ZSBoZXJlLCBJIHN1Z2dlc3QgdG8gYWRkIG9uZSBzaW5nbGUg cG9pbnRlcjogaHR0cHM6Ly93d3cud29ybGRpcHY2bGF1bmNoLm9yZy9tYWpvci1tb2JpbGUtdXMt bmV0d29ya3MtcGFzcy01MC1pcHY2LXRocmVzaG9sZC8uIEhhdmluZyBhbiBpbmZvcm1hdGl2ZSBy ZWZlcmVuY2UgaXMgaGVscGZ1bCBmb3IgdGhpcyBraW5kIG9mIHN0YXRlbWVudHMgKGJlY2F1c2Ug b3RoZXJ3aXNlLCB0aGlzIG1heSBiZSBjb25zaWRlcmVkIGFzIHNwZWN1bGF0aXZlKS4gDQoNCg0K PiAgICAgKDIpIFNlY3Rpb24gNy4gIENvbnNpZGVyIGFkZGluZyBhbiBleHBsaWNpdCBzdGF0ZW1l bnQgc3VjaCBhcyB0aGUNCj4gZm9sbG93aW5nDQo+ICAgICBhZnRlciB0aGUgaW50cm8gc2VudGVu Y2UgdGhhdCDigJxubyBuZXcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXJlDQo+IGFkZGVk4oCd Og0KPiANCj4gICAgIEFzIG5vdGVkIGluIHRoZSByZWxldmFudCBzZWN0aW9ucyBhYm92ZSwgdGhl IE5BVDY0IGFuZCBETlM2NA0KPiB0ZWNobm9sb2dpZXMgY2FuDQo+ICAgICBpbXBhY3QgdGhlIGVm ZmljYWN5IG9yIGZ1bmN0aW9uYWxpdHkgb2Yga2V5IHNlY3VyaXR5IChpLmUuLCBETlNTRUMgYW5k DQo+IFZQTnMpDQo+ICAgICBhbmQgcHJpdmFjeSBwcmVzZXJ2aW5nIChpLmUuLCBETlMtb3Zlci1U TFMgYW5kIEROUy1vdmVyLUhUVFApDQo+IHRlY2hub2xvZ2llcy4NCj4gDQo+IC0+IEkgd2lsbCBu ZWVkIHRvIHJld29yZCBpdC4gVGhpcyBpcyByaWdodCBpbiB0aGUgcmVmZXJlbmNlIHRvIEROU1NF Qy4NCj4gSG93ZXZlciBWUE5zIGFuZCBETlMgcHJpdmFjeSwgdGhlIHBvaW50IGlzIG9uIHRoZSBv dGhlciB3YXkgYXJvdW5kICh0aG9zZQ0KPiB0ZWNobm9sb2dpZXMgY2FuIGF2b2lkIHRoZSBETlM2 NCBwZXJmb3JtaW5nIGNvcnJlY3RseSwgYW5kIHRodXMsIGJyZWFrDQo+IE5BVDY0KS4NCj4gDQo+ ICAgICAoMykgRWRpdG9yaWFsIE5pdHMNCj4gDQo+ICAgICAqKiBTZWN0aW9uIDEuICBFZGl0b3Jp YWwuIHMvdG9kYXkgdW5yZWFsaXN0aWMvdW5yZWFsaXN0aWMgdG9kYXkvDQo+IA0KPiAgICAgKiog U2VjdGlvbiA1LiAgVHlwby4gIHMvbGVhcm4gaGUvbGVhcm4gdGhlLw0KPiANCj4gICAgICoqIFNl Y3Rpb24gNS4gIEVkaXRvcmlhbC4gIOKAnEh1bmRyZWRzIG9mIG1pbGxpb25zIG9mIHVzZXJz4oCd IG1lbnRpb25lZA0KPiB0d2ljZS4NCj4gDQo+ICAgICBPTEQ6DQo+ICAgICBOQVQ2NC80NjRYTEFU IGhhcyBkZW1vbnN0cmF0ZWQgdG8gYmUgYSB2YWxpZCBjaG9pY2UgaW4gc2V2ZXJhbA0KPiBzY2Vu YXJpb3MNCj4gICAgIChJUHY2LUlQdjQgYW5kIElQdjQtSVB2Ni1JUHY0KSwgd2l0aCBodW5kcmVk cyBvZiBtaWxsaW9ucyBvZiB1c2VycywNCj4gYmVpbmcgdGhlDQo+ICAgICBwcmVkb21pbmFudCBt ZWNoYW5pc20gaW4gdGhlIG1ham9yaXR5IG9mIHRoZSBjZWxsdWxhciBuZXR3b3JrcyAod2hpY2gN Cj4gYWNjb3VudA0KPiAgICAgZm9yIGh1bmRyZWRzIG9mIG1pbGxpb25zIG9mIHVzZXJzKS4NCj4g DQo+ICAgICBORVc6DQo+ICAgICBOQVQ2NC80NjRYTEFUIGhhcyBkZW1vbnN0cmF0ZWQgdG8gYmUg YSB2YWxpZCBjaG9pY2UgaW4gc2V2ZXJhbA0KPiBzY2VuYXJpb3MNCj4gICAgIChJUHY2LUlQdjQg YW5kIElQdjQtSVB2Ni1JUHY0KSBpbiBjZWxsdWxhciBuZXR3b3JrcyB3aGljaCBhY2NvdW50IGZv cg0KPiBodW5kcmVkcw0KPiAgICAgb2YgbWlsbGlvbnMgb2YgdXNlcnMuDQo+IA0KPiBOb3RlZCBh bmQgY29ycmVjdGVkIGFsbCB0aG9zZSBuaXRzIGluIG15IGludGVybmFsIHZlcnNpb24uIEkgd2ls bCB3YWl0IGENCj4gY291cGxlIG9mIGRheXMgYmVmb3JlIHB1Ymxpc2hpbmcgaXQsIGluIGNhc2Ug dGhlcmUgYXJlIGFueSBmdXJ0aGVyIGlucHV0cy4NCj4gDQo+IA0K From nobody Thu Jul 11 00:27:41 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D31120173; Thu, 11 Jul 2019 00:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=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=theipv6company.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 agBUgjQaq_Yb; Thu, 11 Jul 2019 00:27:29 -0700 (PDT) Received: from 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 8C91D120045; Thu, 11 Jul 2019 00:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1562830045; x=1563434845; i=jordi.palet@theipv6company.com; 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=M7PpLjIjADyyrRLsqqQlmICeQgq/nEkoIM4V4cPg3r0=; b=V1yN/yhSlRf1i O+Ib9pnlCW/iwHNxuGcP6xctGGEukGrufjsJr5ZQv2fhMebVqyg/+rQP0iAWyvDc S4l2UVCuOMgK71VoTBSYM+8SioPo6GXDtPks9hKuZP3imt7ud2qjUKR/Ylc+Yxif i3kz42plEMks5aKpgLcjokQSJcgyQI= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Thu, 11 Jul 2019 09:27:25 +0200 X-Spam-Processed: consulintel.es, Thu, 11 Jul 2019 09:27:25 +0200 Received: from [10.10.10.146] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006322138.msg; Thu, 11 Jul 2019 09:27:23 +0200 X-MDRemoteIP: 2001:470:1f09:495:103:eb48:874:2dea X-MDHelo: [10.10.10.146] X-MDArrival-Date: Thu, 11 Jul 2019 09:27:23 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=1095f3ff43=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Thu, 11 Jul 2019 09:27:21 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: , Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= , Roman Danyliw , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Message-ID: <2A20F73E-F59A-4945-B563-8E6C9EDEDA03@theipv6company.com> Thread-Topic: Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) References: <156280587243.15387.3448756354265835528.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EAC9D83@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAC9D83@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:27:33 -0000 Hi Med, Thanks a lot! that's a very good "middle point" reference. It is only about= US, I will try to see if there is a similar one that shows also other regi= ons. Regards, Jordi @jordipalet =20 =EF=BB=BFEl 11/7/19 9:05, "mohamed.boucadair@orange.com" escribi=C3=B3: Hi Jordi, all, =20 One comment below. =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Jordi Palet > Mart=C3=ADnez > Envoy=C3=A9 : jeudi 11 juillet 2019 08:41 > =C3=80 : Roman Danyliw; The IESG > Cc : v6ops@ietf.org; draft-ietf-v6ops-nat64-deployment@ietf.org; v6op= s- > chairs@ietf.org > Objet : Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops- > nat64-deployment-07: (with COMMENT) >=20 > Hi Roman, >=20 > Thanks a lot for your inputs. >=20 > See below, in-line. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 > =EF=BB=BFEl 11/7/19 2:44, "Roman Danyliw via Datatracker" > escribi=C3=B3: >=20 > Roman Danyliw has entered the following ballot position for > draft-ietf-v6ops-nat64-deployment-07: No Objection >=20 > When responding, please keep the subject line intact and reply to= all > email addresses included in the To and CC lines. (Feel free to cu= t > this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found her= e: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deploymen= t/ >=20 >=20 >=20 > -----------------------------------------------------------------= ----- > COMMENT: > -----------------------------------------------------------------= ----- >=20 > (1) Section 5. Is there an informative reference that can be mad= e > about the > successful deployment on cellular networks? >=20 > Do you mean citing specific operators? I can name several in almost e= very > continent, but I'm not convinced this is correct in an IETF document = ... >=20 =20 [Med] No need to be exhaustive here, I suggest to add one single pointe= r: https://www.worldipv6launch.org/major-mobile-us-networks-pass-50-ipv6-th= reshold/. Having an informative reference is helpful for this kind of state= ments (because otherwise, this may be considered as speculative).=20 =20 =20 > (2) Section 7. Consider adding an explicit statement such as the > following > after the intro sentence that =E2=80=9Cno new security considerat= ions are > added=E2=80=9D: >=20 > As noted in the relevant sections above, the NAT64 and DNS64 > technologies can > impact the efficacy or functionality of key security (i.e., DNSSE= C and > VPNs) > and privacy preserving (i.e., DNS-over-TLS and DNS-over-HTTP) > technologies. >=20 > -> I will need to reword it. This is right in the reference to DNSSEC= . > However VPNs and DNS privacy, the point is on the other way around (t= hose > technologies can avoid the DNS64 performing correctly, and thus, brea= k > NAT64). >=20 > (3) Editorial Nits >=20 > ** Section 1. Editorial. s/today unrealistic/unrealistic today/ >=20 > ** Section 5. Typo. s/learn he/learn the/ >=20 > ** Section 5. Editorial. =E2=80=9CHundreds of millions of users= =E2=80=9D mentioned > twice. >=20 > OLD: > NAT64/464XLAT has demonstrated to be a valid choice in several > scenarios > (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions of user= s, > being the > predominant mechanism in the majority of the cellular networks (w= hich > account > for hundreds of millions of users). >=20 > NEW: > NAT64/464XLAT has demonstrated to be a valid choice in several > scenarios > (IPv6-IPv4 and IPv4-IPv6-IPv4) in cellular networks which account= for > hundreds > of millions of users. >=20 > Noted and corrected all those nits in my internal version. I will wai= t a > couple of days before publishing it, in case there are any further in= puts. >=20 >=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 Thu Jul 11 03:45:49 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C431200E3; Thu, 11 Jul 2019 03:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.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 BA7vBD-kiRnM; Thu, 11 Jul 2019 03:45:44 -0700 (PDT) Received: from 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 032F912011E; Thu, 11 Jul 2019 03:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1562841939; x=1563446739; i=jordi.palet@theipv6company.com; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type; bh=YOLYT9lOaqTO9+uMmQ17CA7JJmq1B59neu/sp6o3mLk=; b=ZQA55A02sTN9q6Fx2/O0pSxAw0Id3uWTCPXiJYt0NHZ4aUxzdBF2PHgSYNteD4 tCknw3U1iYjMR5vFeNNEJvHiJfbNxAV82xdmBNxCUFclx3gZakX2NX40ArTKR2mM SYK184xaO4jSKSGhr5PGWTbfHwVFhe0nBwxLyXAWaZRw4= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Thu, 11 Jul 2019 12:45:39 +0200 X-Spam-Processed: consulintel.es, Thu, 11 Jul 2019 12:45:33 +0200 Received: from [10.10.10.146] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006322309.msg; Thu, 11 Jul 2019 12:45:25 +0200 X-MDRemoteIP: 2001:470:1f09:495:b4c3:52f7:ce84:200d X-MDHelo: [10.10.10.146] X-MDArrival-Date: Thu, 11 Jul 2019 12:45:25 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=1095f3ff43=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Thu, 11 Jul 2019 12:45:20 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= , Alissa Cooper , The IESG , Mirja =?UTF-8?B?S8O8aGxld2luZA==?= , Roman Danyliw CC: , , Message-ID: <4FFB68BD-08A3-4D3D-8E04-6C5AF8D83997@theipv6company.com> Thread-Topic: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3645693920_1025268889" Archived-At: Subject: Re: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 10:45:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3645693920_1025268889 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi all, As I can't upload anyway a new version because the ID cut-off, I'm attachin= g the "draft" new version with the actual edits following the last emails f= rom Alissa, Mirja and Roman, in case you will like to add/amend/suggest any= thing else. Thanks! =20 Regards, Jordi @jordipalet =20 =EF=BB=BFEl 10/7/19 22:15, "v6ops en nombre de Jordi Palet Mart=C3=ADnez" <= v6ops-bounces@ietf.org en nombre de jordi.palet=3D40theipv6company.com@dmar= c.ietf.org> escribi=C3=B3: Hi Alisa, =20 Thanks for the inputs. =20 Responses below, in-line. =20 Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 10/7/19 21:24, "Alissa Cooper via Datatracker" escribi=C3=B3: =20 Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Objection =20 When responding, please keep the subject line intact and reply to a= ll email addresses included in the To and CC lines. (Feel free to cut = this introductory paragraph, however.) =20 =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteri= a.html for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 =20 =20 -------------------------------------------------------------------= --- COMMENT: -------------------------------------------------------------------= --- =20 It is strange to me that this document interleaves figures that are= numbered and figures that are lettered. =20 I want to make sure that the figures that will take part of the table i= n figure 13 are numbered consecutively, so the only way I was able to find = was using letters for the figures in that part of text that don't belong to= that table. =20 =20 =3D Section 4.4.2 =3D =20 "A new trend is for ..." =20 This will not age well, probably better to phrase this in a timeles= s fashion. =20 I will find a better way. =20 I will keep this for a couple of days in case there are more inputs, so= I can accommodate all them in a single version. =20 =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= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, 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 awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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. --B_3645693920_1025268889 Content-Type: application/zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-v6ops-nat64-deployment-08.txt.zip" UEsDBBQAAgAIALNl607R/CVFIm8AAEilAQAoAIsAZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1kZXBs b3ltZW50LTA4LnR4dE5VVgBOVUNYKABkAHIAYQBmAHQALQBpAGUAdABmAC0AdgA2AG8AcABzAC0A bgBhAHQANgA0AC0AZABlAHAAbABvAHkAbQBlAG4AdAAtADAAOAAuAHQAeAB0AHVwLQABPXsYxmRy YWZ0LWlldGYtdjZvcHMtbmF0NjQtZGVwbG95bWVudC0wOC50eHTtvXlTG1uWL/o/8T5EBhH3HrjW AJjJ9IuuhwEfU+WBMvicmhy3EymFsixlqjNTYJ3wh39r3HvtzBQICnff212uchUWqZ17WHvN67fW 1tbWbvfzWRk9+s/ve9FFPEmq6H1cVGmW/LZ2nlVJkSVV97SIR9XqI12Nk+j84nY/Osmnszhb0EDZ MBlGZRVX8/IoOs9GeTGNqzTP4sn9s5pPFtH2difa2dp+tXb2bZYWCQzw+zibxwX8Zgd/s7MFy6bH j4fDVEb9cHy1v9vf3d/907vjq+g0mU3yxTTJqujneTpMJrDCMkqz6OMsKeIqL6I4G64tn8cZ7sWs SMsk+pBUd3nxtWx5eogb1U2TatSlU+hmcbW/2x26l3e3DtfWjq/LqogHFc35apyW0TAfzGluw6Qc FOk1TG2c3/ESoo00G0zmwzS7iWQ1m9EgzqLrJOKBE5o4rAU+pH3PeIad6G6cVOOkiAbJZDKfxEV0 fnnRia6LPB5ew3r5n3mBX0/cAju4FdEsL8v0epJE+axKp+lvdFhlj0/XzTeelHk0TMvBvCwT2pG0 LOcw/SrH+Q3gK7DZBRw9TCWLxvEtLgMn2c0zOFl4IEsGVXqbVosOfr1IbuIC13oUxZvR6YfL/V2Y 8GYUz2aTdMCTgBnDym/TAb5nHFfRHE5lksL84dhh7F0cKB4OgVJgUvh0lmdd2pkBUOQkjWHmxxfn Ja90sElf4gmN87IqZUvsO3tra5dEvFE+4jN7n0xzf4K1uwKflPPraVpVsHQ4mdF8MsHFEtlngyS6 S6sxTD7BAWZFfpuWvLJR9PrkIjo4pJnRj6969JbwBWUUFzAIHDLupx4Hfb/C2ycPA9neAKEnBTxF U43Lr9GbvIAJbJyfXb3ZhPP8kFcJb2NOtHJT5HPgH9N44U63ApKcVzTX5ivj+uKVSCbwRZzQYF4U SCvuKRxHVgH7BC8eV9WsPOr3hzFsMdyMr0nRw0vUy4ubPt2psi+j9JfvBj1oJnYbT9JhNMKrDav5 lk7nU5xOmX6LpnlWjYlccZtxqUCs8xm8Pxl2gAZnk3iAP8F38+syB64Ix3i9kB0ya4cbAPwNxoE7 ksC6z+no0wxIp8jhNsW4tzkRaGPKJbxoBHcDyAFHAHYI5wQUDC+FrwxSOpZkKi+FE8rwO+t4AkhS 8IIbpPDe+lIqvEuB6hLimVGeNZgmbOVJPlsU6c24QjKAC0VD+Q834G4g442QWKKrYl5WtGNIY8A3 SyRZuN9ZlY5S2KG4VJL2DGJejfMCSeIY5kKj4rrLpLhNhr0WDsg35+/AFHAXzGUgunbT+KmM3gGr mOAAF/7+fEomcF+BPuG79PCpnhU+uKGEVuEQSeKJDO55kpVJN4Ubuom7m4xGOAXYNXwvEgbQDl3W +bUyBb5tZvKwyotJEsNhF8Cekjv8bum5Jc1hAKSK3GDRke1aOKYfLfJ5oXuES4Z9gqs3YKZHHAM+ mcG8iOLyxstP8mFCQjfPiDyTbyRn4GRGRT4NH4+msAUgNtdCoW8kHsvaBtXUZd5fL+KbJNr+svb/ LFUYloriFllPcn6NBRqKvSS6TJFnE4G9vjyN3vFRRRWsDrdQd4/47GVCuxXt9vS88PiYcIleLLHg FiPjIP6L6glucT6HexMXBcgIYIB0ZMEbcLz2GQE1X8UkMUdwCKjywInj97d7xLCKfDjn2UW9R/4n il7iQDvw06fk3+dwLsx/3sXZzRy3f/WB9nCglz05FHsYl7CKuEjzMlp9IBwKl/eHLL/LkCR/Re70 uKXtqyKFQ+Fgl8AcYEv5qEB7kKnSBSCNYJWBdtoG+gi3ujCKVKdt0Cg6tAO9XH0gpB0eiwfa3tE9 2mns0ecMx7mE24w8H+iFFdfWzY+2d/2Mdh7ao9os7hloZ+lA/yIjCMGT7sSqkQ60bwd6+YiBWNGq K89A0aiHiOa66g1x03hJUyB7g46Fbqmj51UGOsCBdvGmWgX2xCuwq87oFc9ol44JFn95duKGEf0V Gc+F6tfHqCrEA5AU7QPxUNusqYEmgctbfgtaZgTWkRlox8+KFCS2fe6QDwLfum/gaGfbDkRnXs2v zTArz2jHDoSbfoKCQe8iMuRvC9olP/YKA+2hlnHyjnTOSUoM8mkz2odP3oMKB1vdxduEVGsMinsH eqnHLxsN24kL+ZTcgr6U6LArzMgNhBv9uTTMhjaq/8BVbxkINxqU/yS9yWibHymDdnb9HjF1v0fV gJjXKL2ZF04pun/waGfPDiT7BHwjvY0Hi/5ZNigWMxrqfTIArTctp+UqAxFBglymLaFN/+Xiw2rC bGdf9whp6FewlrvMrS9AWQN7YePXP1xsRrel2v5d4tujdOAe+HAJD9iBkIaIbsQw5VvvDNGTwBC9 b0YHMhDbp2/FPkW24Q3i+5Z2oAMd6j27AuWmnPBp1TjTSgO9gn+dHb+vf3dlOjp0HHKrB4oR2ORI 3CfiClh5KBkIT+xyPp2ijoq05xWaTwkMDT8NZYJoCoaqaDAQnpj5NozFMhVEV4v3p1VOvyQOeUDS EAzWFFTIlTc4HIguLZ7Y+fGH46cNYgbCEzsefAWSniTDG1EeH3f7eSA8seMPH87+FB0fgYUQAxGT 3HjtXEpmB4mfh1uNAxEb2d7WgV4fMVWe41j4vXg1HTl6SQS5vaMDnRxFr8GYHgMlfF2FxfqB6Pi3 X+pApzAj4Ds3wOrJbupubaE60N3a7ne3dqJ7B3o2g2rn+Q2q7V1d4VljhTu8wpfRSlu1pwO9aQz0 kgfafWgg0m6293WgnxsD7fJAe6sNdKADvW0MtMcD7a820OHygfZ5oIPVBoI790n9O+XjTT43EA3F 6h+5zG8TO+5jB9ohW3T0tKGiXVKTjsmn81OJ3nZUiZ5gz+7ura3VzWKiUXSyon9Efd9//fTmZH97 d//LpvGNxxRIoMdImKKzR9y+lZFtU1Uf0BGeDsZRPJnkd6VxP7NJg942EBTzDOUpezmRc3mhS96q ohTlm54rq+jz6UUnujohD3p0fvIePesLeGlMflzyUqL8Z4eRUR/LMdkonSie5jDcdD6pUmSjtWn1 cITP2QQ3mFyAdyh+aOHko3TnJqYVOosaHilY25ryi2hjNM9opzdhDvl8MkQLJ2XRRh7OmPYiPAL1 0SXB1oqfeYa+2ioaJ/EQ94denCWyT2zv9XFn6icTT25ykI7jKRzqCLgkeVbwqA9ebe99YceMPgKb PWF70Y3gBg/UcqaCffMJWRBok+LpxRRfGOVIAzgCUdbW3s4XXiGr0UpvB0Bv5MiNgISKm0QXXC4y 9Oml5Gk/hj+w7YO8GDKPUH+T+7QTlXlER8o6AzmjreI2jUlUoX+Y9WbyIRMJsmsLdHXYHVhafJun Q5wNcSSY2DUQRcdZ55aexVuqFGhpmCZETkeMIOFrYyEOpQ3UFEoX0sGDoWspfrW93h5O1O1SB++i qDpdtiKN2YZLwylFY6Iscp8mBTIfmjdvub44muR00nwcb/O7hOaLD8r28ERh/D5sI395hq5kJPNx kVAE4O4aSLI8ojFiWMvrZBDj15vHO82H6MIrxVoo74BGOCAk5nHqInz2HIZwUwZVVM6Bn/AQcpad tnfEztExy9EhmOIKo+siib/KazoYxAMdFfcKb0aUzafXSYHrHcUDsHyRiOBlOg47jWmz7E2s7eUG RiZoZXzuEtHCP86k7mD4Ar8Lb6dj6kS9Xm+zQ6HHlA/tOkkyiluhfYd8Jx3pOPLNLtNcWppD70RJ NeBzvDZngN/IEthGmLP1Y9gdo0AsXH7Ue0hC6evW8T19c3mi63k6qbpptu4ZPV8wkUrurnbMlIFA JdwDr6FYpTcLrLQh73yK4aSkzH6q6P7qMBTKtLbdSsFGcjVfJxKJwz+wJxICGTh/bDwBBtqh25/l VUB54qbGG5dP5rQFOPWGS01DmCGnIYIRH3dKdCauNhGNRfJ8uuvL59dd8Y8Ei4UfEmUjc5+pw9Hz wXgAgrHUM7yLmzeZw4JwM4Azqi1fisPQ0cEu8DflfDu97U0+rOPr/NbwGqWnqgBaSkcgEwuUw8hK TFDdx+SZrQRr4QgfftFFcMt46r2hGBEcp8Wwi48s9GMax2gcS8LqPYmwwX//zvG7KBHDjY6eY48L opYFzmYaZxrpLNNpimkDoO8kGsOjmCTFW93R4RC6i7JHA5R/EojD4DJsx6DIyzJUTwL2vp5LKsY6 XVj3T13veidar5/5OnNsnSfcHTz1IuH4EWw+C0wKy5BSh9ETYFRIb7QofHHzlEpgoJwOYkfe1K1U DjJhYUojEUWtw97BBRgSY4RlEdPVMdd5a3y8HYgl5g2VOxveS+RVIi5V4xE+QxNz3G1pEOygt1MT 1mU+VVVmjdNVDA3fIgsd94zsTSkcO89AXGEwH65IlQ9jIpLkm4tD0ulqpofOdJzejI0o03QN0uws W8Jvk6wGZRbY7CKpmIzhJsKZDdGTkndYxa3RTVpyfPs6kfukjnq6AXgajYst6SKo+twAGwPODEpD WgnJYv5MPFmIcmctjN0+8fOpd0fCMy5qyBoS7fLh4asvbUHtSZ5/xeNF/SEdkeZe+QybhvDhoKNj jG76ncinAhHbp60iSbSxi+IfFw2mWbUZtZCvWkFEWCRcZHpe/RaeR8oNUJUwaQqd8/oODlA0wtPu cm74bCJKppFMI5qBuVn2IkiCEe9fCUfh8rGcnsvDcyIXZxTJtuagYw5LIbrQ1BmlRRlsNVkowSYv 29hooyTHMSxs/auG6Yjn0FTDz3CQOUXvSoneDVz0bh12hxeGZxRHwG0GX2mMmySD2zEgpQDeWeZE NRVxJjYEkbFy6owkHTSTwvBjTbAaU/IJDmIYJcsTmh0QcIaXwVAc2PwV2mn0Xbo8ZBGLas6mGBBJ TNce33WNNmUsAaq+k49IZwl84m+YHC0nOJSYCXMMVMROWXfQxH2KmlMWJzmEUTAkD6cFB8eW7zHa FcTGiG8PgKa8rq15GfMyVtssoIR6SpshPcw4Qr6t1xdjImkWc0IGsoAs+eanzBuceEdnbLLnDCXN g/gMXwYWoTSgy/LCMce4RlFAyPOZBp5PJnQyhnf2X4ExPAH2OzTbmPrkySi+xhAQMxAznZziJy7B CZl1kZK3ANVxMRztjuFT5pWF8FQ3sWLxL2w2ouDHK4bLrfGzUB8YNEOeo3mBWzLNi6T+fvi5JkHo lnFGll2ZXwrHU5I7vIdI6sgXes+nw+4+vw5LThT0JlTtTKgu5VTPGIC+WZB7hhwDCQo91dBIDMRl N+5q/H0DP4rjy032l6ShK4wvl9dBKlENSXt1ktMpNUDxnt4N/y5F6tkHXZKpU6Lwt+x8mM9mIJYw A1hNF+EwcxYNat3rnqrcJ8pAEkeJPABG1+bh0qtB5G4YrOerhkpld9o3p+NV4rRkY42Vgt9w++Ui oqw87572JtPxTNJ8/WBd/3rRBDB2A1onvBtZTDh3ccOhMMYERGbbeU6euJgFozKz2MhcZL+et5FT YoCPsnzXFVoejl45GShFIwOkmZwSOWHLClaGu+39gmic8jRgQhP9spcstDWivVI6lHODeB2lSCbJ Ldq/PmNyQ1jzLQg5Jz2s5TMFCaokOGxG4/qGx5I/Lx6kILljTpY0kqTI0QT0+cT+bSGfGiZVnE6Q cyzNrnKX92tCjjzQP9bff768QoME/z/68JF+/nT2x8/nn85O8efLt8fv3rkf+Amyai7ffvz8Th7B n/yXTz6+f3/24ZS/D59GtY/eH/+ZzR0a5+PF1fnHD8fv1ptsA3k0p6/UnLuBlfD65IKDQsT4d7a3 gfHjT4fbB7tfyMfBehq7L+mfLAFmswQuOdoqkwkL/BkcwITZAhAQ0Bb6WWBH708zW7OOxQOffWLc QR0v9djDZ1Rh5zYj/pGt4BWzpg3I60HiErDrOZ1xZUwNSfpt49i4P06xRDOWbUrVw8IMeNyxQYUJ E56RwspmmOgrhpmw1Cnr6Eqx5DMs5hO0bYAVAu8nxlqkN6kvdOCl0o1uZTucsDsjr0DSpJmUM56Q 15P6mTNfbjU94miU3KHoJbMiMBhh/wrUjHnxpNyycgkbMB+IC9BZhU45p20D5ssp7aJdk8ELyu6U lBk1NaNqMeMt4VU1vEB3ccYxnWn8FX49L0TSCbMiip0Dl52iJjyObxPjStKcmhGwBPhi6Qx+crEY DUVlnw8n+JmWjn/BYsoqXKX3TF+RMxLvqkShnFIOO2cc6Owm9t7UJY7HILvkcZ5HP5NmHURorV8n i1xTsdXZpGOCBfc12kh6Nz04GCo7YR2xqRds+piSo785rYHicHAJy6QK6GMdJUQ6SGe4JHSjV2lS rh89n7a39wOi7T3yKdSdks6/g3ravmzFjntWtj9Mh+yzE79fWhVPvvqSbK0whhNt0L83NTRYvyP8 zV36Zj1wQP9+4Jt7PN3kG3npJ807mGt6LI5RmxvHb2wUoT4FGJe3HH7g6fBrMUFHT0GvcIQ30kUG 0R+BJtVm3dVGfAeeBx4WV8gS5hzbQtUj0ZBeqhprIv4FUXrIpdJxd1O/Svef4iKlltGIRzCu2BXD epGWNpEyln/zEVv5MsZMf6qIx3gbiyUFUg2KqpsJ++vIiyaWGDlzi0QjYDhreCcaV24rqchEHf/0 Una2iYtaAjJCjmkPzHZ9G06UDW8XdKsdkxQzZH6m10gut8SWxN3XIc2WJgrTM9feXWwjSkngiRMG psQOE3SuwOwxFJxIVC9IN/fybqf+8VIfDSkmjaR1N7emPSYz4IMJXEFawyHsE00zqm7ih5Jv6DTF YinHMiSXxJsjqtOXPmiOTqCzmK0QPFW0AklOGddhIcrHgDRu/AkmS0oEayAVx+uHSZetqxE8BeOg TAYuNGO3E9EoKR46CdmalZLwpQ6Lt8iHTt4QUUfbm0vEM7GG0kevfXqCFvnU6Mz4U+WCTjGkrJJC XxyXTiPiAIiqXawurfngT1H6YLLNL/E0HmigY1Zu6G5rrISOo275oLlDN00W4aT2VbBDxCNwEFQy kJDAJNbRKB7JkRwn4x9RzFiycyAug9HCPIBlgn2c1gV7TWCRb+XZBO7+jwkR4p8XXffnxaqf2e9/ b/nxuxJp+Jn7sf59Oh/zCnrpi/C1LzRDqOX7Le+XPO+H3/+k9S8tfdb7fNTOAI5diKHBAnY2nchM R/cxA2Z0k0XL7e84rlDTImwA5nqhjvB5VebzYkD6+A3Yiz4NNTbqilNmXECzxWEpMnqGlXz5vESZ CUPGs3HpXFDioO6wwc2jUNyW9X+uZOySP3xt7YGa+ccQaNufJUTTSiDt31et62EC/RHvp5e+ePr6 V3vLIy7Li5UZw2OYgF7iJ4/76Iusl/HIZ7Mv1dsDSWsi5RJLa9zwl5voGGLit5ePRFZ4/yhbqH4B xeugiS2oE5i7Lp6uujoQRR/RdcNRBPVA3n95Reddcn/1+j757rYdyqNo11y+70+4O/xwKF0ec3f5 /bzPT3p/y+V99N2tvaaNzlse+976Y+tj9dvYMrfvq8ymTg56F44aplLaInOeUYU6eH4V6mNGOSYK oWJYQOPu7y6T7ibW6bT9FgGOAr+zROeXHCkyldoEN7OUvHD+uth79z3foeiPelRNFlRsdXEO6Ygx Qdkt7MYWQ3b9ZpJfx5N1Eu01buk0EJhoQksQJ6w8yBYaZgEhy6mSTLQMNvsxzYrtZpheWkju75VL a3FZw7i9IWfUsG6LsUS8zKdf//qHi2ijUc62yQllXl/5cAmPLSlt2/RaUjuX5fNeXUu6l81+HMFL 5gWC0AhVucNvkAgf9dDLlxYCJBMzQ8cyvl2dWrHYyRzHDPU8dGnTBgtpgO2eDpz/xBhyj9PpHqM/ rT2CXT/nuMv0nv9IfeuJxtk/qpepcfdU4+zZ9LfVjDPlwUdhkT0YQi0C50loCOwhFvFhkr9sFQ5q ToNxivnwLsri4nVakGNTUTUHNPbZsHnhvJFp1eHUaon6S2yB08CRT6KTF9MIFEKqJ2kyh7smTaac 39xgxNslm3P8STIQ6GNKuvGMxMSskkziRVJcYjgKrANePMdVpNar76IbxsmnGEV+4KFmwbZtaZFM sA5BYpggi67TTIORnH4kfkTY3Cof5BPjCUWPpfrCu+2+cJF5GCOnYiJamRTLODe8+RKQ1O7+Js+Q 6nE2fYaS93xrhqv4enUgGODkDF6s7vmzIWgqn0BGJ8Vmx/mixSO/7rz4WJW6LsvVsID3O4l7lzzH QrzNtV7U1uoqmHTMILvfrshFFHFesrx68nHvGRW3w+dX3DAK9HHGahvqVS1+TAb0wnQ/SiXxoG5H UaxbJM7/oFSr8ooHBng5VQSF+11uH3Qp9kw/LzgCJTeaQrmmdMMXnrTRkNxVLtSjIpYNCg9SvdWn hKzMhKq7i2HZCPVQagkoD3KQbRcOdn6aZvkkv1l0AhC2NsJKBaeLM7CiC2KUYXhHTdV5llK2drVo T3fn5MO7eBEO6ajUF+j17veu7222+9OYB5UBUARnRdUyIdh3xxFXyRMYJB3judY00yKZxikob3Mu RNRcdS71M4HwRtFNb6kEoSvKlRd0C12CKRdizjw4HtDs3zkER1v0ghehWetHBIiigHTs5bsHJVBT NCxQ4EqO9eUrcRVSEhJMpb4Lt2wSygkSIfVAOCZjuuQ4zqwIZFMnuCU+Ahiuk4NwA2XtLJbwS/oa WzXFxVCadkJ5Hkt37d7dItF834YB8aop6YtArAZusmpJ7tV2h+gWS22cKfAZWcUZ2KQzukwbn882 TX6Qphz4hB1aBaVNcHQj9fkVEjVV6yGmYJlBDt0lXmcXoITO6gizJjk5KqocTJK4wEOvTJlxEHPh Weg494RZUMGzqbJxWI8ZOQr06oTggc59xaYB+TSQoIHGVlLBspOEajSeSMq/j9iL2nTmA7iqTjkj TzmULWHpOPMfRIV3K3BAC/MCQRiKKpMzBswkR9kSyKZjvhKSmOgmK9WNjBS0ATs0SzSnALdnb39n D4WehuNpo3kj+PyA42FI2We4IUdHAbOmeFRc1kthaeMD9RY+xQ8+usLsYY5JZD53Ga+HS3TSt6EM hiXEg0oHw2zuIi6rYk5H0tPd8GgoEWizMQxdjqUYYAKDhHt0LvfjrH9yJu8Oc8qJXVPhqh4yX4CB 5LTXgy5pJcPQhDmOqAEaksK4oEWgDjgXBf0et1W3Uhb/jLnZr55fgbLKuimf8P5lxQfgMgVMX8C8 0xQvESzpJ/YZYA5YUksMcykaPr8QrsNwHk+68I7BV6BceNtRqzfhRWAW9ujnXquRLb9bu8cFQP/f l3/8reVB97u1cFD5NmhevT6N0mcbuqvD2Of6Emz2w/Sjd1jZzc9+jy4/vv1IK9vQsB/82eziv9kK 55/N79aC2fFL7aLg3yPUa+EZese/0XR+0mf1dzQMDnyKe88vfSHOgO92T/qN7en7363psJd0eDQt +DYYPTqpfyNnxk86otucvv/dmi7kAs5elvadRVGLC+Fv8MAnSgj7W7/uU7Br/c6sUsIB6lN50dw8 88sHCeY7+jVxk77Xd8/8cvf7g9T7PbLrC/fPuF1WiFVIDO17uIWrB2leBDun90406+Mj2Or6hXU5 51xPANeX7mzdXRJkNtU4RlyNy44pSPBVhcQESmWhjJFAUAQ+/YgwuQuTO0oXqqvYJ0wb9E+c/Q1p UYqBZvUV5xGP9C0+rXTZkLtHBsWOL6ix+nwSqfv+bmNKqKa7fTGGhCoagbwqCVpsAwQC2VYOY0aA 88pNdtoOU/YkXLv8Uw/9+opqGkDEpdkAkVW0jgST0bhulZJ0QC3wnvoi8SXijKlO6rviaLNL3els 1h5CvzIcUlJUoPVXC+/BQG+YkAlV2pWUE01jDOIZZmDx7g3v2T3d/Q5f7dYzkENMlg1jRA0vAze4 TYHQqYdFaXwgtU23ux2oAfQG68VByscliirfmD2Zg1jzmQxdUIM4Nu6ayVdmChYcY/HhiU4G6n8l HjOvoXo4HJ9o6Vz4MnksVjBZdYNxTsQgaZ8IAp426ocS2RVNh/rHlRoBUN76PzsjSpzmT86IkgD1 kzOiWLT9H5ARpS6Yo8DLslpK1P5/k5Sof2ZE/ffJiGphDI9hAkszolou/D+aEaW3sO3q/ktLflSQ F3XM2bWdFXOjDkxu1AMXcdXcKHUdLU3JXzE3Ssd5xEVuucWu1v8/4CY30qMeeZNXFzUrpkf9J9/k 1bKj2m7navey/abrjVy7NzNK6f++S/ZwjtTz6FTP3ZXiqf0AnFZKAQ3v/Wz6T5V9HG52QlAJhaV0 Y3a4HEKcsw09gkPZ8kSAaJdROcN1kX/Fml4Ol2WcDyMV+YUHx1M35cBifDOGAA4Dv54Q0hbVkbSg WTRLDcQHSoEHQdcAc4D9mgpRQ9CLWDCq5RvkL4uO+875iHNDjKboLmZnJfIm8kFiixSMaZWbzkp7 CxNYRGeL5Bp4Yhnd7nAU5/Dl1p7Eo6S2Qwx/CY95o/U2xlY+tuWLd3iXHgSBYp1C1xQ+GTo9zpW0 pyXBOSzUNuELMaNcq17TdNHQoUASoAlrgTLSimv0vX2iE+uAksmwe7mtdGa4che40ukgtF9rHh69 EVdCvnTe6usE61+ouCy1ddYeHLM+QLCv9ahmZ0kaVsdUVmW5D0hSkY10wKnHWDYsIF5Ad5utNS7k UAniLx34IaUAkivnyUOsmRDVXeKGa8pr20Jhj4+Y5JSIKVziPztE0hYCkYEeCIQ8GAKRYZYFQo6t 1wHja6lCgg5Wj4/I1YkH4xRYloR7hN4Uu8QVLHI7QJz+5aKsEoQEaTaD813n7uUshpvhjRdInal6 Kd5h2MDGDFaLFPjbEmReSnF57c/ziNGdH+ea+Gek45+Rjv9ikY7QxfX0SEftz+qRjvqfMNIhCubr xwY6msrsf8VYhxmy7nOv50p61/vzxz/ucbe3Bzd0nPtjHPcEN3SAVWIcy4IbwRiPiXE8adf/GfBw AY/zinKdtWtZRr08hwbhzWmbDMwGeskkcYhJ9FbSn4NMMSYYv5cbTpshzUm6upZpNafnNztsG3is 7yD1m4t5+H3u6sUCdMInyMYCcQW9La7AJ+O8Ep9eKLUyMUEakcE4Rf06ziqXOc7J5KzovTv+EFS5 83Za4Js2CH1OQBc0J9MjQptxEkhLzQapAegKgDgOhLiJBDaU8eJc3qMWOtWVz5rtjGOAtT7EnHmP 5dSxbkK/DrU3+BJ3NCZBEM/quosGSqUtdxzxd+iGm/xE5qzsCMVQwfOpmD8AMtxBDdr8UsU7FAxQ zQIUDF+E9ZvhegTXD175DW5tF5hHdzDMgKdhn74v3qrzaT4aY1weU7QBReKJbTHFHx+1e1SpTIvD /lGlMvc58f8jo3bqVQudknWVZuXC51fGuc/35knRNucVcpLOduFYqbS5xXfPtYrPU9r8zyDcfyfX vbkpr5bclPvDZI9pdPtowKVMsv1FpDG8+U1GCInIREcjlHeU6Xqbi+Ouhq1D3hwpBa1AkvryMHoO FgJyeVpq8cb6YJKXyXDdwkd7zY8xWhmlyvakV4ciOQx7LYnwdSQnRs/XIhKGbWLIJta4tN3AfchN As6Jjtm1Zvovvi8dYKOppPR9xxkW0CH6KXwS++RRu1APvvFUS4mzA5+kfax6fPSrNiZ+ADpq6wHs qLjJLz1Mk+PIWV73ZqtKxGCQvWd0kP0AsOhmcU6c+T7MtjFzWxVBx1kTgi0sUJzavqieAu7qR10z Ear+29rb+tJhHZh94jAC1jmYrtASUWDDg+oPAqFWKzm64utNxQolI0KTem+NraCNO4KRhQ2hfO0K FpRYe2OCVkor8mvH9MOSDSS7tbY5+TXqvqGlgcjPtptXAFnmSOsaUe25ZAZ5k+sokXzDO+tuPix+ XR5ZNzaZpAQ5RAAHEsB4Y5z4CE9Ud4kU0/m+Y9i/BHVbWXcDQpJsEosYAF/jEBlhudoeZh2fjrAE OGCNKzzvxQtgIpCwXeMKt9xcF0ZaCOyt2XnMY2qtXZM+LNxMeaCg1dR97nrh4BuImjthgaccYExN DBE5Gl1GvlMWS4glQVXYOBQUiF9HpqG7Lfj9Txd/iTY+SfQxusjBbFtEf+HOG2RZ3Kbf0qQ7zMpu MfuNel0Rq/Xqpi4xnnDfHhm14zHnAry5NNMeYsTymQB+wy1Atkp9jkiPLPPO0nSzVIEHWYGFk+3g mzR+ozssGxJumm4Yzm5QJNI7sSowAMTNPHxjI4olFwvpCIQ31stAJCfhGUB3Ha6kJNeT642IO7F+ myZ3cG+4V0cXPnKxW4FqZ8zyJUcsTRyZfH5msa0gwu6OmcZjHYPDwVDCCZ4rNu1B/GPWsisNCDbv nEWBZuas9CxVtqbObYOaQZRTTNnxITNBQ2clQIWX5/giAnjsnrsUNOuCccxZSfiKTg8Ybzon9Glv mCCnVrAQthsINn04x/QhCve6/mcDUprkmjK3o6o5OmsaiM5a0UUpbshKlFOLNkSdch7JdV/mii2n 2Pcb6gT6+mfDSFRBlsqYpYhCUvykE0E9qCwt08ibdn/Z3g+GIPxvhnIRAhBuHbWrks8Z6Nx79nyh nXbojQC2w+hyIq7v148fwlZt9SiAqgR7hgrP/cD44UwEIJ08u9Ju8T5x7FiDACqloyVZJTVACekk EL67z9EiOzkeltKi2Vej62EQYjYJxR/d8UgAlQjQ2cw7hKfJMJ1PuwgFgEJS/OR3scdqlqQphWKX DGtuyEZpBIEm5tKyM1ckrwjJqp/WzZE8hMl3z4W6ZcdmfiGfDAr02xBmEVi2XAFZdtV67qD639AG SV4H1kCpEDhKezZEx7Sl2960pq3OktpOwTQbDWDt2soKxVvLCoWFB/zbxTWeiHf7X8wZGxTO/Wdx dMfEjhpM0DJA5JwvH8E5W3HzH+CjO0/ho6QQukS9WgDINez0A7hsqRaG6RL6kKsxA+H2dZP0a+J0 H1I+qzwH/Q31QNJCuaMFN9awK+5I11iUTRqw6fjKEMaYqDNwTbQKMqICv7cFQdNrTA6fjoIquETH ALKu5CZqDUw60fYVfM4a1gzOVmsehq1JqTO2+g4YaH+eqYbNYqqsdasmLPMWBrmUifxDyuVSsO8V uZVjVY10s9XRuZ9HDfq/D5y79bNlfHBVzVj47ZM1Y+W3P4CPOhZ2dD9DREaKbPSEu5LJFQxbMF3Z eg9uXyZmUTOrOOgDZPtrUmxas6TLaIN9UplJavTQYfABGJk0bCKwlWgXhzFRdoARZhh3GxQXhI+4 Dgq8n2nsU4VYMzqKjl1kjq9Uo5vO73wqEN/xPl5g+8Xg/rnq3/a836g99/d3LjfIHUdzanXFxL+K vvA7lz3zJi+S9Ia076PovAz5czkHCUZOG9G4MYnfJLO6GmlKK+gsRfzhbskqt37n0mxs4jH8c6M1 EXnTro6T+iXpN6iJNgnAzbRffuWo5wBQevrKRwCibOIG2ZQcAkYh5o5b1IJkQseArBrzTOQjCcfg H6wxoBh/o8bgd17FQBn8reKOrpqjPJlPqS+ENmmxnlof9sL0j0ZNll6NjrpSBTaW3UO9WgYeUPhc cEsLny++3l13dz1av46H6+KcxybIcnsc4sz6C/vwTZ7f//T/enhoH5Th+nvnhnUYOyQQh8bvbLLk 702tdo4j3/OkE60P8jkKrWkSU+0Ldsvz/rwod81gLBCvdi3UINstCGsXY6NTlNVI+xDGL6StpmVL p0qOW/rWk7WGprHv/8sZjqU2B9ZGq/I96vnYaywtlj2WybjKCo7NoCIA36duQVlyw8vlzCguA0wr aZfnUCZN595kWFJOKVz+Am4lDI+tvst6gyCP9G5a4ZGzsUIFFZNbkt7z6SA/AN36DaL5ZQjsg+G0 sNk6WaNYFuPKIOrpYECOJWPIOSaieaec71izmW0gUvid/2rY9UbqudBBI/ybX8td2Ul2qTuiI4Yy ZodJqkfFDl9utckXI8wGkBSGVf7a/1kjNeYc39RXhQM+2Ia/O/D3JfzFgsg9+LsPfw/g7yH8fYXP bOH/4JPbO6z/POOMxP/hNa3uPX9fyN/wf555RlaJaJ3Ri5a/9Av3P899as6oWLJH/+EzMvrLY2f0 4sfMqKbUtM+gMaMfSUc1nef+mfwv+fujZvSAO/7lkZf/J76nvUtdcO3bcrQXSnLI3iWm47FG8NNQ zEzn7Dh1yRpN7RidoIrsotaA03kCLV0/VIu9xqTtd+7pjqWZSrACpzt67Y10F1f220DwxF7NLsIb +NEpFboJnBqNkljQGUm6ampvzKLAZrb2HFCkR9hkSE87Pc3P/5okMweXmo6MmztUhlBmSf0vGh4n AmwZUxzZdd2NyL3vG7RIwSvbRVVHubSoVVxtLDoVTpA32kHINnztkkEhOZBhm0DUTcmWBFXPRd8b 5oi2xau3KVetQaICbnszV4iM8VF80o5GXrI3qcArC7TClFs14uY25rSsQJHhV+smS62Jbtt8w+Jv 7uStcd4yrFBtqM690OEYZ+zp6ogi68IqrKd7Hdi3LG7URfaeNfD23JDY2Nv0nAuGOcZy4hoCNn0e aHIld3WXh9Qbs6c1s4DgXGhhAXLgn3cxwYXWJutVZZ92R1eCfTGce+gbk2vzcrgWqHVe43ljPjmW SrgkdupO7cbt4WK3nfPDLVRdp3AHLtRKPJYxkrJZXWs8u4ea/0XQ4dISluI3czA/Ftpd2r9l0+dh MTNw8AGsIZd3lLbHmq4HIpB+jEOTl1aii5u/7frJy5C0a0n8NWiteI7ZGAKKLDeOx4uze3LjtBYZ 2RG7nXKEbI4y9D2TXSAT+43K0G1aHFaswDaUaGHR45xW4rpTu3CYbJpmXcFVmE8qgac3CU4m/8r1 dufnW94iViV7AmiZEo5s8k/N+BqTpUmfo4GXcllxgS1ZJReVE4Yy3JRS0V+dS39QLGZVTvnlkkHl 7BEW2mJsqkPE1Ss182/MOnphP09XryZZiOjNT/PiCGUuhzja9sL1nV3H7gnrupwB/Iu8QkgThq0S w8y4d6giTrNtbb7lkgK5gopaUghl4/dvgqyhhTTu1TMwgWKUDWVC6SUshChpuINW2sK0q29dmCYP 1ryWsDGafYbrGMUDgtPGvCtfbjWCO0kZna4+nGkNFkOUxsl2FVGFHqSUicWkJIWPuwbIlBCk8Shq RxGWOY2aWy93nNhhNwfxx26tDdu8FQ+A+67KHpYtQffcSfDgriiYN3VR5VU1Lhc/66t1rhPbjt3H y5Fm5cXEepFAUCRQ5EwbGNB14BWi1E24Z3uICG2vZHsKwQYnDpZJ5aCYTz9G1yldx23HLk5O9bOt zZ6PYWqKVOL1LnmxnqZIsbiK8TnY8CqeztgHhRyUlVxKhOALwd0O6svwpX6mkS5xEmId8A9M8uI3 sCbCMctJOiY9CLtO31GbKZu0GrzCpaPSlvZU2/MZg84BVXIt3IYJPGA15RQEtPQTj7AuC36xKQ5Q apTCLOXa5Uts/PVqjEmKXZqGuhAvtSyuTsXkBNYjWsaNmcvynO1vQiaNclGBWoA0UFPAW0OcgbPu mGR8fMJQjKd0F0uMck6YM6RO2+evh9WeUduux1PZQY91iNRZRyBgjA5QRi870V5vT8XIfm8nUAqU R7kaOxS5WNQaZqf4punMY1Sd99K1fD4d8geggkuVoK+tDGpasfLyhtoOeAd2M7t6zaPJ9+ppLdjm aO7lUZ5VRT7RfwYap7bayEX1U03T5nCRTHXQPjDtGaVbamckU+N4PZMCx3QGOhL9mvKS4S8oxV9c +rp1n+tRa+rOnbSZRvXBcAkqLZZWFckkp+xhRzYes0oIPNcK8mthD90Yrgdln7J+jc4Cy1HV2b0w SEpIoNRgCfvoYba6aUJCnB/eh7Ol7HDuCu/VDhXY5FSlx8o5FssgE8A+GtzUwckgN++u8YIDc3AZ TFijJNno+VcyPkhplbpaY+sS8MuML9vINxpCgZNzIjx8EfWbspoPvrJaylTsmH9XKAOt+snQN3Vx By7KfadmRNdrCIMWfTxJ1C8oAoHmB3e6QX9AIxwLb7YylaoKgavGCyHYtOKZe7vqLl4cRes+F5yq ojXYQtoBnjfMSNIgyGJZ9wYO7ieSn6pqmtY3cs1StEGNxEfIydBwLZz5plq6CxVIF6zgTbAErMrd /nmUNS3yzUf2IFURFScHiBz2U7G8U/KOixxoL9ruHfwPSvn+6zGadyqNAp3U8ok7/AzVLtK1E1PT D/KcZTjrgKTbyZQMbd4U+V3J8VQuJarIgVEzNhVBLeA76IoThw+KnHW4Y+dKlJQP7iJ+8I1BQlhV kkJNy3AyXsIfqH6D9pFMZmD5fUXtALN5zr0LxnMb6+UqdWbT33G0bWoCn/4h8TRhMCpTx0bYvFEi tBpZFcsZbecPeWXPrC7cnBBTIWee5bBN3HLrmGV4r4ubMye8hnfSK6nz0lRkkUr7NaEOpSBUNGmf QoO2KNE1r9BwImZikUwCMYi+BeGhMcGDJlWRDjDmmWcpHDSrSTgmGTnIVDOqHYRF50PXJYXz5sGU SSvZ8o2/vjk5Aab+1+NPJ2cXqlJhE1nt0YQr4Ut6a3PP4irw+aLs8KJBUArtjsHGj5M5ByaJ/JT5 m3zZDVexttlTF4UheFs8t0I+1WML6Frydk3RHKE/rFI3hwanJNuyQWM0SbYcrEgmr4SnnAa2oH2R q5HSmDsKROnl6PAPXM1f6PMYDr0izGHGoG5MTG9iRrPbXUqQjItZ3BP/ST5aVk2lWrVYvkADvaSn 1Uy1Nrb7u0ej0avro6P+q/3No2dTG3e2fiy4WW1HosuPx4wkBv/Z0v889CWOmcGXHnqQjgX+uM3a frXT24L/bB9s/QPf3X7wu/L5Y17X+Mp2m9qZz2zhtDYEU4d3YorvWKq2F9otq7JLSdj65oFaBxUm KZFB01pe5xgeQi6H1WPEVNjxhsXy2W1a5BnjCxFnvji5UG8h9/7T5CIf/6dmmsx9VTg3LpHwK2xp WYqFwEExvs07O3vowRXOgBeKuRSxBq7YTDSuBjNSFk58yyynbObHiEgdzQmu0cVqptpLwxqYjfZl wGW2vwRF21ZnSW5F8lICPzAq/AChG6dUJxYas+JxRKe4YKXiiSZ3QjmutweXCOozBGiKzmZeOnco jY6HiGmbKqQTU1OaVKPuPry6W8Rd5KasrxXR6dsT3EV5j//CJO2CSgWvjbuwe6CmMwvuDseDWZef dhlMlW4srOo2ycj1wCYy1j7GWUKaqc+K0srW3AFYOSEZO+9+p72pLaZmkXNDKNDp5FRhgl0pCeVI G5TX0Wlpw1BGjuYogqVYOq28N9eZzGYxWoTj9BlfqulafktalkqXQeKqpTVEYzB6aYtxlWNg8t1y Psy6ylq6w7zqInv5IrrdTq8eWkSPP1qYTsXSRDLx7ZLkGyajGHa/Y8qCbbMfXwugRoj3tKI3RoWj 5AiaKiicyMc/wH38uBmNJvEN25tJZQA9ye8UAuW6lDHWUzJXcxQE6zpcmlprblwaWGNyJbFUdxbN CYcWNYtLQhU4cW5wtuj4tHoblWzvC0lYVBRn5heI8knwZmiZVTklzKJBEXODREr9dz4jVrbIjGqr AnI2nxYZNJdr4YYl4uargNpq/gVpbbcOb4brpPiQb4cRxvzRcSOKwWbvWcsQd7afPRoqsOXV/Npf BA2giQ+a6DFlcgyds+rRrznpOeXb+ymd73qcDMhFAFIHd3kYbZycbgbj08ZKE0GTh0AxjlAn9Ge2 9H6Rf9wZW85FrpNv+pCaXnnnvjPeOl/PZ97swhDcBnZrb+fLJidnC8UrDKJy5WAqZFBTqQoZA6jT JzCrZBx2dGF263MNTb6LF79gxI3zYWnMno6X+B3HKNuEl//tapJKofa4ralfj2lIW7OMW6odcYmc qog3jheKskGrG+th3bozx+XorMgLDGC6soONey9wJK4FzYWHI20kPaheyLWrIRoQvb7DDvM2ddP7 hV7PpzPY9y4ssfsWl8fEtPcSMaMD9B6OumA0ZElGtKmpVP+8JkhHLWGjJWBipFVbJDFNazGVSAzl iZwEcytObF8HgRjHE24wlxjxgjlyA3vKOOWa2UX9NTHp3g/SqUPB2HKu/d6uC0Jw+1tuS+tsW60C ww7wltNJDBEfmIycp83yNsaTRMeRry9xFWqqWEnOgjOZuZbGQNW8dCD6uiXqGiRqxUD1umklHM7A oYW3BKnbAtMGJoOC0S1haK4ckEg0qug31Mu7cre5Ftd07bKfcptbL7JpR9Nya11Vc02M+4tqa5/N XcXN3sMFnbwjbyNrtao08ZYhqrsHL5VHOmHhB6GSOHAY1IC0SQLqxejZQRHknu0RSTtNFuZI4s1n telbeNq4VDJvbkDkGZQdUolHQaeCMPTfgH5KdVEWdVBwS8MRTBIJddgoGOLVVl8hPi3LnVavlafM 0i8j1JnYA4+k5XZE9DeDwyLKk58LaoGIoaTpTkFN5UxNUSnwnCSjqutjYybe7fIkrYsKCKF8vuKD nR8AeP8Db8I+nIK0x6QtC3VyI1CFaBC9tcuweu4wGv3d/Yk4hGNfgYAOaT4nRM5Jhuak6sck0ZZb DdF4f7jpr+FHRoSsqV/LumbDqnUpDBVzuBAEzGUuEsnVjF0UFNuvtg+/mIVtSEqLNp9XsKp3xx/0 Cm1Kx5EqyCWBsZFt/GC2Jgar1IV8Qu4BN0cOl179K2qkccixO0HAqWK2hteUvt6F/QwTYxwSmuxL Rzrb+wQGiWGL1QsL+XD8/kwVY4oYaUCaetT47Dk9B/tuTuLwW2lfHW1ofzQXm01n++Qj3Ow4uETz gjDALg8kU5DIQ7ewXT+6DJl18RMeNizADxLQNPWMrFLfc8YgOflIN1sKN3ExlK3XNSuaFB0oml2f bR8n2tH+EjjExLdhqidTmUjFhsQVLPYdSTmBZzO568EXO5yQw19y4QXJmbxNY8EA8y+CS7FpMhgJ aMBnInrZ0zIhrkxCyRvq7g/OwAyLr+84YAGWU3Dhr1O0nIw7xkVYRTy5eCJHdFwnAPSuwnG8DlJV mQQyzaQedlrNQ36BVm75SN7o/mRNk8Jn0yWZdGoZk8vTJevmuMFJ94lD9fi292nXOx87THjfgSzh lKpUNYC4qmMQdO63iwIMdUZqqMfPPO65Cz2zG0ASRdhZyfAZkpAxhAPxGDhhXAwtaO/GMs5jn9ZH bkqXkJtWyrs5yk0Ui5Y3BQfR1KTOZxgrQME/K7CZkatKiRc0bUyWI/29mGdNKDYEme85FdSCQy+o tHqQaEZl2E3IN4ZWAzdpYsGLn9h55zjLRm4e7iTnOcTL6koY2NC79PFFkoZIuzsLweLyrDtMpkh5 v1x8iDboVqZcRePQezxffD7V60cAwTMJKCplXDnQjCZwFYVPFb0qM6TAlbYacWc9fP1zloKKboMp eCUjNOrX2RjfOXj5hbxeOoeaX1OzS5v83hgvcAr9vDCsEjMIyBr1z6ACEyaq15SPvJBkcFeApP1H 9JnNjsk6yCSuwfPFJIlfHcc9Cswg7g5nbVbuxyHO3w3GQJVioch5tdo9yPfgq2wG7nbtkqFObBLZ d2qR+uh3TNjr0vULlQzTisPV9wt/pwQx4ShEagGBmOKDjsGgjhgHlLst1oLqy+AuCJY9dl7uHdld pxGEG+xb8GnaSLDBtm8IYQXNPYKP2xns5WNbqNAUVOZFG7DaXdDJKouaUOs4L/tygbqqMgA4tlKA qIGax+gKS92uulIo6W9bUP4avMbMo5ERSX6H0jZnCft+cLqvSe2wdnazPsRGdnUS5vWdWstGv9N4 OiUXtRO/rsx2CnQZ3TRQEnlUtwH1NCqShhyD4GAnbdosR9xsDHqZ9pckCly1WK3PnTfts5wTruB+ khLCcWoWpuRtw0te5PHwmpoiuYQWavrCZW8cWL0VgFCfnwVfjKsKeeAsv6N8TldIwdDNeMtd2Uz7 s4w3xSrSQrANVDXjJSH8ssmqNzzvfhEGFlSSRKHPU/NWHC7ELjkoTbkxEcKJ+n+MGhMIYS77WRJd 7+ieid7ogoKkvEn+twiHUKh4pV6BR0ectDdM4Q0ExxoWuCYmj9WiEgc6wZrDcsHU+wSdmgW7ldgj SrKeVeUQw508vWoAoVNmfcQbtR4sC+dOBrC4aiXTTS59yacfeKjoFuKV0NsWVqHShwpKG/uSLlUQ RRrbipKW2J6JdS7tUO/9sS8lbZ7Aw1psLAco5AvTnbLYBiF+l+iMr132g0ObpHY5DmMtzchMHVQ1 mBHysU+TCh11mnIpnggUKWAtV1TIoCBphI1G95rmTAkLmnPt5IxUNllctpeiZWjWXa0mWWPyLIjt BnjXRQO3rhO2FMZzWlQ0WdpmviaM48bvo2jXdXBMUkWSmQ7INJcYHdNlxb2Hw2LkpCjy4jl9ez8A q/9KuZp0YPG5jCqwraymSx5zn1RBzPbNwZwkvkcEm8IAyf0JYwFsdOjdRRrDhmYbpoPZ5jKAejYX w4bG3oyp3UiPtI0cx4XPqcI4RNR3lRH1G2EuBOXPxByhaL8KmzXdOQ27niXTGSi46GFSkJSRBWFR f1wA5nhPSLATtOyxl8NdDdli4X7DtOSgCpp74nsIWhSbtm3elNAKG+dCvAEahruRJMGutdQFla5z gHb98H2UA5BGD5Y0n07hgtDOaROGONXt0vig8HQnM1idFHblOIXkhZO9RMCUaC1hWMC5lKUWwNS1 mxrKZSzepapYe6JKp65HWd2tkC16jrGzIJayzrBY0x+Ic3Fp+MY1SCSfCO6oO4Khhmn805RJQknf OoswkiO/d7m/9tW1cI02BmMSUPAJl6puUGiJwaDTig5l3ZzDuk/sHUxi0LmwSoPHQBSDqdScSEcd bf9Sz4v3QU9sDRUkyHNx+XtqTYE51ebucgqV5rFR9Ad0DpF/WJOAOPfOmmapIW6W0iksXh9r+EV8 KppNCGXQONGSmu2a9T6hYot0Qxt6cqaLEQc7WOvpbTxY9M8yKnHG5bxP0EeTltPSaoyt/evxSkzd 40QBHPTlQTnHSQeWREOuzuCI4tW7S0ncONw7/MJ2N//mFH7FmYSo02692tXfariSnnp7dXUhIxzu Hmo6oo7xx8/nJz4bcYyBkmncRbQxzInN8QfJ6tAQoQujDFLJOTjNwdA5zd/qdp7mf7Rqo12tX6mm Qna0O+SEmwwFwG+iW7sWIaGXUQG9G+4vbnxIUexKAw94vkiFd0VaaRcDl+HZQfk0ASqscDGyiLfo 9cyGiNXgTKBhAjencOXnGw0Lk4TvpqnUA8IrByCFtUwtzgKfu4uaT43jgAZxyf2xMvbJwoLRwSQa HFEyJZ8xvWzv2dPLOM5xiX05HCjaLxcfSh+xctVt6IYiPod3aN218liHfafMUSAT2AUe6i1wrN/E +4vDMkwHxSaB9BgTTTGcXWqqdX9Yw56Ej2PsPZ9W4pNKXlEWVQzyflGSniu5M67alYuFjdYf4spr ciQunfkdcIZB4rRA5JaS4kkhunGRz29Yo4evgEi8yXIH0uq0vAbe/i7lPjS680QboCptRrdltKQ1 DyiXoEStBQjJbu2YykZu3v3omO1uAvkZme7NV6KnwjVklVPTusUHVDPGxFok8OcED4aqZ8iHjrKf GybqIgUXSn13ovTBxYIpC+OJGbgoC9+jkQKaiaamSK2S1iBTCR0rbKgAaSKfC+M0gFdKjyl7JbN5 //nyKvrw8cqV61CQU1PL0GV5M8mvG/5MV7Fx7oPfzu1mA3gaaWBdVk2ChLfEIs3Ka2zOLYWEaavs 8L7ftVvD8Z+RUWHkBDO3kQN0JbYKlMgsFLWcUovh9Z3umIR5l43yY0Y+SIqygWTke1NzGpome9eo xWQDvP75IhqlKPLJei3cNNzGCejiblcDv7bUKUH0geyGlK84c+SEB6gDyTnGku6PHlCkNmqwlww3 ceIwiR5ZSLirWvxAMX8dhNLCZgh57KpUaMGUCERlnB4A2Cfu87a5sC1G+TS9fhYPviZV6SOC3LUT NDPv3uUYEFYrMGyOb6KkbRmVCemJMqavJ0Tbgk37UGv8VjMUbX9C2VJyVUgSXNRogMaB3QW7CJiD GetXQ7c5xsqlTZR4mVGUVvCRC5MLHbNWK4XHHLXxncStczygCVItOz6jrhmoZDUzqqua1MLKgR+n RRMVjfObh8kkvcYxE4diiy1+SY/K6mpqsD9c2VzA3b0mMLWg1DVy6U3OQeDLEJSC1c7BMg66ScRF 5dabkIjTrOpH5Is/2tPg2y58fQyp/Se7kwvbbZNvtq4ED7tp9bISvt+rofTRzrqgz0kTou+YyzZr qQ0PhZHyCXpwCYyVu4GLOMJi6jC81NGKUAMIi8GuenFoJ0iIM71IWyEJw/op14MhGT5j8eIPQOrP Jbt3o71qbtNBQN+fjtyJ6mjN8JX7Mp811ai9vRDdMLufdAzNhgoj1ho0c7wOADXyZqhY27Y1xnpF aB7w47poH2YDxGKXGjtJH2BjX2LK3hUV+julWzpcXv7WHaWBits2dgwbfoIH56hgurADQfyZRmXc oEJDTJ/PBHwnmYy4Dl0EhFpRroqFFytU7jIhcDZ3qeaGmyozh5GoEB+ulJGNI3RYMxu3vdVlpqrn cCuf3d6BRcCn2Dhdz+M6wuZx9gAQ50O3lBME6aIuuaVL/U28Ifcs++FlHmpa/JVx54Y4eZrdG4SI fXb7yyC7XZRxUd3fwsZPEOKoY6A7w9WITDe2pNwoYDmST9931SXqdxI5EUZlRaVU4KHrJKjEH+ZG EUoUK4XFOLugTXy3TmiaA+rnJPNRH20Q4mk6bCXaK9pPTqn+MAyZF3YBJrJSS5Ryz+Oyd22NF8sQ TKQQTUzjGQuhdFScY4J5p7gJqmmum6OVP6YXGGqE84JN2OYOCVahGcMlRqrN6ZEukmo+Cys7p/E3 RBD1SRAW5oGDEHngXpBcKd16G3jgY+iF+iH68PRejdMES3DjeQUWg+AwONAsH24+OeMUKkmnCsDg alGBGK2+AutuhQZs/goX13YvTtXNtY3VMaK/5Y36ZLFysBiEdf5MwizOHY20L4yzFnQxcIQM+KRb TuEPvzQjwl3DEseytQ2numu5pgYzZqcgc30DuXxUoTvEolvgrOqsX3WWJHMaFtIuWK/VbIy4WdEG UOLnM8TehB+cs9sCEwpqYetOkjwSVEJHf31Wqd0irc5/cXpBAFWIoEKIfXxk5Zjbymw4vrXpnFbc GcEYgb4OCSZuCi+4bocSk4aamGSuvASWnk9r+gG9BQyDiessxl4zU3jh2QExYBIir2DTMFjXIjdg iSAIgSeLe0azwtk0u3SDnV/0z0/eX1gx5BzKBwd7eEAeUvouXoRF34m+pdF2GhmceoNDaxt1F9B/ QUu6oQTbXzlqyDeK02kMO3bJa7WgdB2PmY0/42cPWB9ZrnKPXY1xOFlpyZYPW7I9yJZzyXNS2OXM lKYTprpDLqbBWQ3IblK1OLU+lqQM7ZcM9EIuPldY+vPnY4vK0qUSmpidT+7FwojYMebBoUN8GUZ5 xuRiDL2Jaw2LxggS0PVpEmgoQUw8Of1QOqREFwSqob9gtGCGF0zA4eAOfIPlYyFodzDMuvzdL75p 73CY2tBx8wxZ9xU6C+NkdC7NhHXBIJhO5xljb9UMsYY1ub1FrExksu8SVNYBlcQBn6Kog41JKedC Y7aco055G1PuKO7TrrzxKNo1BwlRCfEBQlkVusCwyh3/P1hWr1bNrrU46hYKbBvJlqmrmd4peXn1 +QPf6L2Xh69QLl59/qSfHOzvf+G0/XMQh8Lzd9HCMq60sHDm+p6Zh9duYrxRbbvlzmsXN7wX5tz4 U1ClirIvUUP3ZhJMNwINpWIg+YRSIVGGUAy4SCgljzcAl4jr9mmc8Gpf9QzXdwr3e55dp+WXqF// Dapl+BvvJkVEFpFjh8gmhTJi9j4wmySARsTEc4tnxc83i5K0U3blUfTLsxFBciEEUOrNLnc6KCvW gXA6uuWKhkEmqPcrUl6HYew4jvRD54O1Z9dk8t6taCTJYF6ChsftK03SllT7XRm2rjZEZOqpgJIu z8+vuqcnbmJ7Qo3yeff0yk96n5wDGM645NwEUv28zP0U6E88wUBAr601RPaYeBtQd1kVqmJfJwYF OyeNNNO7F0I7kNXV1UPlq+0+IqBz1/oOTCwkgZiPLJBT3FT+71jO4RxDTRVPfVIDalyl2zmeZyDg hyRXp8BpNH+P4+Ybfz2//HhCCly4bOo5GvbQ46VyKawBog96OFDOhtrTpKBxpjtOADdAzp+AizB2 npSz1PXuCAKuvrsAF9iJIlFTgcOe83oamHU4L0Wvx52O40unpbOQ8fF2q7s2ZhBzCy0uYnk2jfHw +TXGUTxAgBXCbE6wfxs7qmNTXaQcwWkB4ZuE6SA8YHvrANNZAPGqGshJBDinQIm+nwDaDJZEgn5h lh5wSkQ/FguVdHyXIuUiJ85PH/iSWR00eTucEjDkQrpkhDigpRlHOryBgjGco9OZwEYNhLPtmtaI UTHUSADZGzf99Dph5hYW9VZz4QRaIlZQ10qqSh5oI4PuCirh91UzQXGKSdBjHdP/+2CzFlYzO0bK PeLmhU739ixnU8noXrzpsmknsJOVTxhmapPcX+rUPb+5QQj1IDytEK6wD7l1olGtCcGiqb/Q961p ZOPC27ydDZosXLqhzxnY8L3nqI+js1BFf5R5JcN+rdTHT3Mz9JwEtWHqB5NWJ+S3YAa40dxRaQVn Ula07YorPm2Pa9SKWdgO1s1S+UMUMXYZXc6N3Iz9CJqMA9MIzakARqUZvdVcb46S2Y1RNFlj01Ld 2jX21oY7p8KPs1cD07buSTPWWcd3PvETboGUIKuOjJMpp0yFUDoUcfIo6Q1gfA+05TL5xZpCibgE Xl1dnZKuTDxkTvjWCwfpLO4rBQ5zqSVGITIuf8FvA5rn0s0yFsmsXmT2DzqWJhWtai0RY+ILHsrO sgWAxEg/1wKr2VaVsxeQrQXYZ5blbPd2fJzmVIi9mGcZmVVIW5dvP35+d6roghSNYKAWsRJEFQwA UeANiMTyiyKxbDYKfmQXQqgH9lm2gaG7KSIwosxI4GUsjkwIRhOuc9ev0368F22EcCKbNSa8DWx5 o46zILN1gcdNSrIIQ0DXCzf9sqZ9uVqPNTWp7LGZSvV1vZhDey3XfWBiHGsDo9In1zNTcrVGk0X9 CknVUDnFi+tRnKkBhq9dRm+uR1ETXY2onL4n5UMUwmrhCxW/kA03jyR3csaRfODoltE0WlQFsGwY RSflqeDsPO9SRHcyMQ26bX5fyAmuhV0efhjm7VJFBwFSsEWQaK23SwP/fVwF0RhDaS83n7Fq4Qc0 N1hSYqhJk1hjolVD1jlRdxvZC7LdcWyU2UTNBPUYyBbpzDvNG022TIctn9Hf0rKO4xWkKErnOnsS 3LxK/9HbCf/50pUzKnW5NA1k7VMb+xIB5f03XNatyNUODsxGXQLga5dDj3pBUELL0iz29esoBxz6 QSPfymsmAsxATgoJe2oCFG8JhyZwCdZy0ugeMto0myeu+j7sP2dUuqBjSt2YMJolVbYabIygN13s W99iVhZmK15e2MPa2zSt0pCYqBLEeVIbvZvrAvncp0A16pu8HqLJ+zR4zwDk+DoXh7rgA6q2AMJn lcZaHxe0S8a9DVouMlLASES7BrocNLjulL0ZDMSmIdHevfHj3d4h+9kbpZ+lAqWVxuBoLQwTgerK /u6LwTWAyNl7FBB9GN/zMTp+D7uoucCG6JjKD4nxmGBdPU7SiNwlQSIpkYzl4XSEzqeFUFzoUbOx Z7ahdK6UNNjnXDrHuHRHSGWpNW5E+GdUFn1AnU64E4AdsYx0riMj8GoKjsEZkOC5qg6kKon25RJt aikDnve3dukbeWOp4dol/Ne66qAyL8luQHqxDh14hNosuRZHVwv2YICdI3Ci5L90cXZsj5GPupJq r8myGDpsln04hzZ3/MDwpyleZWPBKZ6BSaw6rrRtY6iPvCOmZepyaoAqGkUJ64qlsO7eFsJi4yjv gWnkvk8aZjI58xztkshlHXXUrg/g+AS6UDsWfD5zTgoulzZtaegSjwm5zqD1DzzjxYzVpFDlT+dc s5VD+pMOs4x21Thay05UAbGxYPFRrZ+29iaQ5JbPpam0cvHNSy37XvfxS2rv0BGfeIzLuaFU9VsZ 0Lo5xcEjse3jiw917ofK3WLG/lEb3t5gYGIckP5393Z/04TmnGppAFFN9naQIMEV1Vws6wxZ6dER FGd/PivbbXbOLi0trpFBJlIeyZqEB451rSC8p8DYbXDL0TamBBZfKbjdU2ZC2/xsuuvLH9BhYeMX 0yBwFCl1ARldEMbt0VE/M+1IJjE1HTT8x5foUtzUkTMXdFA6whQok7mg8aiTK+ubbUhc+VRtjlEF Rd1O8qy5/HVzVeTCKx6e/ha7gHiR5T53IIj2a2CwVINeCGHe2shW1BlLwUl5jztBc4ACMFq/WJIO WH9F0EN+g9y081obP4u5g9vudtfOhhtqKnx3tnB5nciKM8KSqCwwOalzOCwFadF7ov5djdT8HWk/ Rj0PhTvyQZO2T2kAOvdUm/bQPUNvOoK40c5yt02nnXkPvLIC68yvVbY43xM1d/D5QvBqr6l5Zxy2 uiH6I27lc8vi+DJyLSJMrzB0odslOAddoAnYGAHxEtFhEvbfS6nuucD1Txn8RO0eBwA5XlwX6ZBc L3R19KJgMpdfi5S7TtLsKzv1IuwENJ8hwJuDvq3JEZ9TAHb/MIkn3NKMSne4EgCseo5W6xUQW9Ad gfa7k7zaVfrcIQ9QO7XDtp1sn2YrKeJqWzfz3lJ4epeWzJECun4h2qXWn7KLSevmjCGMtsL21tb/ oIU3eu9RjNclBquXwvZcZKWBfLs2TWO8BBEicw2w1FKVAmc1aafsxAnVavYHmewtgpVqwLaQw4Zh PHtWn+WTZW+/lW9IXy5xpp4BGjYNWf5SAxwqzsU1V3EivkVn9plv2fQ3XxWzDHxlAzELU+727Nvz Hl+cb0o9TK3A1X9BXH72exyiCH3PEmdGJcmB6jo2FCTGUimM5hTpY3hAnSA//iZHgoHxe642kzZz hKme5GRnMqhnFsRLeoXv9l51TFUvNZtGXcc1irLGkrlj7CfsWkgqMW+DXCCbgdCanGOyCKUBm5mN sUupgMhcWEyuwLsH67wXcxwTjLgvoiSCG1eYQXLWHLAgtWLltIq1tX0KrTvdR4NvuNNnHo1Q6jp9 alMtPqD4Iw0ZTrSj8QVeYBPkEI0o0Frmtt2bq3j1+REuqYyXyKE6l++rYwUoq+KfN1gbLp5X82pt SJP4etQWS53UDcL4vL6PZxAp8OB+VMAifsFnU2W3n1+VNe6lKaEscLlRXniAW7Oo1jj8pnNlI6Xd wfMJg/jGJd8R79lSN53ekPWW6gnqpU7KlzQeCGbARnEASOuBCRXcPi24RfSi62CxPOIMZwrpuOLZ Pz+7egP3NanoxujLtLaFCQZ1H+8+bJJKqc2fiX93VJGUsmEXKHT4tKizq3ZcEnKjtYa2292CnuM6 ADOau6vZqQLQnCx3e24CEFSFA1ojFk4RJTvFKHSSwCbZKWGV/WtUAP1VIulLDX8rCoErJWC3L/KD +76Ufp/D7RWoPDR9tcEpRQnxaJGDVmGtcwzC4k61emvT+uRTbbtRJQ6mWaDQaFAVNujqE8J4w5lp 27tGkgS0Elu81SbzkpskZMjtrTw4JkKvyKWVOlEqHSSUuRoxWaEqc5M/L7oP/nlhHv+uDKbBv/0j weNm/Bct73zhRnyx7IXfNf3Qvx1/4BXqAzo3imnV5/Bd4w3mLTSZF7VJ8r9fRK0jIA5ubQ5M9y1z 2H/2fVjpnGx3Qkd7R+0kRtRUJxNLtHtLidYS4cbp5eajKZe+1E6+dSXegsq3l1H+307I4QMPErLQ pyVkfxVWImTa4BXn8J9LyI4Uj6LTywbxMm4p/ELJqBM1EejfpBnXdOlY+yvxYoeVqfHKRtqdeAEe vgquAEy6SHskzJq5eg+ZP5emt/Oj2sI+7vY97vI9guaWEN1qd49/bz9de/ju+dsUfCpX8nvLHHbv mwOLqWVz+Ef3YfW7527LPTfP35ZjV58cXL8DxiOaU754S/HXVWDVDdGIl7baeHnuvFlQ6iChIsnu oEVOPmCupWetENQ6ly9JrkDR6/RdJUOCMaKuaZyiUOEc69ne5XoJHlN9yqXttsd6dg2VuWMbpy+J au+q/cLON4a6xITmQtrQYrKlegMEXIYD7SwmCYwpBGirlfR4+GOLuFiL0dJy+4wKrpB3PlMTDLG4 +Eq5f+K1mWtRfy3NkdrZOlQBdlawK7Cm+nswRw8QUCQ35DWlVAZ2T1H+QNjhqYFiLFgGimUJWjcs AevVz48/HD+W3DhcYkiOBgkn74/5iMeyfVyBEKYOImZcVbPyqN+/u7vrFaMBtwel6p9eXtz0kwJG jPtJOtzb3tthJ5c2MM8tfIF5h2R3qNeBA6GSfE7xvaCGP3El/Giehu0R2GLUM8ZMAelYx63YV+1E i0WdxwNsuDRJhjdssvs6Yer6Ed3RWybpV04z8k9LouVszpGUn+NrePpdkg2kUuMYi0Xuosv5ZAJk BLLxXZKgmysuYItex8V1XMRYHYqW6RvcgtfxV3SAvc/HYP6Sufg6nw/iYZzCp8eT5O8grYs8Ov3p 7CYdpjlcdKCdXyk6/T79GieT6Pi6iOHLZSlZu2dFOsBxfllkg6+ykyfYAbgoY1MUBhJ5kExymMBN Np/kHZthNsi7vBE+8dwhD7K739USlq5mDu5cOim59jGdMBhMqfhJ8Lavfn+ANXhD2RZOsm8Qnfcu CnEyBvZdpbDqtwydiE7wGZGPpvI0YmXXLjme+jQ9lxLyA5ph0K2THl3MvgQ7P5EEwKEm7xhMtSCX K6wXwfMiwd7iX4D9pPLM4w8fzv4UHR/B6p0O+drFi8zMiU5sZVfAPBx6W0kVeNSiQrN+qD8LjhMo pyaZhk4adj4dci5s//Lj24/eK9uxmQGk3qTZdT7n7IU6CD8n38VlN+5eCq/dkBjdpgfRCrLmfCOC OqpMNZ8Jj9HKvbD+PuhA4uYbtplZOB+TpnRIOSstoVHNqhfIl1TV0pI9hq+8jxMyO64YMa4cfjlG iEhIumiB4wAIpybt2hj+yvkTm8kmns8Gp7fh/E5evmXIxBHAVltueCcmlYGvU46aopy7zsD27c4B Vvoend4+6bBySaNKNFNSP1z7XcqkolIj59fnIhxDYv53rocuzsEbN2btdEClrw9nkOD5NatEOLoB xwi7dJl4a+l7phENz2dlBcrV1KkCpWWkAmWkCc5d52OwOBzeSb9xYa65XlLp85Fm+SS/WWz6CGbQ +5uhUjDiLd44KeVBglUgZL+3xrGKi3DT2nCYwd6SNF3JtIkql//vu3aU0rcB65zwBIBosPycExfp QVekwmgvktmb5apNtjQa4Po6BVJ6l+ckFjRgx6TpcfxI9YTNnxFQWmLzh3n+trmQ5C3Z5p6CJ+Mi XRRoJnmmdLqr2KIb8P99KVVFtU+zuRXIp0QBGCs6qU6Qc/B1fpS1dlwr88LVu/a2HRbDGPzyQ9D2 uotjJ7PPpRTUfsg1/G14pzSLUFkOeRHda8UHr5cVdQfb2YQsFz6oOZYOOm5CCLNIUj5HpUxutJz1 SmoKFKSa2PGaaQkkjSzkG5JTYjkF83qP/blvOm+KBuP7UCpYAO3fvMRqM4xdZwun2TcklBaZ+PQZ 2Sd21XckGGPZJB4vgn/rrDucBFNpddmdt1IYJTzEGCpNuHPDdCVz5Kjr8tuwqQDFz6f67P4o/0uP jPeeNfJf1H9R+yO/cWP0mftGfzNuie/8C/7zt8YQ7jc6yIZztG/iBD6BbdynQfrC22UUM6u+VHia UeAZdrb3aQpEMbisDe/Hx/E3hIVv1n7jd+Xf6DU/RbUVwRSIgcsCzFPmN617+906if5W2wX/x/0m 3Nxdt7nAmnRK8PYX8vbaH/nNkr0lhtrqSKr9+b5kW9lx9V1J5kXgVbIeoxc1L9KSXY2+K2NszEV/ s/t9KcW+0Ld/j+pLa3ivXphtPcXr6jbcbIfEZr6b7bsk4Yrbh3++3zOu26nGqoMYi/eTHRzhmbLe S9MP+tGZvp7tMDOJY5U6SghKmtiMENKMuqykDMaso4imSynCXF6QzEqXMVOD1LOFJpwTxl0z1BIZ OqxojBY3kpxJY9oQ/HjO4zlCx5HL385Mdl0knawo+7bDGY8if0y+HwpCTF6xPQU7geM8Yv2ShtrZ 2eOhmohpmv3Kye0tyldEkdCKhIx2MPiEyMNFdCzAyYz85XBV9qdx1i3i7oxycKkrgUO3pVISbRAg X5qkcOwVSJu4C5Pa3+3yFnWH48Gsy48qeOiOT9aqNaHhJOx7ikQQ4Ky/v+uWpBrLLM8nhlic1eXV 01Y8OntUVBHTCarqMUSHItxlHdXqVTwWYqPXHmUjFgNJ0GD3IyVEohScJkNKWQ2xxXQMAysW1/ei AfZkS4YUZpAK9YdJBWSQDGsFVraWMhiHtmDvcO9LawUfmzaukq9RkyN+Vm2EWyo8UWD+Sklry7Vy NUXce2Sc3oxZNXFJUbyRkvf+10/nF2fd/Vd4tWzZi53WdD6pUkGMBIopw/KrjsHT0iZcBgTKI2m6 /a/jDN5T50hJINSbogZe7zc8HhR5WTowPd/nolHFY2o/Kp/2yz5878Bn0zjEJQ8zaWR1zjHO5RFw CCVcmZjTsInv4+Z3ZaM0OZuRqdvADMJqP96V9x4oIsiuLxJT/z8Kp2+AYCnJ+vkQAl/uPb/2qcQV FPjJCSukWfeaKrzrT2CGf2txCLdTYOe8bXzdQDWpFJKPjxxlL+JflYTa4ai50Q2IZbY6L1yf7UmZ a76SjIW3Z93amOuGz3rL0rUlPePzqzeVUmCpRgsWqaKzi+9aEJDl2Q7/VPf/qe7/11D3XzQC2o9R 95cr949V5VWRP3xYkQ8TTEKwlockewCoHhcFNmcYui53rano26bXXe1NMFMMY2J5Ub1eoZZb4iGC nScKtX7p8kAeS2Z54j10/EhzobkFL1bK3CgiQcKJzazSkrY5544RLiZLLT0KdtoFYi5AnMpcLzlv zth08jLs4U46IzJS1NY5VLzx8cMVveDN1dXbTnSCik33PcyQofNPP55cnl+yxNnUsl1Fb5KT5uIS wnziGLUSBMY5P17fpvm8lK570q+PhAI1GjaabLOQP7TEeAObeCk+OMF7EVp3fZAKVT7IJw5dT6Nc WOyP2BALY/WZkoG2tt20FKkDWsFAtE6wZ9NE9n+UH6yFfzxWMAac7ImCsTbIUwVjOMrTBeOSFT1S MAajPFEw1qbyFMFYG+M13ahHCcalJ/w4wbhslMcJxpaXPF4w3rPWNsF7vxK4RAORE1+iXrAP5fv9 asMSJUt0myXakyguS2Z1v9LTeO/Ks2rbqx+mfHhh09A+iLqHS5UPm66lfa9IdqoFzCJY4ridBiiH c0vAayWhNb/LJL5KtU/uCRHmEfeM5UJeNP/iLCHZ6HpzwTh9kCucJNiANw9Mxl2XEMNOBrDuk0kQ zrXNt7x7hZfAdfKBGUpEWs6vQayUGlVyrcs0rOSQFWudgN9+UKzkw5cHrsOPT3KQksNBMpwXplV5 RCqBE6XOgevhm6TjFzWxVVtRDNIy8Ddtb7vEktdHfOjnAV7qQ+5j9NSBjiRloqUgoaFlKon1J9xd JwRh9YqW65bjcPfI4/pqe+9LzR8UmqW58fK6B63e65TiZ8xmPvghfaKci/n+deBJ1l3Wfi+WeY8f GLPm8YaTbPqmw5es4m1ue6m8oflqdQu712Cbv5ofOnTTxwYlOvQ9ykvc7UQAopr30XURdqhMzgXt PIs1VPmPoDpf5nPsQRrScalpW25YR8WYMAfM58ilZt4AL51f98AO6A/hV3dZP+ZH/rdaL/9bPugO JtqmDwb6fZ5PjoIEz7/DJ73pN/fEuzSbf2t9EfBc2GF0ieZZH0f1BINr+vXTVevXgNlld0WlvTKF zfYRjR2uQdm/nuTX/WkMDK3oAw3s7vdHKRxWXzod9Mqxe80vFxfBK3qjYS/N+7ezWR+D6/2yGPRn k/lNmpU4FHKkHceRTo6i10k2GGNSMCUEarxgZ/vVFwEoHzHoJ/A9/yCQBzDhIRt2DhDHg2AHtk5K XW98XZIDpUAikBwEeME0F4kgYBKCyNMG1GhG7pBfnr12k0Uv8lCBfuiwUvqV63oUrAIhPtG3m0ww c1Vt9r/ScN3X77vv4Vmh30uhWp97rg5NuIeYujFIxB9gdgzmAnem7Ch6uukyYnOnJYtU30sjkBh5 6Q7tFMQI98pk32V3awvf1t3a7ne3doK2ueyUwNwdaok0Qr7z68/vTgiN+iZD6xRd7/PZkBFBisQH Ca/Qhy5NOdWnrwgOunKc2K6b2FljYjs8sZfPNqljaqIabjMmeXM/cHcgPhb3SR/FJ4myD15y3XjW HSZTlySZCvrxLxcfHEG7JJJIawXv+rng9z2fyPsBkO1IKx+JRkFbTLAbNS2Z89Up4U97ra5t77nj e9M4vpd8fLvPfHwUnTE4I4jh0MjL3953E/u5MbFdntjeM0+MiTykLpycJPZaqsLeiPCNdYoKMDac PrbeaxyC33k5DnQjwi50THoo4iAi4oYoxPy+7QO3C28bu7DHu7D/bLtwwq9OCG7iSlbvV321mOV+ on6VH/ACLgPNa0PDwIUd3rOwfV7YwbMt7JzqElBAF/Sc9BXAt52fXf4sp4LTemV5Rkkf4AAfsMKG IkP2lyItOWcOfvN1XGHJwp97WLZQfs3BuvutE72Gf/4hhp3NrpPiphOd9tBZGP1c5IiK9XOvU7P5 qVShF71LYhhrXVHmjhkMUsHULqSzvDKOcr0+zGvQZPc61KYGJwjv/XgebW/1tg92Dw/6Mu1O9Ca5 LphLvXq1Xx/j/62XvZiSlzQb5X34DIf5157bjJ1tVB2i10U8zHAzLmG1639g9KthKW01SOzBwyWX DLOTvPbuTx44AvYCjcj1Di1qe5dXhW+qT7i+RnqGKjrGuMCDpywQx/jX3jO6Sn8ARrJrsQT7Bsax UNrvkRDj8QL2i36qQHZjiclFj3Wg0x4XzNQ2Zf0y4XKKqyKm4phJ9LnCcHmauM420Qa2Ntpc56PA Vz90FPRM9HFQ5TA5mPrW4VMOA0cx1La3j1YdKLGTSVryMtcZtgrB1UNDO/oZG65M4OTaL8v23o6s BgZtXhf+9Hh+gzmqMP1XT5o+DGKnjz2wonvP6Pc9e6Lr5khsPpa7M5N4gbyPyinomLDx1OYR/wbo tAJbTrHV5JhrY6x+6DD5Bw8dn4mOZ0U6QWrdetKewRhmz/a39nbwyOO8E53AJknxE//D1Wy9x3/4 erH3spt/qgcF3qUdLstQOE8K4IxIKSSPr+tPmBelLBxn8NDC6RlD7U9bOo5il769u0tLp8q4N7Am nP6faN2yG7jIP/SiP6cZrOtNEU8TLSqqvb65QFRdZIHwnuYFoE9ro7iT3e6stiAYI1zQPi3InFrz Cpz3ots4g0ue/j2bT2Fdl5JbVpsMsc4jV3eukhOHuJBoW9D0mOW/1ACYPyfSfx5lE5YsYO1U4k9/ G1PVWjZn/xk2Zz/cnIP65vjyyeN7tqrO3NzGke1yRMqqYQV0u8NNa/KE5q49vE8HD94SfMbu01Pu CIxhdw2btEfAFWKsBEXd6zTBn97KDl31osv4Np/EIAfwjlAEgJ391PK7NgPistF6vSH8erTx+vyt ckJ854NLxWe8tgWr3XnSamEYu1qC0wZCuIsr0G2ZSP4A/yrHKfJE5XugJb9egLoBCxbV4qhO9B7o l9CcNH2TgB+dszDgFXXhgzsB82m5HPSpO+aXT1o4jPGvvWeNWe9u/RhFjNoyRlKLjNr+2RD+50QK sFklrsmmiyTLclYBTItGbbAIJJtMvqZYQrR+gc78E4GSc2xt4+LkwlEjvP5BasRn/uETObQXjwMF weW6QmLMC+wDnbE2arXOEGy7NoHHQm+3ESPOqEmM/OkHeO9URPOTVo/D2NXvsCIaHqtbITIR9oCa RQGdfi5NsbI98gdPGV/40CnTM3BLiEB3n7TKnUBfpbJZcr2TxxtPmI70GM1VkEsw79kMdZP1ehfo 2rtX7wmty4U3P7hcfCZgsU8yaHEYu2aKlHkNy6tcTguz+8E0/qYX/Qyn17CsWhYIlv0N9t8cT3Wp 8MIHl4rPAO/JkqcvE4YwyzyEsWGZcIzXMcvN9WOQCDdz6Qz6GQ+WvNS3ZfQuv5N/sB1fez1azBHa /L+izV8z2/FFzVtJnzaIhA7xYDXtCUew69k5eEl+iN/y3/K78muKDIjO5ude9Auok8Mk+iWZYNXm +ucs/fd5wG9qM0HIRRL7sgQYu2UJ/GkycIzlSe4GHMau4+UWkt/lYAzS+bcUBYrqMRfxHPPX1t/C ZQLbbpFcE07jL0CLSFc7Rw09kLDFtff0LZ4sMyCsgZ+jh2qw0CXCax8iQnrmGRYMwwQLPsAFX4zS krxpF26977BZLqr/XO7c/Yw4lTmietfe+tM4nyY9hDXp/eTWc9Bi0/OnQmeHT5v8QTD5XWIW74v5 TTwhokOOcJnmw4T/iVLhl3wibsE/5/OiGoyT7GtOGn1diKWDcQw3CFeNX/x9Skot6g+yF1deq/2V khbLBss5XWTxNB0Q/eJBm0RGJ1icYN3goO1mqzzFxbXsIX1q5enTNnKX2dGzKXfbP0a5oxblEXA3 4OCJ2GFv88mU/TMn7V6bcwV/uk0aare5jGdlFV9P0nJMU9k4PznbPIqOw2P64NEYrakpCpF3VlA5 36b35ug9gOk/eK/xGbf2J57mbngtDlG4vM1Hoykar3Kn4f/eD97DaZbitvvjHFQlbHSCSC9vr64u Lmvv3jjNndWFg7aRI35qHC9PnP8hCZPtVz2q6MtGSwMAxwixwC3SvjScS3Cxb2NWfdffJdVPYCzH k68Cy0A3juPV/1Pgx9Y798vz60l+04tnWTroAVX38dn+Fvz3VT0fE25Q2cV3cUuBYVbu70o7gb4e zPGnk7OLL0Q++BNyVkGJcY19SsnLSuZFGR3BqGU0TUoKWA3rpPzvYEljy+2hg7ng1RzW5DfCK816 o6I+5QFc+KTswmUd4qVIyn6Wl93Z/NrhrHdBCI5GBf6q9l15YZcn3oWJd/3EuzJl+Lg7ibsyT/xX +yj9+0eDTbAjtu8C/kaG6Y2r6UT3PIjr18mF0bJQQcHb8eceWPLD/DpeoDUPp2NTNTwIsPXphbkz iGmW5MVCPGDIf+hMwNSfzSXPPvQATOeZi451oltsPbC9c4AwyfBDJ5rNetH+drepqeklRHL8O2a4 wH97ePS9rb3eFmoJl8ms8gIi3AxJrli6G/AXlnGTlIO592jUdqcu9YK9el/LVuE7591Vj9uQrVfB hmzv73S3D/ZW3ZKD3tY+bMlubUsOZEvenJx8kQTSkxM48/dJLMmSHojqeApcchBH7/Nr7KqCFmwX d7Ux/bgAEQR282lcxe13cTQY9G7y2z7DK5Z1YkaoDoyd6e/7U51O1/VR6cY8nfqVvOfR7pRm3nUz 19uxQi+Uuk7LXq2TnopdUh7Ep9/9RICNmKKN7FWat9kLE7SxhS0aoprQvX8K3a2tulTSfpTa52sz lEC9Z/Va/QDE15UQAuvkZfxZ6tfxVooq6ZFX0qMP0o7Jaur6GtLWf3In8MBcutu7KxxBoJMaChtz xAgEQTrAM83xh/rygrDS5Zi6ynF4Ivuait53mg7gZ1LPL53iVyexRZLdUCT/UuqBfDcw0HhI0zlN tEzsj5/PT5ZoiMCC3Pa0rgDzJnQb6var3xSOhePRmx1py2ttTAPEWgUn+85dNafeBG6ui09nb7gj CCe6NjRVTntleEm3opYZdLe2V1iP+kAay6mKeNotq3l2nZb1xVwkVVp1385v5kmWinF1GU/gn2mR s8iphdHb4uSnQXhdFVoXk2mG0euxheXxVbMpdh3dne0V6H75EdNYWFDdsid/4GX8Ph9nZZUvjTAF lk1d6tai0w/Fo2tfb41OrxSPrg1U3z1ZcXfnoHW/2kholSTsllDyO3T0z1POAXqXzpl9/DpnIjIu w0BaNUx2BiH5KCAkpLI4Vzm7kdWD7GgFJlwb5qH5Y3pmy3YsC2IGuzMdq4j0Sb9dantXpGXL1hhd TgT078luZvjXd/QxOqeIl35ywczaMG8wiwpZKVjEHNc9kRRxH8jmGoorkyK8JPgdx5d+8x5YD6ZC brSY3XU6EqFqdmqGq5WhJXsbt787ALE2oGaCDd6k+6OedY9wq7E7ogxtVuUWUeeRD77ZrepeArCr ek415uUPUmNu029pQupaMfutvrm/4C+d/+EX0liKBXXaIgfEJwF5iS5A3A0W0V+w80ud5X66+Ivn 0cHrMDP14R21HtN9pZXLj6L440+a4+BI2+wAKjOqzN/n2Ug1MzAfACdckHsD4aSxyqJEz8Fhw4jG V2InY3YZuFeSit4Pos6UaWaClpfxtySL2R/ZknYDGuJleht/nYNF1uB2x1k8WWBPOxt2BhbXkpdy +HCaGT3zj0c2bZLZ/iuKbILSIAzq9xTXnHwlX9ZH+MdVORjnI9AlTKLB6150fA32aXO9IJ1BfUOT A4TaSa2RUmY7y0VvtOqroQIJwqXuzKu2UCd/aiyRp+3GqzDSubW3jQ7QIK57Nuy1ZVdQ4NsecO31 l9IvEl2csxxkPAs7SsRAHQBzYLNA4i0L9G63Bnq3nyfQux0EeveR9sH6yVienWBg8C/ww5/SxDuA wRh6nVIDk3WHEh6wAHefVcpT2u+3GTpAM3LTcJR3/9XDUV54xikxTwzz7r8Kw7x7tTAvcqTz86vu 6cnR/fHadmm7Tz6I6IRQoqOz7Bb07EwtAInv7q0Q3917nvhuLaa93xbTRp4FvGgUZ5myY7vm+zKk NJriEIGXLb4uWWSLQT/GtKRgUMS+8Hu1v8Je7T/PXtmUtIPDXUruZso+bTL7X9LfhtjZ+ZgTXuSK vAUuNkkW9Ql8oIdgrycofyn9FQNe8yEP/S6fJb/xj3gev/aitzGcB2aVN0WIBm9zLJSjE3j588WF ushOuUO97h+s4sH9w2c0Mvi0rYMR/vV5PT+7PyakdXC4d0gpc8zH/jKes0r+NkmpRCrTTHLv+fgV K+uwrPu0tXwB9CsX66n5PcT/yo4PInD0LNbthXjBTQ65R8zG1btLl/cCk23h9fTp+4ZJSYe34nHt 2TKGw61Xu1TTMRwumP/5dC5ZIVgs6UT0RnbjwC2/AXuzjTVQDXZ9WadmXfjCBwNz+ExwqZ8WcIdh gkwJqtio+dgvUuA8hVCCpE2oGRd41+tJG22VoUssM5dO8XAhBz3js++fmlqxbcUcleiLweXuJtM6 me6qyb3vmZTKOusxZSqlX/CJQjKdYWuUT4LYgF4NLrJusUeDPg26MzDDlhAnfdpK7K9WzJWBEdxG KN5kXbGCz+moMW2AkkMq7S2N2FAuoESLds2yj9pkvxTFx2WZ3pDgk44R3Iu3jLqEvYf5HvCrW4TQ y7rNDBx5gM/kjhAxsDE8bCpjXq0Hqu4DBJLOEoqg2vBif5gPyj7+CvdD9+dqjD2TlwR4H4jY1S9D M9GPQdStV3iWV9KWwfXIkt6v8EsHDt+2zd51EZRIYxgQlwBT9IaW6+/aZgMKbOv+romNldH/9JxL QmEHLjRYP61ZL3r56qC7u230co2ElYmEBnd7mARtLjU66Y+pvc5PpUscxKF/j12GaxdVMUr5vqGr JlswQuckzXKMQk/i6EN8C0y5Ex3sUf8D/QAo7ud4Es9i8sy/j4dFOoT7c7i7Q6GdyxnmFOFPZ9ix 5yj6O76ffTn/Hzb7A/t4wG/EyB4++PnT+RECjAKNCYk1n+s/L+TW7t6Xtf8fUEsBAhUAFAACAAgA s2XrTtH8JUUibwAASKUBACgAsQAAAAAAAAAgKAAAAAAAAGRyYWZ0LWlldGYtdjZvcHMtbmF0NjQt ZGVwbG95bWVudC0wOC50eHQKACAAAAAAAAEAGAAANcrG1TfVAYDLYsfVN9UBgMtix9U31QFOVVgA TlVDWCgAAABkAHIAYQBmAHQALQBpAGUAdABmAC0AdgA2AG8AcABzAC0AbgBhAHQANgA0AC0AZABl AHAAbABvAHkAbQBlAG4AdAAtADAAOAAuAHQAeAB0AHVwLQABPXsYxmRyYWZ0LWlldGYtdjZvcHMt bmF0NjQtZGVwbG95bWVudC0wOC50eHRQSwUGAAAAAAEAAQAHAQAA828AAAAA --B_3645693920_1025268889-- From nobody Thu Jul 11 11:52:02 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CCC120091; Thu, 11 Jul 2019 11:51:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson , v6ops-chairs@ietf.org, swmike@swm.pp.se, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156287111965.12025.574936602251693337.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2019 11:51:59 -0700 Archived-At: Subject: [v6ops] Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 18:52:00 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Staying at No Record since I'm balloting late, but: Just asking "DNSSEC: Are there hosts validating DNSSEC?" may not be the best way to plan for the future, as it ignores the question of whether hosts may in the future start or want to start validating DNSSEC. It would be unfortunate if deploying a NAT64 solution hindered DNSSEC deployment as a side effect. From nobody Thu Jul 11 13:59:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FAE120123; Thu, 11 Jul 2019 13:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=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=theipv6company.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 h9CTzzfT4yKZ; Thu, 11 Jul 2019 13:59:00 -0700 (PDT) Received: from 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 0F4D6120043; Thu, 11 Jul 2019 13:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1562878736; x=1563483536; i=jordi.palet@theipv6company.com; 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=fp9BwycW3LD9swCYwg1jgGzuB4kmXx+G+Cv4gdfU/PY=; b=jlOjLKGKYhw9h 3kDNjSDUq7vYTxSn8jmvYjourvvdlDVfZua21GJ5tuN5DZSwbhE5Hl1aL6z5GeWk xTZDmFwXqAorNK8Mmuq7CvOZthQNUfa8HfMG29BLD/P1vUiIMVKmCucKjx1naxsD UVAgVyKyg5DCh5bqozMjV/bj96KQro= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Thu, 11 Jul 2019 22:58:56 +0200 X-Spam-Processed: consulintel.es, Thu, 11 Jul 2019 22:58:56 +0200 Received: from [10.10.10.130] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006322879.msg; Thu, 11 Jul 2019 22:58:56 +0200 X-MDRemoteIP: 2001:470:1f09:495:9012:1705:2c6:98c1 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 11 Jul 2019 22:58:56 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=1095f3ff43=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Thu, 11 Jul 2019 22:58:51 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: Benjamin Kaduk , The IESG CC: , Mikael Abrahamsson , , Message-ID: <1B6059DD-5BC9-4EBB-8278-A0EC436E543E@theipv6company.com> Thread-Topic: Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) References: <156287111965.12025.574936602251693337.idtracker@ietfa.amsl.com> In-Reply-To: <156287111965.12025.574936602251693337.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 20:59:03 -0000 Hi Benjamin, I think if you put that question in the overall document context, the inter= pretation is different. Actually, the document advocates clearly to avoid breaking DNSSEC, and the = best way to do that is either not doing DNS64 or (even better), ensuring th= at hosts do DNSSEC validation + DNS64 by themselves. This is possible alrea= dy if you're using 464XLAT. Also remember that the NAT64 is going to be used only for those services th= at are IPv4-only. I think we should advocate for those services to be IPv6-= enabled + DNSSEC-enabled. If we agree on that, then the only missing piece = is older IPv4-only boxes (in the customer side), which if can't be upgraded= to support IPv6, I expect as well they will not be upgraded to support DNS= SEC. Regards, Jordi @jordipalet =20 =EF=BB=BFEl 11/7/19 20:52, "Benjamin Kaduk via Datatracker" escribi=C3=B3: Benjamin Kaduk has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-07: No Record =20 When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) =20 =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 Staying at No Record since I'm balloting late, but: =20 Just asking "DNSSEC: Are there hosts validating DNSSEC?" may not be the best way to plan for the future, as it ignores the question of whether hosts may in the future start or want to start validating DNSSEC. It would be unfortunate if deploying a NAT64 solution hindered DNSSEC deployment as a side effect. =20 =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 Thu Jul 11 18:36:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C866120020; Thu, 11 Jul 2019 18:36:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKU9a6hVU64w; Thu, 11 Jul 2019 18:36:24 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 5A40712004D; Thu, 11 Jul 2019 18:36:24 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6C1aJe1006753; Thu, 11 Jul 2019 21:36:19 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6C1aJe1006753 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1562895379; bh=/qxHoOa/F1l0AloUL2zJd0a3waLzk0rXOv7MzqPZNMc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=GNsSL6m2x6EiQoAOQ866gl0aWeHCc55WLu57AVcqdzBUVtQaMO2WCScSDGGvtp7KM 3bvvMGU3iRHHMqEi1ndNrGCXalCkMQWCTh2WLhnc1RwMj6tRqB2Lyz7GVxJBgn57Gh X3vWv7/ObhLwGWIAGIyQyAr7lS4Nl32zc5BytkjM= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6C1aGss019322; Thu, 11 Jul 2019 21:36:16 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Thu, 11 Jul 2019 21:36:16 -0400 From: Roman Danyliw To: =?utf-8?B?Sm9yZGkgUGFsZXQgTWFydMOtbmV6?= , "mohamed.boucadair@orange.com" , =?utf-8?B?Sm9yZGkgUGFsZXQgTWFydMOtbmV6?= , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) Thread-Index: AQHVN4HXDqwoxMuSdEau0nlmDxvmhqbFOx6AgAAG+oCAAAYZgIAA6+5g Date: Fri, 12 Jul 2019 01:36:15 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33CE0F3@marchand> References: <156280587243.15387.3448756354265835528.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EAC9D83@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2A20F73E-F59A-4945-B563-8E6C9EDEDA03@theipv6company.com> In-Reply-To: <2A20F73E-F59A-4945-B563-8E6C9EDEDA03@theipv6company.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 01:36:26 -0000 SGkhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9yZGkgUGFsZXQg TWFydMOtbmV6IFttYWlsdG86am9yZGkucGFsZXRAdGhlaXB2NmNvbXBhbnkuY29tXQ0KPiBTZW50 OiBUaHVyc2RheSwgSnVseSAxMSwgMjAxOSAzOjI3IEFNDQo+IFRvOiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tOyBKb3JkaSBQYWxldCBNYXJ0w61uZXoNCj4gPGpvcmRpLnBhbGV0PTQwdGhl aXB2NmNvbXBhbnkuY29tQGRtYXJjLmlldGYub3JnPjsgUm9tYW4gRGFueWxpdw0KPiA8cmRkQGNl cnQub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiB2Nm9wc0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1kZXBsb3ltZW50QGlldGYub3JnOyB2Nm9wcy0NCj4gY2hh aXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBSb21hbiBEYW55bGl3J3MgTm8gT2JqZWN0aW9u IG9uIGRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtDQo+IGRlcGxveW1lbnQtMDc6ICh3aXRoIENPTU1F TlQpDQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBUaGFua3MgYSBsb3QhIHRoYXQncyBhIHZlcnkgZ29v ZCAibWlkZGxlIHBvaW50IiByZWZlcmVuY2UuIEl0IGlzIG9ubHkgYWJvdXQgVVMsDQo+IEkgd2ls bCB0cnkgdG8gc2VlIGlmIHRoZXJlIGlzIGEgc2ltaWxhciBvbmUgdGhhdCBzaG93cyBhbHNvIG90 aGVyIHJlZ2lvbnMuDQo+IA0KPiBSZWdhcmRzLA0KPiBKb3JkaQ0KPiBAam9yZGlwYWxldA0KPiAN Cj4gDQo+IO+7v0VsIDExLzcvMTkgOTowNSwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i DQo+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiBlc2NyaWJpw7M6DQo+IA0KPiAgICAg SGkgSm9yZGksIGFsbCwNCj4gDQo+ICAgICBPbmUgY29tbWVudCBiZWxvdy4NCj4gDQo+ICAgICBD aGVlcnMsDQo+ICAgICBNZWQNCj4gDQo+ICAgICA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiAgICAgPiBEZSA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZSBKb3JkaSBQYWxldA0KPiAgICAgPiBNYXJ0w61uZXoNCj4gICAgID4gRW52b3nD qSA6IGpldWRpIDExIGp1aWxsZXQgMjAxOSAwODo0MQ0KPiAgICAgPiDDgCA6IFJvbWFuIERhbnls aXc7IFRoZSBJRVNHDQo+ICAgICA+IENjIDogdjZvcHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdjZv cHMtbmF0NjQtZGVwbG95bWVudEBpZXRmLm9yZzsgdjZvcHMtDQo+ICAgICA+IGNoYWlyc0BpZXRm Lm9yZw0KPiAgICAgPiBPYmpldCA6IFJlOiBbdjZvcHNdIFJvbWFuIERhbnlsaXcncyBObyBPYmpl Y3Rpb24gb24gZHJhZnQtaWV0Zi12Nm9wcy0NCj4gICAgID4gbmF0NjQtZGVwbG95bWVudC0wNzog KHdpdGggQ09NTUVOVCkNCj4gICAgID4NCj4gICAgID4gSGkgUm9tYW4sDQo+ICAgICA+DQo+ICAg ICA+IFRoYW5rcyBhIGxvdCBmb3IgeW91ciBpbnB1dHMuDQo+ICAgICA+DQo+ICAgICA+IFNlZSBi ZWxvdywgaW4tbGluZS4NCj4gICAgID4NCj4gICAgID4gUmVnYXJkcywNCj4gICAgID4gSm9yZGkN Cj4gICAgID4gQGpvcmRpcGFsZXQNCj4gICAgID4NCj4gICAgID4NCj4gICAgID4g77u/RWwgMTEv Ny8xOSAyOjQ0LCAiUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYu b3JnPg0KPiAgICAgPiBlc2NyaWJpw7M6DQo+ICAgICA+DQo+ICAgICA+ICAgICBSb21hbiBEYW55 bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiAgICAg PiAgICAgZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1kZXBsb3ltZW50LTA3OiBObyBPYmplY3Rpb24N Cj4gICAgID4NCj4gICAgID4gICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiAgICAgPiAgICAgZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0 DQo+ICAgICA+IHRoaXMNCj4gICAgID4gICAgIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAgICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+ICAgICA+IGNyaXRlcmlh Lmh0bWwNCj4gICAgID4gICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICAgICBU aGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZv dW5kIGhlcmU6DQo+ICAgICA+ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXY2b3BzLW5hdDY0LWRlcGxveW1lbnQvDQo+ICAgICA+DQo+ICAgICA+DQo+ICAg ICA+DQo+ICAgICA+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgICA+ICAgICBDT01NRU5UOg0KPiAg ICAgPiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgPg0KPiAgICAgPiAgICAgKDEpIFNlY3Rpb24g NS4gIElzIHRoZXJlIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0aGF0IGNhbiBiZSBtYWRlDQo+ ICAgICA+IGFib3V0IHRoZQ0KPiAgICAgPiAgICAgc3VjY2Vzc2Z1bCBkZXBsb3ltZW50IG9uIGNl bGx1bGFyIG5ldHdvcmtzPw0KPiAgICAgPg0KPiAgICAgPiBEbyB5b3UgbWVhbiBjaXRpbmcgc3Bl Y2lmaWMgb3BlcmF0b3JzPyBJIGNhbiBuYW1lIHNldmVyYWwgaW4gYWxtb3N0DQo+IGV2ZXJ5DQo+ ICAgICA+IGNvbnRpbmVudCwgYnV0IEknbSBub3QgY29udmluY2VkIHRoaXMgaXMgY29ycmVjdCBp biBhbiBJRVRGIGRvY3VtZW50IC4uLg0KPiAgICAgPg0KDQpJJ20gZmxleGlibGUuICBUaGUgdGV4 dCBhc3NlcnRzIHRoaXMgaXMgdXNlZCB3aWRlbHkuICBJIHdhcyB3b25kZXJpbmcgaWYgYW55IGlu Zm9ybWF0aXZlIHJlZmVyZW5jZSBjb3VsZCBwb2ludCB0byB0aGF0Lg0KDQo+ICAgICBbTWVkXSBO byBuZWVkIHRvIGJlIGV4aGF1c3RpdmUgaGVyZSwgSSBzdWdnZXN0IHRvIGFkZCBvbmUgc2luZ2xl IHBvaW50ZXI6DQo+IGh0dHBzOi8vd3d3LndvcmxkaXB2NmxhdW5jaC5vcmcvbWFqb3ItbW9iaWxl LXVzLW5ldHdvcmtzLXBhc3MtNTAtaXB2Ni0NCj4gdGhyZXNob2xkLy4gSGF2aW5nIGFuIGluZm9y bWF0aXZlIHJlZmVyZW5jZSBpcyBoZWxwZnVsIGZvciB0aGlzIGtpbmQgb2YNCj4gc3RhdGVtZW50 cyAoYmVjYXVzZSBvdGhlcndpc2UsIHRoaXMgbWF5IGJlIGNvbnNpZGVyZWQgYXMgc3BlY3VsYXRp dmUpLg0KPg0KPiANCj4gICAgID4gICAgICgyKSBTZWN0aW9uIDcuICBDb25zaWRlciBhZGRpbmcg YW4gZXhwbGljaXQgc3RhdGVtZW50IHN1Y2ggYXMgdGhlDQo+ICAgICA+IGZvbGxvd2luZw0KPiAg ICAgPiAgICAgYWZ0ZXIgdGhlIGludHJvIHNlbnRlbmNlIHRoYXQg4oCcbm8gbmV3IHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIGFyZQ0KPiAgICAgPiBhZGRlZOKAnToNCj4gICAgID4NCj4gICAgID4g ICAgIEFzIG5vdGVkIGluIHRoZSByZWxldmFudCBzZWN0aW9ucyBhYm92ZSwgdGhlIE5BVDY0IGFu ZCBETlM2NA0KPiAgICAgPiB0ZWNobm9sb2dpZXMgY2FuDQo+ICAgICA+ICAgICBpbXBhY3QgdGhl IGVmZmljYWN5IG9yIGZ1bmN0aW9uYWxpdHkgb2Yga2V5IHNlY3VyaXR5IChpLmUuLCBETlNTRUMg YW5kDQo+ICAgICA+IFZQTnMpDQo+ICAgICA+ICAgICBhbmQgcHJpdmFjeSBwcmVzZXJ2aW5nIChp LmUuLCBETlMtb3Zlci1UTFMgYW5kIEROUy1vdmVyLUhUVFApDQo+ICAgICA+IHRlY2hub2xvZ2ll cy4NCj4gICAgID4NCj4gICAgID4gLT4gSSB3aWxsIG5lZWQgdG8gcmV3b3JkIGl0LiBUaGlzIGlz IHJpZ2h0IGluIHRoZSByZWZlcmVuY2UgdG8gRE5TU0VDLg0KPiAgICAgPiBIb3dldmVyIFZQTnMg YW5kIEROUyBwcml2YWN5LCB0aGUgcG9pbnQgaXMgb24gdGhlIG90aGVyIHdheSBhcm91bmQNCj4g KHRob3NlDQo+ICAgICA+IHRlY2hub2xvZ2llcyBjYW4gYXZvaWQgdGhlIEROUzY0IHBlcmZvcm1p bmcgY29ycmVjdGx5LCBhbmQgdGh1cywgYnJlYWsNCj4gICAgID4gTkFUNjQpLg0KDQpSaWdodC4g IEkgYm90Y2hlZCB3aGF0LWJyZWFrcy13aGF0IHNvIHBsZWFzZSBkbyByZXdvcmQgaXQuICANCg0K PiAgICAgPiAgICAgKDMpIEVkaXRvcmlhbCBOaXRzDQo+ICAgICA+DQo+ICAgICA+ICAgICAqKiBT ZWN0aW9uIDEuICBFZGl0b3JpYWwuIHMvdG9kYXkgdW5yZWFsaXN0aWMvdW5yZWFsaXN0aWMgdG9k YXkvDQo+ICAgICA+DQo+ICAgICA+ICAgICAqKiBTZWN0aW9uIDUuICBUeXBvLiAgcy9sZWFybiBo ZS9sZWFybiB0aGUvDQo+ICAgICA+DQo+ICAgICA+ICAgICAqKiBTZWN0aW9uIDUuICBFZGl0b3Jp YWwuICDigJxIdW5kcmVkcyBvZiBtaWxsaW9ucyBvZiB1c2Vyc+KAnSBtZW50aW9uZWQNCj4gICAg ID4gdHdpY2UuDQo+ICAgICA+DQo+ICAgICA+ICAgICBPTEQ6DQo+ICAgICA+ICAgICBOQVQ2NC80 NjRYTEFUIGhhcyBkZW1vbnN0cmF0ZWQgdG8gYmUgYSB2YWxpZCBjaG9pY2UgaW4gc2V2ZXJhbA0K PiAgICAgPiBzY2VuYXJpb3MNCj4gICAgID4gICAgIChJUHY2LUlQdjQgYW5kIElQdjQtSVB2Ni1J UHY0KSwgd2l0aCBodW5kcmVkcyBvZiBtaWxsaW9ucyBvZiB1c2VycywNCj4gICAgID4gYmVpbmcg dGhlDQo+ICAgICA+ICAgICBwcmVkb21pbmFudCBtZWNoYW5pc20gaW4gdGhlIG1ham9yaXR5IG9m IHRoZSBjZWxsdWxhciBuZXR3b3Jrcw0KPiAod2hpY2gNCj4gICAgID4gYWNjb3VudA0KPiAgICAg PiAgICAgZm9yIGh1bmRyZWRzIG9mIG1pbGxpb25zIG9mIHVzZXJzKS4NCj4gICAgID4NCj4gICAg ID4gICAgIE5FVzoNCj4gICAgID4gICAgIE5BVDY0LzQ2NFhMQVQgaGFzIGRlbW9uc3RyYXRlZCB0 byBiZSBhIHZhbGlkIGNob2ljZSBpbiBzZXZlcmFsDQo+ICAgICA+IHNjZW5hcmlvcw0KPiAgICAg PiAgICAgKElQdjYtSVB2NCBhbmQgSVB2NC1JUHY2LUlQdjQpIGluIGNlbGx1bGFyIG5ldHdvcmtz IHdoaWNoIGFjY291bnQgZm9yDQo+ICAgICA+IGh1bmRyZWRzDQo+ICAgICA+ICAgICBvZiBtaWxs aW9ucyBvZiB1c2Vycy4NCj4gICAgID4NCj4gICAgID4gTm90ZWQgYW5kIGNvcnJlY3RlZCBhbGwg dGhvc2Ugbml0cyBpbiBteSBpbnRlcm5hbCB2ZXJzaW9uLiBJIHdpbGwgd2FpdCBhDQo+ICAgICA+ IGNvdXBsZSBvZiBkYXlzIGJlZm9yZSBwdWJsaXNoaW5nIGl0LCBpbiBjYXNlIHRoZXJlIGFyZSBh bnkgZnVydGhlciBpbnB1dHMuDQoNClRoYW5rcyBmb3IgZml4aW5nIHRoZXNlLg0KDQpUaGFua3Ms DQpSb21hbg0KDQo+ICAgICA+DQo+IA0KPiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91IHJl YWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cDovL3d3dy50aGVpcHY2Y29tcGFueS5j b20NCj4gVGhlIElQdjYgQ29tcGFueQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29u dGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlkZW50 aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUg dXNlIG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1l eHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwNCj4gY29weWluZywgZGlzdHJpYnV0aW9u IG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZg0KPiBw YXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgd2lsbCBiZQ0KPiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZQ0KPiB0aGF0IGFueSBkaXNjbG9z dXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlz DQo+IGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZp bGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLA0KPiB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmlt aW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwNCj4gc2VuZGVy IHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCj4gDQo+ IA0KDQo= From nobody Fri Jul 12 02:31:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A5A120133; Fri, 12 Jul 2019 02:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 CVub5Xr2gPiQ; Fri, 12 Jul 2019 02:31:04 -0700 (PDT) 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 7AB38120161; Fri, 12 Jul 2019 02:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1562923860; x=1563528660; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=33o2cjKTavyWnIvrDrnVU q85gPZnoQvl+fiyeJQXVo4=; b=a+j7co8FdpAQJiPmjdkhzCSmZujsv8stqWEi7 0tDxB26COJEVDapnBcdUDIyFEGBhhVAEb3hsslv0+GGI9xmeadF2EFJ6ur8G2ULG U4C8EakBug5gNM69gDzy2F+TcxTCeQ2sYRdRTLIvmiewWC0X9097Hk7KzSYtgtcx NhIgmg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 12 Jul 2019 11:31:00 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 12 Jul 2019 11:31:00 +0200 Received: from [10.10.10.146] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006323423.msg; Fri, 12 Jul 2019 11:30:58 +0200 X-MDRemoteIP: 2001:470:1f09:495:5c22:fcb0:1779:b2bb X-MDHelo: [10.10.10.146] X-MDArrival-Date: Fri, 12 Jul 2019 11:30:58 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=109661f471=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Fri, 12 Jul 2019 11:30:54 +0200 From: JORDI PALET MARTINEZ To: Roman Danyliw , Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= , "mohamed.boucadair@orange.com" , Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Message-ID: <429F374B-C5A0-4038-9DA6-48138E1946D0@consulintel.es> Thread-Topic: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 09:31:08 -0000 Thanks a lot, done already in v08. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 12/7/19 3:37, "v6ops en nombre de Roman Danyliw" escribi=C3=B3: Hi! =20 > -----Original Message----- > From: Jordi Palet Mart=C3=ADnez [mailto:jordi.palet@theipv6company.co= m] > Sent: Thursday, July 11, 2019 3:27 AM > To: mohamed.boucadair@orange.com; Jordi Palet Mart=C3=ADnez > ; Roman Danyliw > ; The IESG > Cc: v6ops@ietf.org; draft-ietf-v6ops-nat64-deployment@ietf.org; v6ops= - > chairs@ietf.org > Subject: Re: Roman Danyliw's No Objection on draft-ietf-v6ops-nat64- > deployment-07: (with COMMENT) >=20 > Hi Med, >=20 > Thanks a lot! that's a very good "middle point" reference. It is only= about US, > I will try to see if there is a similar one that shows also other reg= ions. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 > =EF=BB=BFEl 11/7/19 9:05, "mohamed.boucadair@orange.com" > escribi=C3=B3: >=20 > Hi Jordi, all, >=20 > One comment below. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Jordi = Palet > > Mart=C3=ADnez > > Envoy=C3=A9 : jeudi 11 juillet 2019 08:41 > > =C3=80 : Roman Danyliw; The IESG > > Cc : v6ops@ietf.org; draft-ietf-v6ops-nat64-deployment@ietf.org= ; v6ops- > > chairs@ietf.org > > Objet : Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-= v6ops- > > nat64-deployment-07: (with COMMENT) > > > > Hi Roman, > > > > Thanks a lot for your inputs. > > > > See below, in-line. > > > > Regards, > > Jordi > > @jordipalet > > > > > > =EF=BB=BFEl 11/7/19 2:44, "Roman Danyliw via Datatracker" > > escribi=C3=B3: > > > > Roman Danyliw has entered the following ballot position for > > draft-ietf-v6ops-nat64-deployment-07: No Objection > > > > When responding, please keep the subject line intact and re= ply to all > > email addresses included in the To and CC lines. (Feel free= to cut > > this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss= - > > criteria.html > > for more information about IESG DISCUSS and COMMENT positio= ns. > > > > > > The document, along with other ballot positions, can be fou= nd here: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-dep= loyment/ > > > > > > > > -----------------------------------------------------------= ----------- > > COMMENT: > > -----------------------------------------------------------= ----------- > > > > (1) Section 5. Is there an informative reference that can = be made > > about the > > successful deployment on cellular networks? > > > > Do you mean citing specific operators? I can name several in al= most > every > > continent, but I'm not convinced this is correct in an IETF doc= ument ... > > =20 I'm flexible. The text asserts this is used widely. I was wondering i= f any informative reference could point to that. =20 > [Med] No need to be exhaustive here, I suggest to add one single = pointer: > https://www.worldipv6launch.org/major-mobile-us-networks-pass-50-ipv6= - > threshold/. Having an informative reference is helpful for this kind = of > statements (because otherwise, this may be considered as speculative)= . > >=20 > > (2) Section 7. Consider adding an explicit statement such = as the > > following > > after the intro sentence that =E2=80=9Cno new security cons= iderations are > > added=E2=80=9D: > > > > As noted in the relevant sections above, the NAT64 and DNS6= 4 > > technologies can > > impact the efficacy or functionality of key security (i.e.,= DNSSEC and > > VPNs) > > and privacy preserving (i.e., DNS-over-TLS and DNS-over-HTT= P) > > technologies. > > > > -> I will need to reword it. This is right in the reference to = DNSSEC. > > However VPNs and DNS privacy, the point is on the other way aro= und > (those > > technologies can avoid the DNS64 performing correctly, and thus= , break > > NAT64). =20 Right. I botched what-breaks-what so please do reword it. =20 =20 > > (3) Editorial Nits > > > > ** Section 1. Editorial. s/today unrealistic/unrealistic t= oday/ > > > > ** Section 5. Typo. s/learn he/learn the/ > > > > ** Section 5. Editorial. =E2=80=9CHundreds of millions of= users=E2=80=9D mentioned > > twice. > > > > OLD: > > NAT64/464XLAT has demonstrated to be a valid choice in seve= ral > > scenarios > > (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions o= f users, > > being the > > predominant mechanism in the majority of the cellular netwo= rks > (which > > account > > for hundreds of millions of users). > > > > NEW: > > NAT64/464XLAT has demonstrated to be a valid choice in seve= ral > > scenarios > > (IPv6-IPv4 and IPv4-IPv6-IPv4) in cellular networks which a= ccount for > > hundreds > > of millions of users. > > > > Noted and corrected all those nits in my internal version. I wi= ll wait a > > couple of days before publishing it, in case there are any furt= her inputs. =20 Thanks for fixing these. =20 Thanks, Roman =20 > > >=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 > confidential. The information is intended to be for the exclusive use= of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n 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 origi= nal > sender to inform about this communication and delete it. >=20 >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Fri Jul 12 07:11:36 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE221200CD; Fri, 12 Jul 2019 07:11:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <156294068884.27192.3184024158766672000@ietfa.amsl.com> Date: Fri, 12 Jul 2019 07:11:29 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 14:11:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-08.txt Pages : 45 Date : 2019-07-12 Abstract: This document describes how NAT64 (including 464XLAT) can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise, and possible optimizations. The document also discusses issues to be considered when having IPv6-only connectivity, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-08 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-deployment-08 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 Fri Jul 12 19:26:43 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3DD120074; Fri, 12 Jul 2019 19:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3NQZfscFfFL; Fri, 12 Jul 2019 19:26:33 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7499712000E; Fri, 12 Jul 2019 19:26:32 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6D2QQYC032041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 22:26:29 -0400 Date: Fri, 12 Jul 2019 21:26:26 -0500 From: Benjamin Kaduk To: Jordi Palet =?iso-8859-1?Q?Mart=EDnez?= Cc: The IESG , draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson , v6ops-chairs@ietf.org, v6ops@ietf.org Message-ID: <20190713022625.GT16418@mit.edu> References: <156287111965.12025.574936602251693337.idtracker@ietfa.amsl.com> <1B6059DD-5BC9-4EBB-8278-A0EC436E543E@theipv6company.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1B6059DD-5BC9-4EBB-8278-A0EC436E543E@theipv6company.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 02:26:37 -0000 On Thu, Jul 11, 2019 at 10:58:51PM +0200, Jordi Palet Martínez wrote: > Hi Benjamin, > > I think if you put that question in the overall document context, the interpretation is different. Oh, definitely. I was just making an editorial comment about the wording of question (a) in Section 3.3. > Actually, the document advocates clearly to avoid breaking DNSSEC, and the best way to do that is either not doing DNS64 or (even better), ensuring that hosts do DNSSEC validation + DNS64 by themselves. This is possible already if you're using 464XLAT. > > Also remember that the NAT64 is going to be used only for those services that are IPv4-only. I think we should advocate for those services to be IPv6-enabled + DNSSEC-enabled. If we agree on that, then the only missing piece is older IPv4-only boxes (in the customer side), which if can't be upgraded to support IPv6, I expect as well they will not be upgraded to support DNSSEC. That sounds pretty likely, yeah; only some weird combination of legacy technology and regulatory decree seems likely to get past it. Thanks for writing the document; it was a good read! -Ben > Regards, > Jordi > @jordipalet > > > El 11/7/19 20:52, "Benjamin Kaduk via Datatracker" escribió: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-v6ops-nat64-deployment-07: No Record > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Staying at No Record since I'm balloting late, but: > > Just asking "DNSSEC: Are there hosts validating DNSSEC?" may not be the > best way to plan for the future, as it ignores the question of whether > hosts may in the future start or want to start validating DNSSEC. > It would be unfortunate if deploying a NAT64 solution hindered DNSSEC > deployment as a side effect. > > > > > > > ********************************************** > 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. > > > From nobody Sat Jul 13 00:01:58 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C781200BA; Sat, 13 Jul 2019 00:01:49 -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, FROM_EXCESS_BASE64=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.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 mfXlpiF9_EZh; Sat, 13 Jul 2019 00:01:47 -0700 (PDT) Received: from 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 9C0D7120112; Sat, 13 Jul 2019 00:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1563001302; x=1563606102; i=jordi.palet@theipv6company.com; 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=Or/nv9ph88ukW/GAddF5TcKZcD7VD/P4I6+o/0z5218=; b=IBin/XgMaGdlu Zen3Xa/513ezR/XHsKYG5WGVi42MxKa5/DvAIIfX1XJm2omZoXbJeIiBfvrETFjm +w0+CqKk5hml/0nNpat8Og054egggjnV+xJbPBBufcLSSKDCxNVdjyzMC+YlWlG5 BdbCpne6TRPDCa6xFOmSweYqS9huw4= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Sat, 13 Jul 2019 09:01:42 +0200 X-Spam-Processed: consulintel.es, Sat, 13 Jul 2019 09:01:40 +0200 Received: from [10.10.10.146] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006324285.msg; Sat, 13 Jul 2019 09:01:39 +0200 X-MDRemoteIP: 2001:470:1f09:495:968:ab2c:858c:531b X-MDHelo: [10.10.10.146] X-MDArrival-Date: Sat, 13 Jul 2019 09:01:39 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=1097a26248=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Sat, 13 Jul 2019 09:01:39 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: Benjamin Kaduk CC: The IESG , , Mikael Abrahamsson , , Message-ID: Thread-Topic: Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) References: <156287111965.12025.574936602251693337.idtracker@ietfa.amsl.com> <1B6059DD-5BC9-4EBB-8278-A0EC436E543E@theipv6company.com> <20190713022625.GT16418@mit.edu> In-Reply-To: <20190713022625.GT16418@mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 07:01:50 -0000 Thanks Ben, I guess then the RFC Editor may tell something if they consider that that s= pecific question should be reworded. Regards, Jordi @jordipalet =20 =EF=BB=BFEl 13/7/19 4:26, "Benjamin Kaduk" escribi=C3=B3: On Thu, Jul 11, 2019 at 10:58:51PM +0200, Jordi Palet Mart=C3=ADnez wro= te: > Hi Benjamin, >=20 > I think if you put that question in the overall document context, the= interpretation is different. =20 Oh, definitely. I was just making an editorial comment about the wordi= ng of question (a) in Section 3.3. =20 > Actually, the document advocates clearly to avoid breaking DNSSEC, an= d the best way to do that is either not doing DNS64 or (even better), ensur= ing that hosts do DNSSEC validation + DNS64 by themselves. This is possible= already if you're using 464XLAT. >=20 > Also remember that the NAT64 is going to be used only for those servi= ces that are IPv4-only. I think we should advocate for those services to be= IPv6-enabled + DNSSEC-enabled. If we agree on that, then the only missing = piece is older IPv4-only boxes (in the customer side), which if can't be up= graded to support IPv6, I expect as well they will not be upgraded to suppo= rt DNSSEC. =20 That sounds pretty likely, yeah; only some weird combination of legacy technology and regulatory decree seems likely to get past it. =20 Thanks for writing the document; it was a good read! =20 -Ben =20 > Regards, > Jordi > @jordipalet > =20 >=20 > =EF=BB=BFEl 11/7/19 20:52, "Benjamin Kaduk via Datatracker" escribi=C3=B3: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-v6ops-nat64-deployment-07: No Record > =20 > When responding, please keep the subject line intact and reply to= all > email addresses included in the To and CC lines. (Feel free to cu= t this > introductory paragraph, however.) > =20 > =20 > Please refer to https://www.ietf.org/iesg/statement/discuss-crite= ria.html > for more information about IESG DISCUSS and COMMENT positions. > =20 > =20 > The document, along with other ballot positions, can be found her= e: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deploymen= t/ > =20 > =20 > =20 > -----------------------------------------------------------------= ----- > COMMENT: > -----------------------------------------------------------------= ----- > =20 > Staying at No Record since I'm balloting late, but: > =20 > Just asking "DNSSEC: Are there hosts validating DNSSEC?" may not = be the > best way to plan for the future, as it ignores the question of wh= ether > hosts may in the future start or want to start validating DNSSEC. > It would be unfortunate if deploying a NAT64 solution hindered DN= SSEC > deployment as a side effect. > =20 > =20 > =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 confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=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 Sat Jul 13 08:02:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FF71200CD for ; Sat, 13 Jul 2019 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, MIME_QP_LONG_LINE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 6yabDZOgZXem for ; Sat, 13 Jul 2019 08:02:07 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 ED56C1200C5 for ; Sat, 13 Jul 2019 08:02:06 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id i2so6201811plt.1 for ; Sat, 13 Jul 2019 08:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :references:in-reply-to:to; bh=3AIaxZVsd3AfOpp+QL1dHXqeFohxfbSKFBK5RPsacNI=; b=Y6ItFTgijdzziGSts0P/g+5FFOGb8HB60j91QPxUvndyJbCLb/LnXEQmOuYvZmGnNU JsDk4/J8WlBNLpBjUSmlphByyLv6SUi4bhMuDZydh8k330p3GyOBLVpTk2P/a6Wmjicf 5iQ1rlQ9g8sdgbAPchxgKIcFFpIvzKr8I8tyD0srt+uiY2akPi8ftU1+XOfjN8r/0lNS LPT8yyMkTxqanElvVTbTjpfmcTpaRFjNA2n2u9Jy5UlVxWPPEmsvSOg0X8etmTyk9UoU a2iIaL2dFknno2eKDkE/GKI6UEdA58s/LL9xUMiVspQL4DT5XEt1HLENXjjBpL6fWTio 98Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:references:in-reply-to:to; bh=3AIaxZVsd3AfOpp+QL1dHXqeFohxfbSKFBK5RPsacNI=; b=NXjT4pxrqD3dW16gXe3nsIspjDUuIMeflspPRT8SrKPgMbfCGhfFAk2+r97PGJVisj lkdOJhwV2Ysa76Ons4Q3DUSqdmlptwGs2BKLs0ZYPSbDw/w/I6HDu/JP6NjZRBW4YI1E xZyG+vL07FFH5pYhFuKIBhWd2OuxCEJy0DkCcuCOkcXsOmu4dM7RhCPqigLCRuGmjrgQ CKsqwjehhYewGcZVks7JwhBciXIT8yC739osercvFhnmvi5crCW/smi4RpLInF1/XVbR ClWCmmgHb9gkZ0RB/hwXmrMYZYZF4xJOx71+3djQxsvWlb14Ti/DFOfZlkvHMVPRLhQW MVEg== X-Gm-Message-State: APjAAAXqBg0buzU7g25mIzw6961oW3X+BYH7Tckjq4txxYChrjtt3XFs Rk4hAw8x6sIjOVDUiC0M0q6rVSOo X-Google-Smtp-Source: APXvYqzvf9Z+HurMr4JzJVbEZeu+aVe1jP7D71Qdyjau5C3PAJzcNTUxqnODDNqXqo2vwFqX2meKZQ== X-Received: by 2002:a17:902:f301:: with SMTP id gb1mr17848541plb.292.1563030125904; Sat, 13 Jul 2019 08:02:05 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:accb:296c:3543:1270? ([2601:646:c005:a10:accb:296c:3543:1270]) by smtp.gmail.com with ESMTPSA id b126sm20337841pfa.126.2019.07.13.08.02.04 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jul 2019 08:02:04 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-58DBAED4-3F49-43B7-A656-6C119A1BA31B Content-Transfer-Encoding: 7bit From: Fred Baker Mime-Version: 1.0 (1.0) Date: Sat, 13 Jul 2019 08:02:02 -0700 Message-Id: References: In-Reply-To: To: v6ops@ietf.org X-Mailer: iPhone Mail (17A5508m) Archived-At: Subject: Re: [v6ops] Minute-taking tool X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 15:02:09 -0000 --Apple-Mail-58DBAED4-3F49-43B7-A656-6C119A1BA31B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Next week, we will need a jabber scribe and a note taker. Attached is a sugg= estion of a tool for taking minutes, if that is interesting. V6ops meets at 1= 5:50 Monday afternoon Monday July 22 Sent using a machine that autocorrects in interesting ways... > On Jul 12, 2019, at 12:32 PM, Jeffrey (Zhaohui) Zhang wrote: >=20 > =EF=BB=BF > Hi, > =20 > I would like to recommend a smart phone app for minute taking: > =20 > https://apps.apple.com/us/app/otter-ai-meeting-voice-notes/id1276437113 (i= Phone) > https://play.google.com/store/apps/details?id=3Dcom.aisense.otter&hl=3Den_= US (Android) > =20 > Some of you might have used it. It records the audio, transcripts into tex= t, and you can playback the recording with the corresponding text highlighte= d for you word by word. > =20 > It comes with a free plan of 600 minutes per month. With the help of the t= ool you won=E2=80=99t have difficulty finding someone to take the minutes fo= r you. > =20 > Jeffrey > =20 > =20 >=20 > Juniper Business Use Only --Apple-Mail-58DBAED4-3F49-43B7-A656-6C119A1BA31B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent using a= machine that autocorrects in interesting ways...
=EF=BB=BF =

Hi,

 

I would like to recommend a smart phone app for minut= e taking:

 

https://apps.apple.com/us/app/otter-ai-meetin= g-voice-notes/id1276437113 (iPhone)

https://play.google.com/store/apps/d= etails?id=3Dcom.aisense.otter&hl=3Den_US (Android)

 

Some of you might have used it. It records the audio,= transcripts into text, and you can playback the recording with the correspo= nding text highlighted for you word by word.

 

It comes with a free plan of 600 minutes per month. W= ith the help of the tool you won=E2=80=99t have difficulty finding someone t= o take the minutes for you.

 

Jeffrey

 

 


Juniper Business U= se Only

= --Apple-Mail-58DBAED4-3F49-43B7-A656-6C119A1BA31B-- From nobody Mon Jul 15 12:49:05 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EF31202DB; Mon, 15 Jul 2019 12:49:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , v6ops@ietf.org, v6ops-chairs@ietf.org, Mikael Abrahamsson , rfc-editor@rfc-editor.org, draft-ietf-v6ops-nat64-deployment@ietf.org, warren@kumari.net, swmike@swm.pp.se Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156322014401.27079.13445431277610847275.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2019 12:49:04 -0700 Archived-At: Subject: [v6ops] Document Action: 'Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks' to Informational RFC (draft-ietf-v6ops-nat64-deployment-08.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 19:49:04 -0000 The IESG has approved the following document: - 'Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks' (draft-ietf-v6ops-nat64-deployment-08.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ Technical Summary This document describes how NAT64 (including 464XLAT) can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise, and possible optimizations. The document also discusses issues to be considered when having IPv6-only connectivity, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. Working Group Summary The draft started its life as draft-palet-v6ops-464xlat-deployment in October 2017, then evolved into draft-palet-v6ops-nat64-deployment in March 2018 as a NAT64 deployment guideline document intended to be BCP. It was adopted as a working group document as draft-ietf-v6ops-nat64-deployment in July 2018 with changed intended status to Informational. The discussions in the WG has been supportive of the draft, the author has taken feedback/suggestions into account and over time evolved/progressed the document during productive discussions. There has been no general opposition to the draft itself apart from people opposing on principle on DNS64 "breaking" DNSSEC. That is not the fault of this draft and this draft suggests no technological changes. Document Quality The document describes technology implemented by numerous networks and devices, primarily in mobile networks. The author proposes this technology to be used in more deployment scenarios and that's the motivation for this draft, to analyse the deployment considerations for other types of network types. The document has received substantial technical and stylistic feedback and I believe the document is in good technical shape. The RFC editor might have some linguistic/grammar/stylistic work to do on this draft, but I believe this is normal when the author is non-native english speaker/writer. Personnel Shepherd: Mikael Abrahamsson RAD: Warren Kumari From nobody Tue Jul 16 17:19:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C325D12004E for ; Tue, 16 Jul 2019 17:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 9vc1taLguwA5 for ; Tue, 16 Jul 2019 17:19:07 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 4FC471200FF for ; Tue, 16 Jul 2019 17:19:07 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id r21so17047302otq.6 for ; Tue, 16 Jul 2019 17:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=VbX/4PJYKqIx/kiMV8NthHBM82duiIizsXDQsANA/pM=; b=B1cTDWMlCnEitv9/nvhiwwPgA4Ma0DvxldBN2lGsUFh2svtaxSHiAUx8DnZzHp+3Jg JgQ0LYnOR8NmEzTvrI9sVLGZV5wBrgixOmZazO3dm8XJXt0hFCLUw+O6gf0mXAGQs+g9 N4Eiwh6LuM2YrHeHA1SPHYsh83eLhUPFGCMaJIFQn3L2R5KXvr7ElljdhvffFt57JQoq NPd2/xVcqFzpe0F1a6OHcySmhCP/sV0V2kWJnVSvq5IlghoU3UDtVrYVhMMJ95AfsBPL 8gyjh7RWL9u6nd/Lo/4hEom+Gy3MCGVpZB5LsnGug1oIiFKW02bWdpTepUU61uBnfThm wygg== 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:references :to:date; bh=VbX/4PJYKqIx/kiMV8NthHBM82duiIizsXDQsANA/pM=; b=WLcmVUe3hLOF0ZsN7GMLa/EXHRn1EcvUPyv/3zOdKo/vw1pIdzTaFW/nO/thY+MtVO nyF0SRCRslVFvhVaxo88kFDf3OT0RQjrFAFkU9rlopWbiJLm02YT4sLsc5QSFTS9XoEE iWsoJDMVRoYVszJ5lTfSf6fYg2mnXCR/m3lmYVxTEUovWpy0NKMYVLD0fUAE5x6QENH8 O0iUX/JJuPVaVWetjlwQ9SDW+NiM4Z/Gu6YDpLrBqeSKe3OUir0O2X40j95lpsqU9iaO 8GmFgma0oab/wkcwNShHORG6J89XKLbHZLmp/dSeP7BKnKwrnIkxBsNDEtpg+LzbiWcK NOKQ== X-Gm-Message-State: APjAAAU0dWNmQFfPd769VWkraVyFaejF3RbWX+tKq5xfGi+fdvfpQiOX bXzD0kIOLR5hrBCtjOeckj0hFRoS X-Google-Smtp-Source: APXvYqy1z4dLu9s1nXdPhWfhQC3hPAjapw2Nfrpu/woucrFamLzXUKlSluaeN3t64lABEqRn/yV2Jg== X-Received: by 2002:a9d:529:: with SMTP id 38mr27142506otw.145.1563322746433; Tue, 16 Jul 2019 17:19:06 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1021? ([2600:8802:5903:df16::1021]) by smtp.gmail.com with ESMTPSA id v203sm8688918oie.5.2019.07.16.17.19.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 17:19:05 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_833F5C63-2E3E-4725-9216-BE5CC13FDDC8" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Message-Id: <1FBC4202-9FE6-4BB6-85CD-1BD5F81AAE4A@gmail.com> References: <20190328213600.GF70134@ernw.de> To: IPv6 Operations Date: Tue, 16 Jul 2019 17:19:04 -0700 X-Mailer: Apple Mail (2.3564) Archived-At: Subject: [v6ops] Fwd: draft-ietf-opsec-v6-16 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 00:19:10 -0000 --Apple-Mail=_833F5C63-2E3E-4725-9216-BE5CC13FDDC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Following up from IETF 104, the draft-ietf-opsec-v6 authors have updated = their draft and are preparing for working group last call in opsec. It = will be on the v6ops agenda for IETF 105, and if there are any = additional comments the authors would like to have them, please.=20 > Begin forwarded message: >=20 > From: Enno Rey > Subject: [v6ops] draft-ietf-opsec-v6-16 > Date: March 28, 2019 at 2:36:00 PM PDT > To: v6ops@ietf.org > Cc: merike@doubleshotsecurity.com >=20 > Hi, >=20 > as briefly announced by Fred at the end of the session we, the authors = of draft-ietf-opsec-v6 ("Operational Security Considerations for IPv6 = Networks"), would like to ask the group for review and feedback on the = document (to enter WGLC in opsec). The initial idea behind the doc was = to provide security-oriented input on v6 networks (to operations) as we = felt that there was quite some interest in such input coming from the = IETF (similar to e.g. RFC 7381). It has already undergone several = revisions, striving - as we think - for a reasonable balance of = discussing options while at the same time providing some guidance. > We would be very happy about any additional critical feedback or = suggestions from your side. Thank you in advance for your efforts! >=20 > best >=20 > Enno >=20 > --=20 > Enno Rey >=20 > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902=20 >=20 > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Florian Grunow, Enno Rey >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_833F5C63-2E3E-4725-9216-BE5CC13FDDC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Following up from IETF 104, the draft-ietf-opsec-v6 authors = have updated their draft and are preparing for working group last call = in opsec. It will be on the v6ops agenda for IETF 105, and if there are = any additional comments the authors would like to have them, = please. 

Begin forwarded message:

From: = Enno Rey <erey@ernw.de>
Subject: = [v6ops] = draft-ietf-opsec-v6-16
Date: = March 28, 2019 at 2:36:00 PM = PDT
To: = v6ops@ietf.org
Cc: merike@doubleshotsecurity.com

Hi,

as briefly announced by Fred = at the end of the session we, the authors of draft-ietf-opsec-v6 = ("Operational Security Considerations for IPv6 Networks"), would like to = ask the group for review and feedback on the document (to enter WGLC in = opsec). The initial idea behind the doc was to provide security-oriented = input on v6 networks (to operations) as we felt that there was quite = some interest in such input coming from the IETF (similar to e.g. RFC = 7381). It has already undergone several revisions, striving - as we = think - for a reasonable balance of discussing options while at the same = time providing some guidance.
We would be very happy about = any additional critical feedback or suggestions from your side. Thank = you in advance for your efforts!

best

Enno

--
Enno Rey

ERNW GmbH - = Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 = 419008 - Cell +49 173 6745902

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Florian Grunow, Enno Rey

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Blog: www.insinuator.net || = Conference: www.troopers.de
Twitter: = @Enno_Insinuator
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

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

---------------------------------------------------------------= -----------------
The fact that = there is a highway to hell and a stairway to heaven is an interesting = comment on projected traffic volume...

= --Apple-Mail=_833F5C63-2E3E-4725-9216-BE5CC13FDDC8-- From nobody Tue Jul 16 17:27:29 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184D2120088 for ; Tue, 16 Jul 2019 17:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 ZG1RDVpwC85f for ; Tue, 16 Jul 2019 17:27:26 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 6DF3812004C for ; Tue, 16 Jul 2019 17:27:26 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id q20so23097215otl.0 for ; Tue, 16 Jul 2019 17:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=2lY409Ux/6RLpzKfuFXEflCKlzKFC62LJN9ksqeViG4=; b=fLHNiGUR/Q/aFduA/uZ5aJX/Q+Wqc2tL/Xo7qUyS5kuSkaK317sKQB1yWFg5XdwAJq J6kmmPPuSFYOAjKNDfyXNTkiYDaMCkbWki0FCOjXXiSDiYL8o8hePWT4WfE8HWEFiu0H V3RpFnN95AXoI0sYIBcx4IPj1DgHSBcLZMCkSf7HgEJD41aSezbn08mVE+JBcgj6chMG BftE8MorxTkGcrwHEjbXNsdvWZdd1kbnsFsGMuOYwdGfqfzKQ9ARoLA8d4vqeOp7wIXG OvEsuDF9iGR4h4tlv+gaj0paYNHcJoFtVLQbh0cLpT6qYyziBTsGVS7H133wLoGtjEGP ADEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=2lY409Ux/6RLpzKfuFXEflCKlzKFC62LJN9ksqeViG4=; b=uUCfli398YwGmP3+4Zd6ep6S071F7LxCnyuKCp6LlAliQxhtF3w4uW/2JbYSbXkQ9+ BJS90wqUSN7AghUsxGsOvax1d0xsDIgwH4A/+ifQji1L4WON+WXXL5/rJTi7siwAOHHC kX6xhlY0R3qMYWRXA0L3y9a/A+Y3qj3OOOIACb8rkl55a1wHgQrbgbn3sQ5/TrlcZNRw kLZ23n1jGd9jfKmv3TpP29kZ0M4/UYpqT7ilmV9JtLGLj8jUtMTF3JhfTs89xfwQSFA5 SHkBVpQAF6NpXUCxYFv9duC2qj2DSf9iekdy3+Y+LvYwOPWdwsp8oLPO3GQVZfNnPquN oeAA== X-Gm-Message-State: APjAAAUdZpwzTDfCzASZjF0RVR0t2RmgiVOXAnXHPcudw2u3MRPnOvvP PiR0IwVRGzUiSRhhf12QaSSND7Um X-Google-Smtp-Source: APXvYqwaeErFlMzl/yD/ZW4gDpfVzj+FsTIw+xWUfeChWIkMmYMGsGohK3kIzfDd/59lWg4zhEDqVA== X-Received: by 2002:a05:6830:1042:: with SMTP id b2mr27634493otp.345.1563323245560; Tue, 16 Jul 2019 17:27:25 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1021? ([2600:8802:5903:df16::1021]) by smtp.gmail.com with ESMTPSA id e78sm8081407oib.50.2019.07.16.17.27.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 17:27:24 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Message-Id: <5694C033-A38F-4455-9673-EACAAC6324F3@gmail.com> Date: Tue, 16 Jul 2019 17:27:23 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3564) Archived-At: Subject: [v6ops] IPv6-only draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 00:27:28 -0000 The author is asking for time on the agenda at IETF 105; I told him that = if there was time at the end of the meeting, it could be part of "AOB". = I don't see any discussion on the draft since November 2017. FYI, draft-ietf-6man-ipv6only-flag is a different topic. https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only = https://mailarchive.ietf.org/arch/search/?qdr=3Da&q=3D%22draft-palet-v6ops= -ipv6-only%22 Your comments appreciated. = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... From nobody Tue Jul 16 18:12:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD02E120045 for ; Tue, 16 Jul 2019 18:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 R6XBq5sCLFF7 for ; Tue, 16 Jul 2019 18:12:17 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 D880D12000F for ; Tue, 16 Jul 2019 18:12:17 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id r6so23218836oti.3 for ; Tue, 16 Jul 2019 18:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=dtm98mJjyh2QAjD/k7VhGNMNi6Pbv7ey+LwATkbFSdM=; b=qZPV/3WIcqXt4/PVJBgjWJ6vw+oEDuWZrHBUTVNzE28+Ql5Da09JnDHUksJuO9QJlx ZbvkbBjKtivmCZcZGoclplWiY2HvBT+bfhRHeClgET5vNpxOLoRCm/loKjPTuTDSd8Np S4tRR89pAAD5nFYXaKgBsxVfDbymnCgHXYEGx29VltPS2xsS2gWPUSI5ODw57/kyuVcX iFjCWQ1XTxG5vl7rUGiL1ea/24MkwAAORsRE6dHsHZXju5PLeqVAc6sSmbAQBfa62rbA EfHjzfGA4wMLx9MxDzMRRADvlzXDf+PzLQRwaFXYpY08Ua+rCEpNO15UdB/boWQuhTZM OntQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=dtm98mJjyh2QAjD/k7VhGNMNi6Pbv7ey+LwATkbFSdM=; b=PuvZjvrA7lsaVb/JvqRLyXYWXPBm0hnyHI6yQWWWP6hukyEMmkwvT0UYGHVcSjlbS4 7v7H0iwIV1iMigP16qj2VKnlH/F+T1mToHzHnHggOr1BvJnL79E2BQVsF9/wcrYSu4P/ yAfTLnHM0jPa7RBKAkHNhsqciGgID+sG0IuMOunSarhA+OJFF/dpg1VoQKCT7UzSbB4+ rQfRG+GihQw1ZjHyZdLMA9OXwTAmC2UtsGn5NQdX8Jdb2wC9Xu2owSDrP8UCAmSKKMBs RiJrYhDl85pg4HXMLY9SkE4D6WCzFOh9SUPAb6v8Ag/tkywgI7sMB9PHxLDkwYRQ5Tda Oo8g== X-Gm-Message-State: APjAAAWAZMAEk9uv+J+AutgDkVLPmdnWyxYKyM2jVGDVhmAyeXXjlId/ 4K7DoXT7K/sQ+23pP9q5nXtXFiGk X-Google-Smtp-Source: APXvYqxgv5XZmSZbaW96b+9jd+mjRaTX+skXxwYcxs+JbJreYRFAGj1+1U8XN+h00Yql9V31ZNoOag== X-Received: by 2002:a05:6830:144e:: with SMTP id w14mr12477125otp.10.1563325937021; Tue, 16 Jul 2019 18:12:17 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1021? ([2600:8802:5903:df16::1021]) by smtp.gmail.com with ESMTPSA id 132sm7731634oid.47.2019.07.16.18.12.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 18:12:16 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Message-Id: <2DB58DB8-460E-473C-9B63-A24CBF5F5B7F@gmail.com> Date: Tue, 16 Jul 2019 18:12:15 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3564) Archived-At: Subject: [v6ops] p2p links draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 01:12:20 -0000 The author is asking for time on the agenda at IETF 105; I told him that = if there was time at the end of the meeting, it could be part of "AOB". = I don't see any discussion on the draft since August 2018. https://tools.ietf.org/html/draft-palet-v6ops-p2p-links = https://mailarchive.ietf.org/arch/search/?qdr=3Da&q=3D%22draft-palet-v6ops= -p2p-links%22 Your comments appreciated. = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war,=20 Defeated warriors go to war first and then seek to win.=20 Sun Tzu From nobody Wed Jul 17 10:56:13 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C592120892 for ; Wed, 17 Jul 2019 10:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 bs1GTWrB8-VM for ; Wed, 17 Jul 2019 10:56:07 -0700 (PDT) Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (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 2ED0D1208AD for ; Wed, 17 Jul 2019 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at tul.cz Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id DA28618062EAD for ; Wed, 17 Jul 2019 19:55:51 +0200 (CEST) From: Martin Hunek To: v6ops@ietf.org Date: Wed, 17 Jul 2019 19:55:46 +0200 Message-ID: <2884253.zEWG6I04fq@rumburak.ite.tul.cz> Organization: Technical University of Liberec In-Reply-To: <3E423587-A00A-4918-966E-C8BEAE0298FD@consulintel.es> References: <291EE30B-D299-4EA1-8C8B-53F4BE6A9B07@gmail.com> <3E423587-A00A-4918-966E-C8BEAE0298FD@consulintel.es> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2238497.n6srve5Der"; micalg="sha256"; protocol="application/pkcs7-signature" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 17:56:12 -0000 --nextPart2238497.n6srve5Der Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Jordi, Thanks for responding with this new version and sorry for added complexity.= :-) This 03 version solves an issue I had been pointing out. I think it made it= potentially more reliable by introducing automated way for detection colli= ding EAMT entries. In my opinion it minimizes possibilities how it could ha= ve caused problems not just to CDN/cache providers - it has been focused on= , but also to other services on the Internet. So I would like to voice my s= upport for this draft in this version. I'm just not entirely sure about that "universal web page" from section 5. = One issue with that was already mentioned by Fred - the DNSSEC incompatibil= ity. I would have one more, that it would be quite easy to filter out respo= nses with this universal page (and also that it would work only for web, by= the way). I can imagine that network operator or service operator, which i= s not doing IPv6 properly, would not like their customers ever to see such = web page. So naturally they would make sure that it would never get display= ed. This "universal web page" is a cool looking concept, but I'm not sure it is= worth the effort. Best Regards, Martin Dne pond=C4=9Bl=C3=AD 8. =C4=8Dervence 2019 23:43:09 CEST, JORDI PALET MART= INEZ napsal(a): > Hi Fred, all, >=20 > =20 >=20 > I just submitted a new version for this document. >=20 > =20 >=20 > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches= /?include_text=3D1 >=20 > =20 >=20 > I=E2=80=99ve updated the issues from your inputs, as well as the issue th= at Martin raised. It has required a much complex approach than the one init= ially drafted when responding to him, but I think it resolves the problem. >=20 > =20 >=20 > Hopefully we can get inputs, specially from CDN/Cache providers, but also= from hosting providers if they are using this reverse-proxy often =E2=80=A6 >=20 > =20 >=20 > Regards, >=20 > Jordi >=20 > @jordipalet >=20 > =20 >=20 > =20 >=20 > =20 >=20 > El 28/6/19 17:10, "v6ops en nombre de JORDI PALET MARTINEZ" escr= ibi=C3=B3: >=20 > =20 >=20 > Hi Fred, >=20 > =20 >=20 > Thanks for your inputs. >=20 > =20 >=20 > Responses, below, in-line. >=20 > =20 >=20 > Regards, >=20 > Jordi >=20 > @jordipalet >=20 > =20 >=20 > =20 >=20 > =20 >=20 > El 28/6/19 15:55, "v6ops en nombre de Fred Baker" escribi=C3=B3: >=20 > =20 >=20 > I=E2=80=99m reading through this draft, and feel some comments are in ord= er on the issues marked =E2=80=9CTBD=E2=80=9D. In this case, I=E2=80=99m wr= iting as an individual. >=20 > =20 >=20 > Sometimes I use the TBD, not necessarily because that need to be complete= d, but to make sure that I double think on that for the next version. >=20 > =20 >=20 > In the general problem and proposed solutions, I agree that the problem s= tatement makes sense (it is comparable to the problem statement in SIIT-DC)= , and section 4.2 (also comparable to SIIT-DC) seems to present the solutio= n with the least impact on the network and its surrounding devices. >=20 > =20 >=20 > A few thoughts: > The information in the EAMT MUST be kept timely-synchronized with the >=20 > AAAA records TTL's. In order to achieve that, each EAMT entry MUST > update with each A query, the TTL of the relevant AAAA record. > Update of RFC7757 ? TBD. >=20 > =20 >=20 > I don=E2=80=99t view this as changing 6145/7915=E2=80=99s algorithm. I ne= ed to understand how this changes 7757 to agree that it updates it. >=20 > =20 >=20 > Section 6 of RFC7915 has a SHOULD for EAM. I think this is right, but I s= ee that RFC6877 (464XLAT), should get it as a MUST. >=20 > =20 >=20 > Similarly, my question about RFC7757, is if it is useful that each entry = in the EAMT also needs to have a TTL, or this is exclusive for our optimiza= tion case (this ID) ? >=20 > =20 >=20 > SIIT already has a SHOULD for EAM support. TBD. 464XLAT may be > updated by this document so the CLAT has a MUST for EAM support. > =20 > THe fact that you want it for this use case doesn=E2=80=99t mean that it = is required by all use cases. I=E2=80=99d want to hear that argument before= agreeing to =E2=80=9CMUST=E2=80=9D. > =20 > I think it makes sense that 464XLAT is *always* optimized, so that=E2=80= =99s why I think it requires to be updated by this document.. > =20 > And in any event, what is the argument for 2119 language in an informatio= nal document? This is beginning to sound more like a Proposed Standard... > =20 > Actually we have got this request already many times when having the IESG= review. I=E2=80=99ve used RFC7084 =E2=80=9Cspecial=E2=80=9D language in th= e recent RFC8585, and I was asked to just use the RFC2119 one. > =20 > However, I also believe that this document, if we agree that 464XLAT must= be always optimized, then this ID is an opportunity for killing two birds = with a stone: > 1) Updating RFC6877 to include the optimization always. > 2) It doesn=E2=80=99t make senses (we talked already some time ago about= this), that MAP-E/T, DS-Lite and lw4o6 are standards, and 464XLAT which is= the mechanism that have =E2=80=9Cmore=E2=80=9D users in the world (even co= mpared to all the others together), is just informational. So this ID may b= e a proposed standard covering both aspects. > =20 > TBD. Should we recommend having A "null" records for IPv6-only > services in Internet? A web page IPv4-only hosted by IETF(?) showing > "sorry this web page/service is only available from IPv6 enabled > operators"? >=20 > =20 >=20 > I=E2=80=99m very concerned about requiring something that is not going to= be DNSSEC-compatible, which=20 >=20 > =20 >=20 > =E2=80=9Cnull=E2=80=9D maybe not the best wording here, so may not break = DNSSEC. I mean using an IPv4 address that is not actually configured in the= server that the has the AAAA. I think it makes sense that this address is = a public one defined by the IETF, which we may use for a special page (or n= ot use at all, but still a special one). >=20 > =20 >=20 > it seems such a =E2=80=9Cnull=E2=80=9D record has to be. I=E2=80=99m also= concerned about something that forces a change to DNS implementations, as = a change to the interpretation of an A resource record seems likely to do. = An A resource record advertises an IPv4 address that one can expect to work= under some set of conditions, and a =E2=80=9Cnull=E2=80=9D record seems to= advertise an address whose set of conditions for=20 >=20 > =20 >=20 > Clearly, I confused using the =E2=80=9Cnull=E2=80=9D wording. Is a real a= ddress (so no change at all in DNS implementations), but this address is no= t actually configured in the interface of the server (because it is IPv6-on= ly). >=20 > =20 >=20 > validity would be null. So this is something I would be concerned to find= , and would expect to require dnsop support for before I was willing to acc= ept it. >=20 >=20 >=20 >=20 > TBD. Other risks to consider ? If a CE is misconfigured, even a > small percentage of broken CEs may bring the content providers to > switch back to IPv4-only. So possible failure cases need to be > carefully considered for every possible solution approach. >=20 > TBD. Should a way to manually exclude EAMT entries be considered? > May be a manual config in the CPE and by means of operator config. > This is way-out to ensure nothing is broken by surprise and is not > solvable. >=20 > =20 >=20 > I=E2=80=99m not an operator. I would expect any operator reading this to = say =E2=80=9Cheavens no, no manual or specific configurations. Make this ju= st fall out of normal operations.=E2=80=9D=20 >=20 > =20 >=20 > I think again is a matter of wording. Many CEs have lots of options that = usually operators don=E2=80=99t use. But if they need to use they can confi= gure them remotely, or because they get from the vendor a default =E2=80=9C= factory=E2=80=9D config. However, in some cases, those configs are also man= aged by =E2=80=9Cexpert=E2=80=9D users (and today a gamer, just an example,= is most of the time an expert user). >=20 > =20 >=20 > Operators, please feel free to agree or disagree, and say why. >=20 >=20 >=20 >=20 > This document does not have any new specific security considerations. >=20 > =20 >=20 > The question about =E2=80=9Cbroken CEs=E2=80=9D seems to point to a secur= ity consideration. In what way might they be misconfigured, and what would = the effect be? >=20 > =20 >=20 > Again, I need to change the wording here. The CE is not actually broken. = The complete paragraph =E2=80=9CTBD. Other risks to consider ? =E2=80=A6= =E2=80=9D was more a way to remind muself to work on that. The point is tha= t if we have this optimization, we need to make sure to double-check with C= DNs that it doesn=E2=80=99t create a trouble for them, because in those cas= es they see the =E2=80=9CCE as broken for IPv6=E2=80=9D and they prefer to = disable IPv6 for the entire ISP that has the =E2=80=9Cbroken CEs=E2=80=9D. >=20 > =20 >=20 > Is that clearer now? >=20 > =20 >=20 > I will definitively improve the wording for the next version, so those po= ints don=E2=80=99t create confusion. >=20 > =20 >=20 > =20 >=20 > _______________________________________________ v6ops mailing list v6ops@= ietf.org https://www.ietf.org/mailman/listinfo/v6ops=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 c= onfidential. 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 co= nsidered 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 prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. >=20 > _______________________________________________ v6ops mailing list v6ops@= ietf.org https://www.ietf.org/mailman/listinfo/v6ops=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 c= onfidential. 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 co= nsidered 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 prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. >=20 --nextPart2238497.n6srve5Der Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCpYw ggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgxMjAwMDBaFw0yNDEx MTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBl cnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwp9Jj5Aej1xPkS1GV 3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYtyqDGF2nnItxV1SkwVoDxFeRzOIHYNYvBR HaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VW Ff/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyimatBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0ba minfLcsh6ubCdINZc+Nof2lU387NCDggoh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAM C57iZXssncp24eaN08VlAgMBAAGjggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNz dXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQu Y29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkFOxA/TUiu K2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBSWxITl1KHBS9Y BskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsBiWU2muAoGItwbaP5 5EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101S1OI6J1tUil1r7ES/svN qVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9EowggWFMIIEbaADAgECAhAMQfNc 2yZ76uFuFsYvU6DuMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29y ZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwHhcNMTgxMjMwMDAwMDAwWhcNMjAwMTI5MTIw MDAwWjCBqjETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBnRlcmVuYTETMBEG CgmSJomT8ixkARkWA3RjczELMAkGA1UEBhMCQ1oxKDAmBgNVBAoTH1RlY2huaWNhbCBVbml2ZXJz aXR5IG9mIExpYmVyZWMxLzAtBgNVBAMMJk1hcnRpbiAgSHVuZWsgbWFydGluLmh1bmVrQHR1bC5j ei0xMTMwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtyGGFckzuJwXJj4YNL1+QmNZ 7XSQMTY0RWWGL2gNQsCIqiBN+eoZkPYUEIhtfJfNmh/kFpLQAGKHRnlx/+aGcOMXMGrg71noNKr4 5p2iBtmeIwoQPvBKgNXREstHVm2qcQjzNUbfC5CLTesbZILWMZI9bAHrFeubdq7urlgk5MlF+uCr h+D4F7GRfYDEkY9PXr6Dcb15RFlFBN3zJCqyfFfyxlhUjGj6biMP8fhSMWWnpHoD7OdKPiWQ0NNZ IAe0zeVxmOFo5t2+iXfhM+WfbFT0PeQAAvA5yoBAzge/hWp3CM2HnJB8vB+d93tftpj2DhCDfKlD SQFMu/v5qfVAHQIDAQABo4IB3DCCAdgwHwYDVR0jBBgwFoAUjJ8RLubjegSlHlWLRggEpu2XcKYw HQYDVR0OBBYEFBsqD39E4UgZxyftxDYlCqGCyOALMAwGA1UdEwEB/wQCMAAwHgYDVR0RBBcwFYET bWFydGluLmh1bmVrQHR1bC5jejAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMDQGA1UdIAQtMCswDAYKKoZIhvdMBQICATAMBgpghkgBhv1sBB8BMA0GCyqGSIb3 TAUCAwMDMIGFBgNVHR8EfjB8MDygOqA4hjZodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5B ZVNjaWVuY2VQZXJzb25hbENBMy5jcmwwPKA6oDiGNmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9U RVJFTkFlU2NpZW5jZVBlcnNvbmFsQ0EzLmNybDB7BggrBgEFBQcBAQRvMG0wJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUAA4IB AQBZZ5rT9Ac11lX7SSXXmKrrDr2KMzPCw6S7MW1z36sNaqvi++KBwio9HdxEgN02SJsf5R2Up3xf cyhkNFr6QR5Klca/dY1xO+c9qQHsYDX5Hi3N59xMyVw0bz9u0tOYj/D/qEncm7qrdmdolSV55Nm4 Vr3ZzGl+qBFnskbwpmDgiiyAOfSL8gK++HPxWVKY/Mvv0MSaoVbyiBh0oiFRxX5fwuBJxaSh7bhC dlQ8SXoAhDNwQnSMKYroOn7ZWKlhT41L6IaMfJ2xSBGHtB+1OmehwLWU9FBzw0GAG34ZsshdJiTS fTuUk/hQAM9vNXzkd3ubPFh+H/DgH0GdPsXg/09oMYICSDCCAkQCAQEwgYYwcjELMAkGA1UEBhMC TkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMG VEVSRU5BMSYwJAYDVQQDEx1URVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0EgMwIQDEHzXNsme+rh bhbGL1Og7jANBglghkgBZQMEAgEFAKCBkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xOTA3MTcxNzU1NDZaMCgGCSqGSIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCD+rVV9RsUcy/4IUcY6yfZZCaHO3nmB8Ht7jNRK06tk FjANBgkqhkiG9w0BAQEFAASCAQBhDNyJxL6CIBkDucAQyoTk3Fw2raG7KNk6+4bUVdkp/x0hTBW1 PggvBQCjgqyXyUyDuQnt8slNzhtFPfGpKkxUHLEr+OGkq0Amz/HdzcwZH4FwlHDRq/Io95/IQEp+ wgj9sKxobovJdJZfOvPsCYGhxvzdk/2mIYUSWejl5pnjuFY3muxe9Obn2qJVSlEzllX9yPoKco/X 9LNf6cb4EQm67ghqO1l+9X3Dfc3WasjlMmdJJRoKkL3frLAaDFlnuP9sLeNBbrXsc/5re4VTO96c lEzMePlNyyC+KL1RtVfAeorh2nJF/FIo4juY6/9mcTC3EOkSvD5BzE5hohoPiJ1oAAAAAAAA --nextPart2238497.n6srve5Der-- From nobody Wed Jul 17 11:10:18 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427CD120877 for ; Wed, 17 Jul 2019 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 qrFAk0JHkdbt for ; Wed, 17 Jul 2019 11:10:13 -0700 (PDT) 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 DC44A120851 for ; Wed, 17 Jul 2019 11:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1563386989; x=1563991789; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=I17wlkc7 RFxlH4DY/D1hVYb09Vmmox1YATfaFVYu06c=; b=fEW0EctumLaQ/24MH/xaaQga Qv9oxzaIx19lGDuveYvxvMJSjHE2g40m63OKQtDkrGkdfXBHDkxZ1PLEuEwwEkLU DGSgZ3X9kdHhIKCOrCU8yUuRmQvjwFiiZ5Fzk9z7RhcmLDjsEvynlHA/CpH4l8Jh tGujHDT7r8Hrpczsq40= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 17 Jul 2019 20:09:49 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 17 Jul 2019 20:09:47 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006328107.msg for ; Wed, 17 Jul 2019 20:09:47 +0200 X-MDRemoteIP: 2001:470:1f09:495:b913:c91d:a17c:bad X-MDHelo: [10.10.10.144] X-MDArrival-Date: Wed, 17 Jul 2019 20:09:47 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=11016b6032=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.c.190715 Date: Wed, 17 Jul 2019 20:09:42 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <030318F4-D7E7-4220-9D26-3D6F3AACDACE@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches References: <291EE30B-D299-4EA1-8C8B-53F4BE6A9B07@gmail.com> <3E423587-A00A-4918-966E-C8BEAE0298FD@consulintel.es> <2884253.zEWG6I04fq@rumburak.ite.tul.cz> In-Reply-To: <2884253.zEWG6I04fq@rumburak.ite.tul.cz> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 18:10:16 -0000 Hi Martin, Thanks a lot for your inputs. Actually, I've been thinking (unfortunately too late to submit a new versio= n before the cut-off) to delete the text about the "universal" web page, be= cause that will create exactly the same problem that we just have resolved = ! So, don't worry about that anymore. We can have that web page if the "servi= ce" provider decides to have it, but it will not use any "special" IPv4 add= ress, just a regular address from their pool. I will try to post the changes once after the submission system becomes ava= ilable again, but even if I don't do that on time for the v6ops meeting, I = will make sure to explain that that text must go. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 17/7/19 19:56, "v6ops en nombre de Martin Hunek" escribi=C3=B3: Hi Jordi, =20 Thanks for responding with this new version and sorry for added complex= ity. :-) =20 This 03 version solves an issue I had been pointing out. I think it mad= e it potentially more reliable by introducing automated way for detection c= olliding EAMT entries. In my opinion it minimizes possibilities how it coul= d have caused problems not just to CDN/cache providers - it has been focuse= d on, but also to other services on the Internet. So I would like to voice = my support for this draft in this version. =20 I'm just not entirely sure about that "universal web page" from section= 5. One issue with that was already mentioned by Fred - the DNSSEC incompat= ibility. I would have one more, that it would be quite easy to filter out r= esponses with this universal page (and also that it would work only for web= , by the way). I can imagine that network operator or service operator, whi= ch is not doing IPv6 properly, would not like their customers ever to see s= uch web page. So naturally they would make sure that it would never get dis= played. =20 This "universal web page" is a cool looking concept, but I'm not sure i= t is worth the effort. =20 Best Regards, Martin =20 Dne pond=C4=9Bl=C3=AD 8. =C4=8Dervence 2019 23:43:09 CEST, JORDI PALET = MARTINEZ napsal(a): > Hi Fred, all, >=20 > =20 >=20 > I just submitted a new version for this document. >=20 > =20 >=20 > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-ca= ches/?include_text=3D1 >=20 > =20 >=20 > I=E2=80=99ve updated the issues from your inputs, as well as the issu= e that Martin raised. It has required a much complex approach than the one = initially drafted when responding to him, but I think it resolves the probl= em. >=20 > =20 >=20 > Hopefully we can get inputs, specially from CDN/Cache providers, but = also from hosting providers if they are using this reverse-proxy often =E2= =80=A6 >=20 > =20 >=20 > Regards, >=20 > Jordi >=20 > @jordipalet >=20 > =20 >=20 > =20 >=20 > =20 >=20 > El 28/6/19 17:10, "v6ops en nombre de JORDI PALET MARTINEZ" = escribi=C3=B3: >=20 > =20 >=20 > Hi Fred, >=20 > =20 >=20 > Thanks for your inputs. >=20 > =20 >=20 > Responses, below, in-line. >=20 > =20 >=20 > Regards, >=20 > Jordi >=20 > @jordipalet >=20 > =20 >=20 > =20 >=20 > =20 >=20 > El 28/6/19 15:55, "v6ops en nombre de Fred Baker" escribi=C3=B3: >=20 > =20 >=20 > I=E2=80=99m reading through this draft, and feel some comments are in= order on the issues marked =E2=80=9CTBD=E2=80=9D. In this case, I=E2=80=99= m writing as an individual. >=20 > =20 >=20 > Sometimes I use the TBD, not necessarily because that need to be comp= leted, but to make sure that I double think on that for the next version. >=20 > =20 >=20 > In the general problem and proposed solutions, I agree that the probl= em statement makes sense (it is comparable to the problem statement in SIIT= -DC), and section 4.2 (also comparable to SIIT-DC) seems to present the sol= ution with the least impact on the network and its surrounding devices. >=20 > =20 >=20 > A few thoughts: > The information in the EAMT MUST be kept timely-synchronized with t= he >=20 > AAAA records TTL's. In order to achieve that, each EAMT entry MUST > update with each A query, the TTL of the relevant AAAA record. > Update of RFC7757 ? TBD. >=20 > =20 >=20 > I don=E2=80=99t view this as changing 6145/7915=E2=80=99s algorithm. = I need to understand how this changes 7757 to agree that it updates it. >=20 > =20 >=20 > Section 6 of RFC7915 has a SHOULD for EAM. I think this is right, but= I see that RFC6877 (464XLAT), should get it as a MUST. >=20 > =20 >=20 > Similarly, my question about RFC7757, is if it is useful that each en= try in the EAMT also needs to have a TTL, or this is exclusive for our opti= mization case (this ID) ? >=20 > =20 >=20 > SIIT already has a SHOULD for EAM support. TBD. 464XLAT may be > updated by this document so the CLAT has a MUST for EAM support. > =20 > THe fact that you want it for this use case doesn=E2=80=99t mean that= it is required by all use cases. I=E2=80=99d want to hear that argument be= fore agreeing to =E2=80=9CMUST=E2=80=9D. > =20 > I think it makes sense that 464XLAT is *always* optimized, so that=E2= =80=99s why I think it requires to be updated by this document.. > =20 > And in any event, what is the argument for 2119 language in an inform= ational document? This is beginning to sound more like a Proposed Standard.= .. > =20 > Actually we have got this request already many times when having the = IESG review. I=E2=80=99ve used RFC7084 =E2=80=9Cspecial=E2=80=9D language i= n the recent RFC8585, and I was asked to just use the RFC2119 one. > =20 > However, I also believe that this document, if we agree that 464XLAT = must be always optimized, then this ID is an opportunity for killing two bi= rds with a stone: > 1) Updating RFC6877 to include the optimization always. > 2) It doesn=E2=80=99t make senses (we talked already some time ago a= bout this), that MAP-E/T, DS-Lite and lw4o6 are standards, and 464XLAT whic= h is the mechanism that have =E2=80=9Cmore=E2=80=9D users in the world (eve= n compared to all the others together), is just informational. So this ID m= ay be a proposed standard covering both aspects. > =20 > TBD. Should we recommend having A "null" records for IPv6-only > services in Internet? A web page IPv4-only hosted by IETF(?) showi= ng > "sorry this web page/service is only available from IPv6 enabled > operators"? >=20 > =20 >=20 > I=E2=80=99m very concerned about requiring something that is not goin= g to be DNSSEC-compatible, which=20 >=20 > =20 >=20 > =E2=80=9Cnull=E2=80=9D maybe not the best wording here, so may not br= eak DNSSEC. I mean using an IPv4 address that is not actually configured in= the server that the has the AAAA. I think it makes sense that this address= is a public one defined by the IETF, which we may use for a special page (= or not use at all, but still a special one). >=20 > =20 >=20 > it seems such a =E2=80=9Cnull=E2=80=9D record has to be. I=E2=80=99m = also concerned about something that forces a change to DNS implementations,= as a change to the interpretation of an A resource record seems likely to = do. An A resource record advertises an IPv4 address that one can expect to = work under some set of conditions, and a =E2=80=9Cnull=E2=80=9D record seem= s to advertise an address whose set of conditions for=20 >=20 > =20 >=20 > Clearly, I confused using the =E2=80=9Cnull=E2=80=9D wording. Is a re= al address (so no change at all in DNS implementations), but this address i= s not actually configured in the interface of the server (because it is IPv= 6-only). >=20 > =20 >=20 > validity would be null. So this is something I would be concerned to = find, and would expect to require dnsop support for before I was willing to= accept it. >=20 >=20 >=20 >=20 > TBD. Other risks to consider ? If a CE is misconfigured, even a > small percentage of broken CEs may bring the content providers to > switch back to IPv4-only. So possible failure cases need to be > carefully considered for every possible solution approach. >=20 > TBD. Should a way to manually exclude EAMT entries be considered? > May be a manual config in the CPE and by means of operator config. > This is way-out to ensure nothing is broken by surprise and is not > solvable. >=20 > =20 >=20 > I=E2=80=99m not an operator. I would expect any operator reading this= to say =E2=80=9Cheavens no, no manual or specific configurations. Make thi= s just fall out of normal operations.=E2=80=9D=20 >=20 > =20 >=20 > I think again is a matter of wording. Many CEs have lots of options t= hat usually operators don=E2=80=99t use. But if they need to use they can c= onfigure them remotely, or because they get from the vendor a default =E2= =80=9Cfactory=E2=80=9D config. However, in some cases, those configs are al= so managed by =E2=80=9Cexpert=E2=80=9D users (and today a gamer, just an ex= ample, is most of the time an expert user). >=20 > =20 >=20 > Operators, please feel free to agree or disagree, and say why. >=20 >=20 >=20 >=20 > This document does not have any new specific security consideration= s. >=20 > =20 >=20 > The question about =E2=80=9Cbroken CEs=E2=80=9D seems to point to a s= ecurity consideration. In what way might they be misconfigured, and what wo= uld the effect be? >=20 > =20 >=20 > Again, I need to change the wording here. The CE is not actually brok= en. The complete paragraph =E2=80=9CTBD. Other risks to consider ? =E2=80= =A6=E2=80=9D was more a way to remind muself to work on that. The point is = that if we have this optimization, we need to make sure to double-check wit= h CDNs that it doesn=E2=80=99t create a trouble for them, because in those = cases they see the =E2=80=9CCE as broken for IPv6=E2=80=9D and they prefer = to disable IPv6 for the entire ISP that has the =E2=80=9Cbroken CEs=E2=80= =9D. >=20 > =20 >=20 > Is that clearer now? >=20 > =20 >=20 > I will definitively improve the wording for the next version, so thos= e points don=E2=80=99t create confusion. >=20 > =20 >=20 > =20 >=20 > _______________________________________________ v6ops mailing list v6= ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops=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 confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 > _______________________________________________ v6ops mailing list v6= ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops=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 confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Wed Jul 17 12:35:18 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B3F120155 for ; Wed, 17 Jul 2019 12:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 CwTC-Sc2u0Dy for ; Wed, 17 Jul 2019 12:35:15 -0700 (PDT) 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 5A703120170 for ; Wed, 17 Jul 2019 12:35:15 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id i8so11625477pgm.13 for ; Wed, 17 Jul 2019 12:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=yNgLCHjs7vfZbfklScu/Wn2q59dOqaBha8iLiI5IOP8=; b=A18Gq9LK5MLES/Xa+Fxr+7XLNhTqaBhu1ofNWydMSRhprwLzYdu6k8B73FbFiOE6KC rCFBvbwxFfZ9Wx4ReqhW0gD28a2hcZ7ZMbm5BWdEEUCu4gM+senaRiqf0z4v7gxojgio q5/p07AWWfVUcxKUw+ksBMJ30j0paCEi27+V8ZHH1C1+pkQKoSIXjKzx/2AKfVr7W7w0 0HygBDh53if4pGZCEovvLILLcb73yWpFBOEOFSkOzFO0johfUe+TxOqzcTO9WCnYYo29 3SKbQ1/7FcKwC75b5ZS5pGOfo8L0Ooc5I9K8VZK20jGW+Nc2CakJ3yuqUEWvFNJ5sE9q uiPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=yNgLCHjs7vfZbfklScu/Wn2q59dOqaBha8iLiI5IOP8=; b=JZnYqB3X/x4Ife0em1lMth9ghUem9gufeoWcAHiIwfs0vwRmK9AmulRvIXwDjshP3/ ybCexwF28BKFQXRPJXJdKpT64aMXVzzta8EJyzDVx1LpZ4pl7WVnIfu41OxRJC1egLPz 2H3DNBt3MCYArDDK8kiF021YLqTJSyVEAt8+BKhjHPcbzaSkCGGeKLjH8jS5TJEy4QMv yclaS+/PZyR1mjj1QZE9M4xSV2vaSqTlw0xaiqAyIPsSJxMkdWo/9pvAP7LspD/EmsN+ G0UnjKELWYl9Fbg5LuFtpd67gxkXQlBj2sgKto+KhZJBOgms6UfNckWhFZRjZKV9UWQS LjeQ== X-Gm-Message-State: APjAAAWjcLekqkim/WgC0JUHWbbjFBQ9POQ3lO2b2y61AvElNAKM4bi0 SYdBFXigRCch25nBoXgEgOxvw0Nk X-Google-Smtp-Source: APXvYqy33u02GXiqVNpde/Vyq4T8y8+FWXunFCLAjYv6Q10IXZlOgfe23aKaRyqoTiqaMINrGcWa/Q== X-Received: by 2002:a65:4509:: with SMTP id n9mr27521245pgq.133.1563392114658; Wed, 17 Jul 2019 12:35:14 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1021? ([2600:8802:5903:df16::1021]) by smtp.gmail.com with ESMTPSA id b126sm37965133pfa.126.2019.07.17.12.35.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2019 12:35:14 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\)) Message-Id: Date: Wed, 17 Jul 2019 12:35:12 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3566.0.1) Archived-At: Subject: [v6ops] V6ops agenda at IETF 105 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 19:35:17 -0000 IPv6 Operations will meet at 15:50-17:50 Monday 22 July. The current = agenda is at https://datatracker.ietf.org/meeting/105/materials/agenda-105-v6ops-03 We have had three requests for agenda time that didn't meet the usual = requirement of supporting commentary on the list prior to the meeting. = If there is remaining time at the end, the chairs will, at their = discretion, let those authors speak for ten minutes. If there isn't = time, there isn't time. We recommend, as usual, that the authors seek = support on the list. From nobody Thu Jul 18 12:57:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29FD12040B for ; Thu, 18 Jul 2019 12:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 F4PVuqVPkidX for ; Thu, 18 Jul 2019 12:57:28 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 EC769120112 for ; Thu, 18 Jul 2019 12:57:27 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id s4so11632338uad.7 for ; Thu, 18 Jul 2019 12:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=auJWTBPidbaNxk43xCBkLa+8Kg0rRKti0o6V7Sj2Q2Y=; b=rdMogh15zS95zROSo6CeKFLZ6BM/VXMfxJusInewTrK86CbMUlNAmwn0DQVG5W+ZKY lCgmgzUHUD8gR9Xq0DvzSw24avutjRku/fP9Elp8R+n36D7iOaWmbvYk+cm2RVJlM722 Z/fvW5FKqCRznvC/kui/Z8SqOQdT0zT+Bqh/zF6ubbzp6ozeTElhV5A0zOR0n8pjpUR5 YJ9ZGKv7g1TCgK+ers3ajuyodXiPYIn4Jq/8s3ARz00LS72O7MiJ/j2lmloyKresY1i0 fky1/ufd9Iuw1kP8o5tcs5iqvu8ESqpPib4WtuymrNOm+ioNc3knkBwhR54cDHRPcxk6 Of1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=auJWTBPidbaNxk43xCBkLa+8Kg0rRKti0o6V7Sj2Q2Y=; b=rYQjCu2KHznjmdm0g03OgzeHB+uC833OHcM5nHPdionZJ9efpK2ipoqxe5zqjY9izx BExsL7YsvbNXSu9AnwMTj4swqTj9vneBSR2tiN8CElZWuJkBiz4np50YgkWtWVdYncnT GcgB8cdVLd4H8pxQWBJlmEwhG4dNfNsx8hE0ii5Tz86kDGyQSH01mskCiQbFvhkvLBrd Dw/IHX30Hj7Utg3dL67ShYmqzc40FEDqSP+yfUdHJrpWmHDw8XVRkGKkFkG2yarpWrcn UIaoacir7+RY0jSFvuOPi+l1J6lDK7QWbm655UyoyWzt7axBEFJ4+GmEVIAy7S19GmXJ kNCw== X-Gm-Message-State: APjAAAVWPYr2sB6bVbpuqLix7znMQkA2vTN1JcaQsmEQ9gyExbjO4yWi nszad1u/CHvkxoBa4m513jpZrASh X-Google-Smtp-Source: APXvYqzqVEJF/TNyLJItuzf+HbNpQbcwoLIrm7mW7KKzzHcoD+QKSY7Dp5wYMdBG7tgFVu6c4pm9BQ== X-Received: by 2002:a9f:3f4d:: with SMTP id i13mr28915616uaj.54.1563479846505; Thu, 18 Jul 2019 12:57:26 -0700 (PDT) Received: from [192.168.43.57] ([186.167.242.165]) by smtp.gmail.com with ESMTPSA id 10sm10305592vkl.33.2019.07.18.12.57.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 12:57:25 -0700 (PDT) To: IPv6 Operations From: Alejandro Acosta Message-ID: Date: Thu, 18 Jul 2019 15:57:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------67E1BB5B42201E01379CD615" Content-Language: en-US Archived-At: Subject: [v6ops] Very basic question: What is IPv6 native? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 19:57:30 -0000 This is a multi-part message in MIME format. --------------67E1BB5B42201E01379CD615 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello there, =C2=A0 Sorry if this is not the place to ask this. =C2=A0 I was looking for the concept of "Native IPv6" with no luck. =C2=A0 I performed a search in google restricting the results inside ietf.org. However even when a lot of results with the string "IPv6 Native" the concept/description/meaning of what IPv6 native is did not show up. Among the results I found: https://tools.ietf.org/html/rfc6751 (Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment) https://tools.ietf.org/id/draft-v6ops-rfc7084-bis-00.html (Basic Requirements for IPv6 Customer Edge Routers) https://tools.ietf.org/id/draft-lopez-v6ops-dc-ipv6-05.html (IPv6 Operational Guidelines for Datacenters) https://tools.ietf.org/html/rfc7381 () =C2=A0 And I found this old thread which refer to this very same topic: =C2=A0 https://mailarchive.ietf.org/arch/msg/ietf/KkkOMeinS-l9i_SaViVXHuR= w20A =C2=A0 Is there any document that I might be missing that officially describes the concept/meaning of "Native IPv6"? Thanks a lot, Alejandro, --------------67E1BB5B42201E01379CD615 Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFztkSoBCADJ6Eeff/C7+EifPImW8l/Ic7fslh/AtblJQeuoNCt681imYQN8 Jnvy3euOFGPBllOJDy7Vugc6LEePpOadHTG+m+6BYpBxTs6eqf7qH/TBtESpjMVT 8uf0MElbMJrby+0zF/fhRx5OEcEEiETByNskJhE0fviSwAikXvdzLrWrR6NjTaNG ioZn2h9QXcx0cXCxoBrA/lTxEPs1Ncy3sky08E7KW7jmPSt4VesrQZ/JqcNXyGnt NUi97Aa9TCUtO8PIe3PfzVN0MQeF6xql7XQJGQgocf0X/rYsWD/STX0wA7zVqbdn kAIyicYx/Z8p6QoeiPcwWA5PbomTL0cz0uetABEBAAG0MUFsZWphbmRybyBBY29z dGEgPGFsZWphbmRyb2Fjb3N0YWFsYW1vQGdtYWlsLmNvbT6JAVQEEwEIAD4CGwMF CwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQR9NGXbSCvzsdzzAGBBGAwR8z/TYQUC XPjj+gUJDTO7UAAKCRBBGAwR8z/TYcx1B/kB8VIHe0m7LbpiLAiNcpwdHmn6IrTm IlYUcHPnR/Q6XXN9KQWl/BwQTH01f2FGowrHtZnPT5yh29xcZGuZJO/s/mZmTXAR XZYvX0qPM2UNWg1inPNKea/n1+JopHwQYZPuXywF5hAqHk5BwPdkVzsKxFkvuHFQ +BbG3/dyTCFtfnaRXCDJ5dusEP9c5004/5yRx2O+QQArANmBP4nKPi8xUaejPMdf oEh1ku0EbG3WTzKF3CZR0QiCCeUwTzdrAMDmFpjSg4a50r1TY1fqQvcYPA3CMe4H tJuxToHkk+NGqhAHiABBIJmtqqRm+547HLsfTXFVEi8+JlcUFl9LboR9uQENBFzt kSoBCADFTEbxbHfnmhOMJhAsYjBoEDarMEXC3374KVeEAegF2bBYbnJzz+5/HeVy lZsSJloEtpPwceCOa33x50Qa3VxsOCL5IkBjYHwePQb7Lz8cOfTGug03teH2XZ2g mcr+3s6Mbr5rAPgWMUOIuNtGiDOJpu/xeKUGFn1vslWZAwcDDrDUeEF2j5u5006K nHvwyACXHLUAy0NXbKYexvZPshCCTqavZlAmqRNxBqS6xTm9lmLyKvHzDPOcDLs5 rOYLOg9NoBOXhQib0nHrnY6vnXlQDUlUzYfXiFUoFAsZvwifMhTkVMzaVTcux9xn U+rUx7td+eE0Q2MBgZbGMLam/8jvABEBAAGJATwEGAEIACYCGwwWIQR9NGXbSCvz sdzzAGBBGAwR8z/TYQUCXPjj+gUJDTO7UAAKCRBBGAwR8z/TYdd6B/9wznTFjfQa lkfrHl62M6k3ad4vWJmi2Zx3xOs8MtX89XGhTLBtSGSjxi9Mo6U/Dq86iPeIJaIw EWnT+aw4Mq18bSeMeVilaUrNbhiYqve8a2FAtUXBT/ovwvFY6BrZFrKaeK0k0vqL b9TEr/LNqotLOgQV5BktwM7TQ8Dap1onOkVil2uDnvKR0LBRTf6yddxJXLYJUPXE zJxUCPXodvHWggqrnG7xWHXk4UNWIgNQjSXpI9lXooH/VhRmO2bCpaIba6eRoohG 2c/SDKWXD4qENMpWsLfRtPUZcX7vgF7afIuTvm8F95BfIsOMLMA1K39+s1x2oB9m IlyxqGNfdzAV =3D++GG -----END PGP PUBLIC KEY BLOCK----- --------------67E1BB5B42201E01379CD615-- From nobody Thu Jul 18 13:00:18 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F51206DF for ; Thu, 18 Jul 2019 13:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 FSAFecSEPYVk for ; Thu, 18 Jul 2019 13:00:14 -0700 (PDT) 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 CD644120112 for ; Thu, 18 Jul 2019 13:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1563480009; x=1564084809; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=gWV2LRM9 P8bBPExg+fSy7kdg0hl52cvf/EbpaGWZrGQ=; b=Mc6JKN7NbCKCvsobLIRDuKcS IZsNkXksleLlGTQK0i9fAEcYuCVsmHl8y60RYKw6aR+n9Vr4gISNTlVucrdxxWKl MAE7/6p6p9PZJrq8enLYY6VjqzC6w2q9lyYcP88fau4BsbWBJyoy1SEpIuMZii+l q0rg6oO0pVBUTlKw+x8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Jul 2019 22:00:09 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Jul 2019 22:00:09 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006329229.msg for ; Thu, 18 Jul 2019 22:00:07 +0200 X-MDRemoteIP: 2001:470:1f09:495:d8c7:e32f:f70c:343c X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 18 Jul 2019 22:00:07 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1102b15fa9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.c.190715 Date: Thu, 18 Jul 2019 22:00:07 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] Very basic question: What is IPv6 native? References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Very basic question: What is IPv6 native? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 20:00:17 -0000 Hi Alejandro, May be something for adding some more text into: https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ Let me know if the existing text is sufficient, or what do you suggest to a= dd. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 18/7/19 21:57, "v6ops en nombre de Alejandro Acosta" escribi=C3=B3: Hello there, =20 Sorry if this is not the place to ask this. =20 I was looking for the concept of "Native IPv6" with no luck. =20 I performed a search in google restricting the results inside ietf.org. However even when a lot of results with the string "IPv6 Native" the concept/description/meaning of what IPv6 native is did not show up. Among the results I found: =20 https://tools.ietf.org/html/rfc6751 (Native IPv6 behind IPv4-to-IPv4 NA= T Customer Premises Equipment) =20 https://tools.ietf.org/id/draft-v6ops-rfc7084-bis-00.html (Basic Requirements for IPv6 Customer Edge Routers) =20 https://tools.ietf.org/id/draft-lopez-v6ops-dc-ipv6-05.html (IPv6 Operational Guidelines for Datacenters) =20 https://tools.ietf.org/html/rfc7381 () =20 And I found this old thread which refer to this very same topic: =20 https://mailarchive.ietf.org/arch/msg/ietf/KkkOMeinS-l9i_SaViVXHuRw20= A =20 =20 Is there any document that I might be missing that officially describes the concept/meaning of "Native IPv6"? =20 =20 Thanks a lot, =20 =20 Alejandro, =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Thu Jul 18 13:57:43 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD1C1200EF for ; Thu, 18 Jul 2019 13:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 vzITsdJawkF1 for ; Thu, 18 Jul 2019 13:57:39 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 C2DEE1200CD for ; Thu, 18 Jul 2019 13:57:39 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id z23so2205213ote.13 for ; Thu, 18 Jul 2019 13:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RLyt3xWZxWotp8FZxsk73kKfjSnNblhcZ4tUfC8w/Jc=; b=oOmerLmavx5MpbShkwtMRLDo+/GRey7xaja7uv+LQ3cWubCKF7t6jC1pZMBZxMn/Pf jPO+DBcqrVwgYFVRVleNSGWmp7V3BYOLL1CuAyDRP4UBzqKEKjL9PLPaWrNgP00N2fKh 9taQ0aEmbcuzMZjm8gDgNcsGY1MpyTUQl6sRc05oAMxRExg1yxC5/kfN37ov/zwUzCgb rjjOmLgf1p7ZO/FOeRdk/7TBPIrpngA/683tymvwhsAGblqQXtXLhRKj7YN+D9P0IgYJ i3+dWAQBH82D67YfmvUelV590SVZxa7mgktnPV70/Panz8rVOzF/nL+HkaMGcLoOZN4/ r3Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RLyt3xWZxWotp8FZxsk73kKfjSnNblhcZ4tUfC8w/Jc=; b=PAbefzCe7jrpOf7LxxXj9g8kLyd7SAdkZ4a91XMBzO8Tqa4IWyu3d0nUkd4hcA8qSp LI0RIF4LgmlVaw6btYNfgXQevtmWRgKFAlkZL4V2WGHwJIlIXL49u6SZCPiNPk/l7PjA 7raMiCEpkMphaipXoYLF+oHVumEt87cjHKU5B5TCGH2OrlVJVgE5thcrFROIEG+i0CER K0Fy/7aXLdm5MPpKLfg8tcna2ORMQ8RvCqUOEkXKBR080l9fa/tNzWRrbl8J/WJw3Y26 SFhsBsWsMGz9GxpXRRRZxw53OKknsPb/dtAQsMvT4bR0MZmML2F4XclXKCjR1zc3nBY4 RzrA== X-Gm-Message-State: APjAAAU0Dfyx+LHZTMzDK35lJHg9TBJBF6tATzgQhnKdQr0KgAT/Q+YO 3XNB8SM+h6WAfqfrZk8lWE4= X-Google-Smtp-Source: APXvYqzp78NyCS5BIqhrghbrLfOAwXBKImeQpWA8R7W2eX+1N6j+YePYn5jNHqoHpEMqIrz7UocaQQ== X-Received: by 2002:a9d:6f0e:: with SMTP id n14mr15138478otq.38.1563483458992; Thu, 18 Jul 2019 13:57:38 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1021? ([2600:8802:5903:df16::1021]) by smtp.gmail.com with ESMTPSA id 109sm10782340oty.81.2019.07.18.13.57.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 13:57:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\)) From: Fred Baker In-Reply-To: Date: Thu, 18 Jul 2019 13:57:37 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <7128A662-2E15-42E7-B245-6D77376E403A@gmail.com> References: To: Alejandro Acosta X-Mailer: Apple Mail (2.3566.0.1) Archived-At: Subject: Re: [v6ops] Very basic question: What is IPv6 native? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 20:57:42 -0000 > On Jul 18, 2019, at 12:57 PM, Alejandro Acosta = wrote: >=20 > Hello there, >=20 > Sorry if this is not the place to ask this. >=20 > I was looking for the concept of "Native IPv6" with no luck. I might define it as parallel to "native IPv4" or "native Ethernet". If = it depends on things using the proposal defined in RFC 8200, and the = associated RFCs around it, it uses IPv6. If it *also* requires something = using RFC 791 (such as "IPv6 may in some contexts have to be tunneled = though IPv4 in some way"), that's IPv6 plus something else, and it = therefore not "native". > I performed a search in google restricting the results inside > ietf.org. However even when a lot of results with the string "IPv6 > Native" the concept/description/meaning of what IPv6 native is did not > show up. Among the results I found: >=20 > https://tools.ietf.org/html/rfc6751 (Native IPv6 behind IPv4-to-IPv4 = NAT > Customer Premises Equipment) >=20 > https://tools.ietf.org/id/draft-v6ops-rfc7084-bis-00.html (Basic > Requirements for IPv6 Customer Edge Routers) >=20 > https://tools.ietf.org/id/draft-lopez-v6ops-dc-ipv6-05.html (IPv6 > Operational Guidelines for Datacenters) >=20 > https://tools.ietf.org/html/rfc7381 () >=20 > And I found this old thread which refer to this very same topic: >=20 > = https://mailarchive.ietf.org/arch/msg/ietf/KkkOMeinS-l9i_SaViVXHuRw20A >=20 >=20 > Is there any document that I might be missing that officially > describes the concept/meaning of "Native IPv6"? >=20 >=20 > Thanks a lot, >=20 >=20 > Alejandro, >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... From nobody Thu Jul 18 14:51:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E164E120114 for ; Thu, 18 Jul 2019 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 36EhCXmp2lpZ for ; Thu, 18 Jul 2019 14:51:11 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 18C101200FD for ; Thu, 18 Jul 2019 14:51:11 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id m23so20223122vso.1 for ; Thu, 18 Jul 2019 14:51:10 -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; bh=GL872Cjt9wuJB4I405QO8aWmpz1TrSQZZghYbOSUuQs=; b=pjWTt5SHgq1YlNIN03jjcV5kP6c1nZftXnjpH5QaDK0DZVWVrm7NSysOnDxorXe1bd OvXzADBQLpuBvrJyuzqmLPQf+o0QK88BhH4zweJLWSaRSbcZ3ZHDrkZPyVf20E0MUsqF nfkLXHcUtV5ZyUkc/yJsc6pt5r5ZP768pXf1YT5F7eblg6oq3xJdSw5eRra5TtRViot4 E/h+tQoUJbaq9XSgXzGw3iqH7qtM8STLI48Vv5lSjSp2yCEO1fvh3MVObxbl1MKMWzF1 UqmILN3sozG7AscSsjzpz88kozF01kxN1vfES+O+080BGURZnudeHPsLGNWacXvp/tJP 3UqA== 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; bh=GL872Cjt9wuJB4I405QO8aWmpz1TrSQZZghYbOSUuQs=; b=noOffsBXSOTRe6+2M7jUfh2fMpzOoMSGh1OacIHs1zzl0D2a/TmKWGmc4CYeLVqoUg nD/y/wAkZELBZiblIZUp1l3HIsJhGLM37nqW0atZn4dW45lcUw4O22OhNNHkcA1JXfzR zKwmIpptHAXnbL2LEmPf8H8fP9yoQBlRjZ91qTNcc7PB0e6kHu5zSXVLVo7Jw/eiVRKE S6e33ASN2MJYtMIf7jJAfRiCH3aHS8FVSCUuZLtyxNzbtbZ1TWVVMyHZz4G4RwvcJ32Z ZI71HOAlisjkvfBWRcK2nWLF6co0+7EpVrh5UreYkPdPGMkMZW5ZD9BTmVPZye/9uDhY VVbg== X-Gm-Message-State: APjAAAUbiEIw31Yt5yP1VRObUZjA5WcCdYN7yrbKK5B/+mgWirRY2x9X kb4cTIUebm/YHUbdpltsuKPfc7Ca X-Google-Smtp-Source: APXvYqxdB5A+kASADoc8rUJG/CoUtCqaRnVze0twHGKZPawsQIgnMl4A4vL8xlAV4M9SZ2axPC/J3Q== X-Received: by 2002:a67:d611:: with SMTP id n17mr14057707vsj.156.1563486669653; Thu, 18 Jul 2019 14:51:09 -0700 (PDT) Received: from Windows10AnyBody.local ([190.199.172.207]) by smtp.gmail.com with ESMTPSA id l184sm13806044vsl.8.2019.07.18.14.51.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 14:51:08 -0700 (PDT) To: v6ops@ietf.org References: From: Alejandro Acosta Message-ID: <7b65c3b8-2058-156d-589e-c1d97d591930@gmail.com> Date: Thu, 18 Jul 2019 17:51:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------F25E9EEA8085AF0AE4AD7B87" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Very basic question: What is IPv6 native? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 21:51:14 -0000 This is a multi-part message in MIME format. --------------F25E9EEA8085AF0AE4AD7B87 Content-Type: multipart/alternative; boundary="------------5BD6BE3FAA60CB929B9C5618" --------------5BD6BE3FAA60CB929B9C5618 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Jordi, =C2=A0 Thanks for this, I was not aware of this draft.=C2=A0 I'm happy th= e definition is in a document, hopefully it moves forward in the WG. Hard to believe so many documents mention "native IPv6" without a clear definition (well, assumptions are just fine but much better to write it down) =C2=A0 So far I like this definition (copy/pasted from your doc): 5. Native dual-stack This can be applied to a host, router, link, network (part), etc. It means that both, IPv4 and IPv6 are configured/used natively (without the need of transition mechanisms). =C2=A0 The part: "without the need of transition mechanisms" imho is the = key. =C2=A0 If you allow me to say something, you can add to your text: "witho= ut the need of transition mechanisms such as encapsulation, protocol translations and/or packet modifications". Adding this won't hurt. =C2=A0 Thanks, good luck. Alejandro, On 7/18/19 4:00 PM, JORDI PALET MARTINEZ wrote: > Hi Alejandro, > > May be something for adding some more text into: > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > Let me know if the existing text is sufficient, or what do you suggest = to add. > > Regards, > Jordi > @jordipalet > =20 > =20 > > =EF=BB=BFEl 18/7/19 21:57, "v6ops en nombre de Alejandro Acosta" escribi=C3= =B3: > > Hello there, > =20 > Sorry if this is not the place to ask this. > =20 > I was looking for the concept of "Native IPv6" with no luck. > =20 > I performed a search in google restricting the results inside > ietf.org. However even when a lot of results with the string "IPv6 > Native" the concept/description/meaning of what IPv6 native is did = not > show up. Among the results I found: > =20 > https://tools.ietf.org/html/rfc6751 (Native IPv6 behind IPv4-to-IPv= 4 NAT > Customer Premises Equipment) > =20 > https://tools.ietf.org/id/draft-v6ops-rfc7084-bis-00.html (Basic > Requirements for IPv6 Customer Edge Routers) > =20 > https://tools.ietf.org/id/draft-lopez-v6ops-dc-ipv6-05.html (IPv6 > Operational Guidelines for Datacenters) > =20 > https://tools.ietf.org/html/rfc7381 () > =20 > And I found this old thread which refer to this very same topic: > =20 > https://mailarchive.ietf.org/arch/msg/ietf/KkkOMeinS-l9i_SaViVXHu= Rw20A > =20 > =20 > Is there any document that I might be missing that officially > describes the concept/meaning of "Native IPv6"? > =20 > =20 > Thanks a lot, > =20 > =20 > Alejandro, > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =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= confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disc= losure, 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 recipi= ent be aware that any disclosure, copying, distribution or use of the con= tents of this information, even if partially, including attached files, i= s strictly prohibited, will be considered a criminal offense, so you must= reply to the original sender to inform about this communication and dele= te it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------5BD6BE3FAA60CB929B9C5618 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello Jordi,

=C2=A0 Thanks for this, I was not aware of this draft.=C2=A0 I'm h= appy the definition is in a document, hopefully it moves forward in the WG. Hard to believe so many documents mention "native IPv6" without a clear definition (well, assumptions are just fine but much better to write it down)

=C2=A0 So far I like this definition (copy/pasted from your doc):<= /p> 

5.  Native dual-stack

   This can be applied to a host, router, link, network (part), etc.  It
   means that both, IPv4 and IPv6 are configured/used natively (without
   the need of transition mechanisms).


=C2=A0 The part: "without the need of transition mechanisms" imho = is the key.

=C2=A0 If you allow me to say something, you can add to your text:= "without the need of transition mechanisms such as encapsulation, protocol translations and/or packet modifications". Adding this won't hurt.


=C2=A0 Thanks, good luck.


Alejandro,


On 7/18/19 4:00 PM, JORDI PALET MARTINEZ wrote:
Hi Alejandro,

May be something for adding some more text into:

https://datatracker.ietf.org/doc/draft-p=
alet-v6ops-ipv6-only/

Let me know if the existing text is sufficient, or what do you suggest to=
 add.

Regards,
Jordi
@jordipalet
=20
=20

=EF=BB=BFEl 18/7/19 21:57, "v6ops en nombre de Alejandro Acosta" <v6ops-bounces@ietf.org en nombre de =
alejandroacostaalamo@gmail.com> escribi=C3=B3:

    Hello there,
   =20
      Sorry if this is not the place to ask this.
   =20
      I was looking for the concept of "Native IPv6" with no luck.
   =20
      I performed a search in google restricting the results inside
    ietf.org. However even when a lot of results with the string "IPv6
    Native" the concept/description/meaning of what IPv6 native is did no=
t
    show up. Among the results I found:
   =20
    https://tools.ietf.org/html/rfc6751 (Native IPv6 behind IP=
v4-to-IPv4 NAT
    Customer Premises Equipment)
   =20
    https://tools.ietf.org/id/draft-v6ops-rf=
c7084-bis-00.html (Basic
    Requirements for IPv6 Customer Edge Routers)
   =20
    https://tools.ietf.org/id/draft-lopez-=
v6ops-dc-ipv6-05.html (IPv6
    Operational Guidelines for Datacenters)
   =20
    https://tools.ietf.org/html/rfc7381 ()
   =20
      And I found this old thread which refer to this very same topic:
   =20
      https://mailarchive.iet=
f.org/arch/msg/ietf/KkkOMeinS-l9i_SaViVXHuRw20A
   =20
   =20
      Is there any document that I might be missing that officially
    describes the concept/meaning of "Native IPv6"?
   =20
   =20
    Thanks a lot,
   =20
   =20
    Alejandro,
   =20
   =20
    _______________________________________________
    v6ops mailing list
    =
v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =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 c=
onfidential. The information is intended to be for the exclusive use of t=
he individual(s) named above and further non-explicilty authorized disclo=
sure, copying, distribution or use of the contents of this information, e=
ven if partially, including attached files, is strictly prohibited and wi=
ll be considered a criminal offense. If you are not the intended recipien=
t be aware that any disclosure, copying, distribution or use of the conte=
nts of this information, even if partially, including attached files, is =
strictly prohibited, will be considered a criminal offense, so you must r=
eply to the original sender to inform about this communication and delete=
 it.



_______________________________________________
v6ops mailing list
v6op=
s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------5BD6BE3FAA60CB929B9C5618-- --------------F25E9EEA8085AF0AE4AD7B87 Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFztkSoBCADJ6Eeff/C7+EifPImW8l/Ic7fslh/AtblJQeuoNCt681imYQN8 Jnvy3euOFGPBllOJDy7Vugc6LEePpOadHTG+m+6BYpBxTs6eqf7qH/TBtESpjMVT 8uf0MElbMJrby+0zF/fhRx5OEcEEiETByNskJhE0fviSwAikXvdzLrWrR6NjTaNG ioZn2h9QXcx0cXCxoBrA/lTxEPs1Ncy3sky08E7KW7jmPSt4VesrQZ/JqcNXyGnt NUi97Aa9TCUtO8PIe3PfzVN0MQeF6xql7XQJGQgocf0X/rYsWD/STX0wA7zVqbdn kAIyicYx/Z8p6QoeiPcwWA5PbomTL0cz0uetABEBAAG0MUFsZWphbmRybyBBY29z dGEgPGFsZWphbmRyb2Fjb3N0YWFsYW1vQGdtYWlsLmNvbT6JAVQEEwEIAD4CGwMF CwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQR9NGXbSCvzsdzzAGBBGAwR8z/TYQUC XPjj+gUJDTO7UAAKCRBBGAwR8z/TYcx1B/kB8VIHe0m7LbpiLAiNcpwdHmn6IrTm IlYUcHPnR/Q6XXN9KQWl/BwQTH01f2FGowrHtZnPT5yh29xcZGuZJO/s/mZmTXAR XZYvX0qPM2UNWg1inPNKea/n1+JopHwQYZPuXywF5hAqHk5BwPdkVzsKxFkvuHFQ +BbG3/dyTCFtfnaRXCDJ5dusEP9c5004/5yRx2O+QQArANmBP4nKPi8xUaejPMdf oEh1ku0EbG3WTzKF3CZR0QiCCeUwTzdrAMDmFpjSg4a50r1TY1fqQvcYPA3CMe4H tJuxToHkk+NGqhAHiABBIJmtqqRm+547HLsfTXFVEi8+JlcUFl9LboR9uQENBFzt kSoBCADFTEbxbHfnmhOMJhAsYjBoEDarMEXC3374KVeEAegF2bBYbnJzz+5/HeVy lZsSJloEtpPwceCOa33x50Qa3VxsOCL5IkBjYHwePQb7Lz8cOfTGug03teH2XZ2g mcr+3s6Mbr5rAPgWMUOIuNtGiDOJpu/xeKUGFn1vslWZAwcDDrDUeEF2j5u5006K nHvwyACXHLUAy0NXbKYexvZPshCCTqavZlAmqRNxBqS6xTm9lmLyKvHzDPOcDLs5 rOYLOg9NoBOXhQib0nHrnY6vnXlQDUlUzYfXiFUoFAsZvwifMhTkVMzaVTcux9xn U+rUx7td+eE0Q2MBgZbGMLam/8jvABEBAAGJATwEGAEIACYCGwwWIQR9NGXbSCvz sdzzAGBBGAwR8z/TYQUCXPjj+gUJDTO7UAAKCRBBGAwR8z/TYdd6B/9wznTFjfQa lkfrHl62M6k3ad4vWJmi2Zx3xOs8MtX89XGhTLBtSGSjxi9Mo6U/Dq86iPeIJaIw EWnT+aw4Mq18bSeMeVilaUrNbhiYqve8a2FAtUXBT/ovwvFY6BrZFrKaeK0k0vqL b9TEr/LNqotLOgQV5BktwM7TQ8Dap1onOkVil2uDnvKR0LBRTf6yddxJXLYJUPXE zJxUCPXodvHWggqrnG7xWHXk4UNWIgNQjSXpI9lXooH/VhRmO2bCpaIba6eRoohG 2c/SDKWXD4qENMpWsLfRtPUZcX7vgF7afIuTvm8F95BfIsOMLMA1K39+s1x2oB9m IlyxqGNfdzAV =3D++GG -----END PGP PUBLIC KEY BLOCK----- --------------F25E9EEA8085AF0AE4AD7B87-- From nobody Thu Jul 18 18:02:49 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6321C120169 for ; Thu, 18 Jul 2019 18:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=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 RfANoDAyARON for ; Thu, 18 Jul 2019 18:02:46 -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 081E1120165 for ; Thu, 18 Jul 2019 18:02:46 -0700 (PDT) Received: from [192.168.0.119] (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id x6J12hkr010248; Fri, 19 Jul 2019 01:02:44 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be [192.168.0.119] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Joel Jaeggli In-Reply-To: Date: Thu, 18 Jul 2019 15:14:40 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alejandro Acosta X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] Very basic question: What is IPv6 native? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 01:02:48 -0000 > On Jul 18, 2019, at 12:57, Alejandro Acosta = wrote: >=20 > Hello there, >=20 > Sorry if this is not the place to ask this. >=20 > I was looking for the concept of "Native IPv6" with no luck. In the era of the early ipv6 networks it was necessary to build = tunneled overlays or employ transitional technologies e.g. 6to4 or = teredo to support transitional ipv6 hosts. these are to be contrasted = with cases where the support of IPv6 is intrinsic (native if you will) = to the network control and forwarding architecture. native as used at = the time implies more about the state of the network at the time then it = does today. it was common at the time to refer to inter domain multicast = using pim and bgp as native multicast as compared to the previously = tunneled mbone. > I performed a search in google restricting the results inside > ietf.org. However even when a lot of results with the string "IPv6 > Native" the concept/description/meaning of what IPv6 native is did not > show up. Among the results I found: >=20 > https://tools.ietf.org/html/rfc6751 (Native IPv6 behind IPv4-to-IPv4 = NAT > Customer Premises Equipment) >=20 > https://tools.ietf.org/id/draft-v6ops-rfc7084-bis-00.html (Basic > Requirements for IPv6 Customer Edge Routers) >=20 > https://tools.ietf.org/id/draft-lopez-v6ops-dc-ipv6-05.html (IPv6 > Operational Guidelines for Datacenters) >=20 > https://tools.ietf.org/html/rfc7381 () >=20 > And I found this old thread which refer to this very same topic: >=20 > = https://mailarchive.ietf.org/arch/msg/ietf/KkkOMeinS-l9i_SaViVXHuRw20A >=20 >=20 > Is there any document that I might be missing that officially > describes the concept/meaning of "Native IPv6"? >=20 >=20 > Thanks a lot, >=20 >=20 > Alejandro, >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 19 22:34:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B151200B4 for ; Fri, 19 Jul 2019 22:34:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 NE-2Zq4jpbnl for ; Fri, 19 Jul 2019 22:34:54 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 281B3120044 for ; Fri, 19 Jul 2019 22:34:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FxAgBupzJd/yYyC4dmghmBRFBwcgMEP?= =?us-ascii?q?4daA4UxiEyaK4EugSQDGDwJAQEBDQEtAgEBAoQ+AoJ2NAkOBAEBAQQCAQEFAQI?= =?us-ascii?q?CaYUqCQiCZ00vCgIwAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBBQIPKR4aAQEFEigGAQEsDAsEAgEIEQQBAR8QMh0IAgQBEggagwGBagMdAQI?= =?us-ascii?q?CCp97AoEIMIhfAQGCIhqCYAGFChiCEwMGCQGJbIM0gUE+gVeCTD6CfYFJgzuCJ?= =?us-ascii?q?owCnmUJAoIZlCeNSwOKPI01lAGDTwICAgIEBQIOAQEFgVA5gVhwFTuTcoIbjVQ?= =?us-ascii?q?BgSABAQ?= X-IPAS-Result: =?us-ascii?q?A2FxAgBupzJd/yYyC4dmghmBRFBwcgMEP4daA4UxiEyaK4E?= =?us-ascii?q?ugSQDGDwJAQEBDQEtAgEBAoQ+AoJ2NAkOBAEBAQQCAQEFAQICaYUqCQiCZ00vC?= =?us-ascii?q?gIwAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQIPKR4aAQE?= =?us-ascii?q?FEigGAQEsDAsEAgEIEQQBAR8QMh0IAgQBEggagwGBagMdAQICCp97AoEIMIhfA?= =?us-ascii?q?QGCIhqCYAGFChiCEwMGCQGJbIM0gUE+gVeCTD6CfYFJgzuCJowCnmUJAoIZlCe?= =?us-ascii?q?NSwOKPI01lAGDTwICAgIEBQIOAQEFgVA5gVhwFTuTcoIbjVQBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.64,285,1559534400"; d="scan'208";a="292133715" Received: from mailauth.avaya.com (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Jul 2019 01:33:22 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2019 01:31:45 -0400 Received: from PWEXCVMAP02.global.avaya.com (135.11.85.81) by AZ-US1EXHC03.global.avaya.com (135.11.85.14) with Microsoft SMTP Server (TLS) id 14.3.468.0; Sat, 20 Jul 2019 01:31:38 -0400 Received: from PWEXCVMAP02.global.avaya.com (135.11.85.81) by PWEXCVMAP02.global.avaya.com (135.11.85.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Sat, 20 Jul 2019 01:31:36 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by PWEXCVMAP02.global.avaya.com (135.11.85.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1531.3 via Frontend Transport; Sat, 20 Jul 2019 01:31:36 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (104.47.40.53) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Fri, 19 Jul 2019 14:05:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lau5ISugm1YdeGWBW4OBAlviKWSSty6Zm+yClDPoFuQzuBCSuR5O9jZ54j/LxKiyZ1aoOppqMDo5BKz+55iLxPRtkFoVv7J07bl/PfzLKRXX8a24JN7F2fa0TKZzTAbgA2xnmsCaY77O3lsuDFZ51fkM6PYVfhZwHQu0JrCw5d7d7KvSk1nnqRXJWXKbnX1jucuOjkQxVNki0k1YJsNAi5fdCfbrtXHm+wsXbtRmuZDHrSJL9aX34gb+tNk4WupuwN1rr5goKLP0dUk5yqQwbhgS5Dc6yTsKiwRorQ7CuImqoB8vLRa8DPNu1uIkFprRDbJwv5yPUqaQf6+0X6YUBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EYcSG54FrbJwQz7+mF3ONtG22G4YUKhONdR6GaYZMso=; b=XKxkmAu+YCMadsgl2B/+HzBjmnQsUiyhebIWtiTzV9IzySRQnaDyIp+GG/M0GE14GhaS/UcA6F5cAZn5OHCnJqSMae2PL/id+2cAoUmRkjK4h93hlZDgTVIDkK6JRKVeXMjNw+PPsESzRkjRDikSdlClQ+kK5L0oBNmsrYuYd9Xu0s0sTzBjhqflZXADg+D95+FS7jpjpbfWUr+ZxQdUSJw26+Bf8TTpxEbtm5Y4ZE+jW+v+Q5Kkhm1NOZt0fAKsTx3uakErJhu3c0zq8rQyD57tk528hoLBbbNfpuxO/df7vW45TES0cfzXJnREC+9uiw2OVri2pJ2psfwRyYMhFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=avaya.com;dmarc=pass action=none header.from=avaya.com;dkim=pass header.d=avaya.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EYcSG54FrbJwQz7+mF3ONtG22G4YUKhONdR6GaYZMso=; b=QNqgiSygzqROYcFL41EzkqLeerAtyyZFIU/htgf70UeapzL16V1ymD4hAoCSMQp7f58/1bGAvn6L5qCzZOVajt/CAkVEqTJVuvBkiEbsVer6m2t86sjWcFYkOGFPy36p0ULELXqT5wYxsSEaksqM5cF+Ls//gSYmIUuPbkf5AiQ= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2698.namprd15.prod.outlook.com (20.179.162.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.11; Fri, 19 Jul 2019 19:05:18 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2094.013; Fri, 19 Jul 2019 19:05:18 +0000 From: "Mudric, Dusan (Dusan)" To: Fred Baker , IPv6 Operations Thread-Topic: [v6ops] IPv6-only draft Thread-Index: AQHVPDZ9IJfHmZTVHkuopK5mC67geabSTZIw Date: Fri, 19 Jul 2019 19:05:18 +0000 Message-ID: References: <5694C033-A38F-4455-9673-EACAAC6324F3@gmail.com> In-Reply-To: <5694C033-A38F-4455-9673-EACAAC6324F3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a41d5c22-46bf-4844-89cc-08d70c7c0a5e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2698; x-ms-traffictypediagnostic: DM6PR15MB2698: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:561; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(366004)(396003)(346002)(13464003)(199004)(189003)(66066001)(6436002)(26005)(229853002)(99286004)(186003)(81166006)(9686003)(55016002)(81156014)(478600001)(53936002)(66446008)(256004)(66556008)(64756008)(6116002)(8676002)(6246003)(33656002)(966005)(3846002)(8936002)(6306002)(74316002)(476003)(446003)(11346002)(7736002)(14444005)(86362001)(305945005)(66574012)(25786009)(110136005)(19627235002)(71200400001)(316002)(2906002)(71190400001)(66476007)(5660300002)(53546011)(7696005)(76176011)(102836004)(55236004)(68736007)(76116006)(6506007)(486006)(52536014)(14454004)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2698; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FFwd30/W1UY/7mOTKzeyDvZptjyi2FhEBG3EadUvR5Hg+6dSeBPpcauZa/CB3xKCx85Pb/hzcjPEm3PPaqYxpu5RKx/y+Kp6ou+yWay4vqbW+LmfaP2jYuRH8akOMHR/7cnuppctlaXKBdRzeJzn81qkkLv9Dc4RRMffeo0IwAZHsrjmVkuG73qNjwJyKeJUm9llyPeAS0qMC+zYyBpHXy0t5twRhPeMq9xcHUEpEsB8Ijybf3iuBTa3LAwecVIOshWbQlKcZ2P3heMIu/2/N4378hewFfJvmraLL1GUzCChZskFQTMTlxjC8L4YjhqF9bqPOpplGi2BtsgoK4q1Zx/BVU+yzwLQ+jkH1RsWKYnsL+QGf9ZHoWkQ4XYtPXYpg8Vzlr3KtJR2soBCjuAKTozYs+F/71nbu46S3mHmD8w= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a41d5c22-46bf-4844-89cc-08d70c7c0a5e X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 19:05:18.3231 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2698 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] IPv6-only draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 05:34:56 -0000 "3. Definition of IPv6-only Consequently, considering the context described in the section above, if we want to be precise and avoid confusing others, we can not use=09 the terminology "IPv6-only" in a generic way, and we need to define what part of the network we are referring to. From that perspective, we define the "IPv6-only" status in a given part(s) of a network, depending on if there is actual native forwarding of IPv4, so IPv4 is not configured neither managed." The document defines IPv6-only not only for the network parts but also for = a host/router. "7. IPv6-only WAN/access IPv6-only WAN or access can be used only if the WAN or access network isn't actually natively forwarding IPv4." Should use affirmative kind of definitions for IPv6-only, not only here but= also in other sections. Instead of "isn't actually natively forwarding IPv= 4" should define what it IS forwarding, like "is natively forwarding IPv6". "10. Transitional IPv6 host/router Transitional IPv6 host/router is a dual-stack host/router with IPv6-only WAN where IPv4 service support is provided by means of transition mechanism, IPv4aaS (IPv4-as-a-service)." Dusan Why is it important to mention WAN address family? Why WAN must be IPv6-onl= y? > -----Original Message----- > From: v6ops On Behalf Of Fred Baker > Sent: Tuesday, July 16, 2019 8:27 PM > To: IPv6 Operations > Subject: [v6ops] IPv6-only draft >=20 > The author is asking for time on the agenda at IETF 105; I told him that = if there > was time at the end of the meeting, it could be part of "AOB". I don't se= e any > discussion on the draft since November 2017. >=20 > FYI, draft-ietf-6man-ipv6only-flag is a different topic. >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dpalet-2Dv6ops-2Dipv6- > 2Donly&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrh > IoUWB8YLZU23029sMQGQ2kY&m=3D1nAt78nefTz-p_aiWCrcg5YAes1Z- > E1BJms0WuHLM2M&s=3DUNkIjLs2G5OnvxDyoSyysQPWYTYrk9wTfadmnnr57kg > &e=3D > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__mailarchive.ietf.org_arch_search_-3Fqdr-3Da-26q-3D-2522draft- > 2Dpalet-2Dv6ops-2Dipv6-2Donly- > 2522&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > UWB8YLZU23029sMQGQ2kY&m=3D1nAt78nefTz-p_aiWCrcg5YAes1Z- > E1BJms0WuHLM2M&s=3DE1m_qHn7RsRktmhF07Nf9eanzgGmtNP7lQ29Kyr5su > E&e=3D >=20 > Your comments appreciated. >=20 > -------------------------------------------------------------------------= ------- > The fact that there is a highway to hell and a stairway to heaven is an > interesting comment on projected traffic volume... >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D1nAt > 78nefTz-p_aiWCrcg5YAes1Z-E1BJms0WuHLM2M&s=3D595l- > RsCyu_0mPOHtZ0uecureSaBYL3jaFjC9O1xAwY&e=3D From nobody Sat Jul 20 08:14:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C4312010D for ; Sat, 20 Jul 2019 08:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=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=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 nG0cseD1Boog for ; Sat, 20 Jul 2019 08:14:20 -0700 (PDT) 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 139C2120094 for ; Sat, 20 Jul 2019 08:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1563635656; x=1564240456; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=5b9yiE+HTTqwVt5RK2UsltByNV+o+PRE4g /5tK8dkBM=; b=FUsl6Zi1C5Bn6kegRIvrUMA4pf1tNFAV8gotnWctDb0zdXEz9/ Hrruhyy6EFa8cHja+YGtzam6QuBeoxf4lUci9Jy256qqDKpNiPURbTaIrQszMBm3 S6qW2cMm6PqbvMaXGcCxJB8psv7UF9KMKlrg+jLHvVu7GlkUYmBM5B06Q= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 20 Jul 2019 17:14:16 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 20 Jul 2019 17:14:15 +0200 Received: from [172.20.10.5] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006331036.msg for ; Sat, 20 Jul 2019 17:14:14 +0200 X-MDRemoteIP: 213.4.191.98 X-MDHelo: [172.20.10.5] X-MDArrival-Date: Sat, 20 Jul 2019 17:14:14 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1104a502aa=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.c.190715 Date: Sat, 20 Jul 2019 16:59:49 +0200 From: JORDI PALET MARTINEZ To: Alejandro Acosta , Message-ID: <86EF99D3-92CA-4F57-BBE7-C8883CED8EC5@consulintel.es> Thread-Topic: [v6ops] Very basic question: What is IPv6 native? References: <7b65c3b8-2058-156d-589e-c1d97d591930@gmail.com> In-Reply-To: <7b65c3b8-2058-156d-589e-c1d97d591930@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3646487623_872563585" Archived-At: Subject: Re: [v6ops] Very basic question: What is IPv6 native? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 15:14:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3646487623_872563585 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Alejandro, =20 I need to think it twice, just to be safe, but in principle I agree with ad= ding the text that you=E2=80=99re suggesting. =20 Regards, Jordi @jordipalet =20 =20 =20 El 18/7/19 23:51, "v6ops en nombre de Alejandro Acosta" escribi=C3=B3: =20 Hello Jordi, Thanks for this, I was not aware of this draft. I'm happy the definition= is in a document, hopefully it moves forward in the WG. Hard to believe so= many documents mention "native IPv6" without a clear definition (well, ass= umptions are just fine but much better to write it down) So far I like this definition (copy/pasted from your doc): 5.=C2=A0 Native dual-stack =20 =C2=A0=C2=A0 This can be applied to a host, router, link, network (part), e= tc.=C2=A0 It =C2=A0=C2=A0 means that both, IPv4 and IPv6 are configured/used natively (w= ithout =C2=A0 =C2=A0the need of transition mechanisms). =20 The part: "without the need of transition mechanisms" imho is the key. If you allow me to say something, you can add to your text: "without the = need of transition mechanisms such as encapsulation, protocol translations = and/or packet modifications". Adding this won't hurt. =20 Thanks, good luck. =20 Alejandro, =20 On 7/18/19 4:00 PM, JORDI PALET MARTINEZ wrote: Hi Alejandro, =20 May be something for adding some more text into: =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ =20 Let me know if the existing text is sufficient, or what do you suggest to a= dd. =20 Regards, Jordi @jordipalet =20 =C2=A0 =20 =EF=BB=BFEl 18/7/19 21:57, "v6ops en nombre de Alejandro Acosta" escribi=C3=B3: =20 =C2=A0=C2=A0=C2=A0 Hello there, =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Sorry if this is not the place to ask t= his. =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I was looking for the concept of "Nativ= e IPv6" with no luck. =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I performed a search in google restrict= ing the results inside =C2=A0=C2=A0=C2=A0 ietf.org. However even when a lot of results with the st= ring "IPv6 =C2=A0=C2=A0=C2=A0 Native" the concept/description/meaning of what IPv6 nat= ive is did not =C2=A0=C2=A0=C2=A0 show up. Among the results I found: =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/rfc6751 (Native IPv6 be= hind IPv4-to-IPv4 NAT =C2=A0=C2=A0=C2=A0 Customer Premises Equipment) =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/id/draft-v6ops-rfc7084-bis-0= 0.html (Basic =C2=A0=C2=A0=C2=A0 Requirements for IPv6 Customer Edge Routers) =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/id/draft-lopez-v6ops-dc-ipv6= -05.html (IPv6 =C2=A0=C2=A0=C2=A0 Operational Guidelines for Datacenters) =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/rfc7381 () =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0And I found this old thread which refer= to this very same topic: =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://mailarchive.ietf.org/arch/msg/i= etf/KkkOMeinS-l9i_SaViVXHuRw20A =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Is there any document that I might be m= issing that officially =C2=A0=C2=A0=C2=A0 describes the concept/meaning of "Native IPv6"? =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Thanks a lot, =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Alejandro, =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0_______________________________________________ =C2=A0=C2=A0=C2=A0 v6ops mailing list =C2=A0=C2=A0=C2=A0 v6ops@ietf.org =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/v6ops =C2=A0=C2=A0=C2=A0=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 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. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. --B_3646487623_872563585 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Alejandro,

 

I need to think i= t twice, just to be safe, but in principle I agree with adding the text tha= t you=E2=80=99re suggesting.

&= nbsp;

Regards,

Jordi

=

@jordipalet

 

 

 

El 18/7/19 23:51, "v6ops = en nombre de Alejandro Acosta" <v6ops-bounces@ietf.org en nombre de alejandroacostaalamo@gmail.com> escribi=C3=B3:=

 

Hello Jor= di,

  Thanks for this, I= was not aware of this draft.  I'm happy the definition is in a docume= nt, hopefully it moves forward in the WG. Hard to believe so many documents= mention "native IPv6" without a clear definition (well, assumpti= ons are just fine but much better to write it down)

  So far I like this definition (copy/pasted f= rom your doc):

5.=C2=A0 Native dual-stack
 
=C2=A0=C2=A0 This can be applied to a host, router, link, network (part), =
etc.=C2=A0 It
=C2=A0=C2=A0 means tha=
t both, IPv4 and IPv6 are configured/used natively (without
=C2=A0 =C2=A0the need of transition mechanisms).

 

  The part: "without the need of transition mechanisms" imho is the key.

  If you allow me to say so= mething, you can add to your text: "without the need of transition mec= hanisms such as encapsulation, protocol translations and/or packet modifica= tions". Adding this won't hurt.

 

  Thanks,= good luck.

 =

Alejandro,

 

On 7/18/19 4:00 PM, JORDI PALET MARTINEZ wrote:

Hi Alejandro,
 
May be something for adding some more text into:
 
https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/
 
Let me know if the existing text is sufficient=
, or what do you suggest to add.
 
Regards,
Jordi
@jordipalet
 
=C2=A0=

 
<= pre style=3D'margin-left:35.4pt'>=EF=BB=BFEl 18/7/19 21:57, "v6ops en = nombre de Alejandro Acosta" <v6ops-bounces@ietf.org en nombr= e de alejandroacostaalamo@gmail.com> escribi=C3=B3:= 
 
=C2=A0=C2=A0=C2=A0 Hello there,
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Sorry if this is not=
 the place to ask this.
=
=C2=A0=C2=A0=C2=A0 
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I was looking for the concept of "Nat=
ive IPv6" with no luck.
=C2=A0=C2=A0=C2=A0 
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I performed a search in google restrict=
ing the results inside
=
=C2=A0=C2=A0=C2=A0 ietf.org. However even when a lot of results with the st=
ring "IPv6
=C2=A0=C2=
=A0=C2=A0 Native" the concept/description/meaning of what IPv6 native =
is did not
=C2=A0=C2=A0=
=C2=A0 show up. Among the results I found:
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/rfc6751 (Native IPv6 behind IPv4-=
to-IPv4 NAT
=C2=A0=C2=A0=
=C2=A0 Customer Premises Equipment)
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/id/draft-v6ops-rfc7084-bis-=
00.html (Basic
=C2=A0=
=C2=A0=C2=A0 Requirements for IPv6 Customer Edge Routers)
<= pre style=3D'margin-left:35.4pt'>=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/id/=
draft-lopez-v6ops-dc-ipv6-05.html (IPv6
=C2=A0=C2=A0=C2=A0 Operational Guidelines for Datacenters)
=C2=A0=C2=
=A0=C2=A0 
=C2=A0=C2=A0=
=C2=A0=C2=A0https://tools.i=
etf.org/html/rfc7381 ()
=C2=A0=C2=A0=C2=A0 
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0And I found this old thread which refer=
 to this very same topic:
=C2=A0=C2=A0=C2=A0 
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://mailarchive.ietf.org/arch/=
msg/ietf/KkkOMeinS-l9i_SaViVXHuRw20A
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Is there any document that I=
 might be missing that officially
=C2=A0=C2=A0=C2=A0 describes the concept/meaning of "Native I=
Pv6"?
=C2=A0=C2=A0=
=C2=A0 
=C2=A0=C2=A0=C2=
=A0=C2=A0
=C2=A0=C2=A0=C2=
=A0=C2=A0Thanks a lot,
=
=C2=A0=C2=A0=C2=A0 
=C2=
=A0=C2=A0=C2=A0=C2=A0
=C2=
=A0=C2=A0=C2=A0=C2=A0Alejandro,
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0_______________________________________________
=C2=A0=C2=A0=C2=A0 v6ops m=
ailing list
=C2=A0=C2=A0=
=C2=A0 v6ops@ietf.org
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/v6=
ops
=C2=A0=C2=A0=C2=
=A0 
 
 
 
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://ww=
w.theipv6company.com
=
The IPv6 Company
&nb=
sp;
This electronic message co=
ntains information which may be privileged or confidential. The information=
 is intended to be for the exclusive use of the individual(s) named above a=
nd further non-explicilty authorized disclosure, copying, distribution or u=
se of the contents of this information, even if partially, including attach=
ed files, is strictly prohibited and will be considered a criminal offense.=
 If you are not the intended recipient be aware that any disclosure, copyin=
g, distribution or use of the contents of this information, even if partial=
ly, 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.
 
&nbs=
p;
 
_____________________________________________=
__
v6ops mailing list
v6ops@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/v6ops

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


******************= ****************************
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.

--B_3646487623_872563585-- From nobody Sat Jul 20 08:43:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B1C12010D for ; Sat, 20 Jul 2019 08:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 2Q4_wAPndAsX for ; Sat, 20 Jul 2019 08:43:33 -0700 (PDT) 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 30B2E120103 for ; Sat, 20 Jul 2019 08:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1563637410; x=1564242210; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=SGbR6ILL vDCxK1jVSGmpE3sYWZWMys2MNgPpbstAM1k=; b=jXWldLAu237Je8gdeM7BTBI/ t99CLPoubDqMgZawcFlesSJC6Lr4hgviE9ZsbA4pes7llSpKQ20NiXWnEl6eMzDc TTUH/UsgqOfb+6ROi4HGJlWCHck+sRmop8Jm4L6JeBapuhZxKAOyY1+dE0vGRjg0 W4vx+HopqHV4+TpDMrY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 20 Jul 2019 17:43:30 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 20 Jul 2019 17:43:30 +0200 Received: from [172.16.45.27] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006331061.msg for ; Sat, 20 Jul 2019 17:43:29 +0200 X-MDRemoteIP: 82.3.55.76 X-MDHelo: [172.16.45.27] X-MDArrival-Date: Sat, 20 Jul 2019 17:43:29 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1104a502aa=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.c.190715 Date: Sat, 20 Jul 2019 16:54:03 +0200 From: JORDI PALET MARTINEZ To: "Mudric, Dusan (Dusan)" , IPv6 Operations Message-ID: Thread-Topic: [v6ops] IPv6-only draft References: <5694C033-A38F-4455-9673-EACAAC6324F3@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-only draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 15:43:36 -0000 Hi Dusan, =EF=BB=BFEl 20/7/19 7:35, "v6ops en nombre de Mudric, Dusan (Dusan)" escribi=C3=B3: =20 =20 "3. Definition of IPv6-only =20 Consequently, considering the context described in the section above= , if we want to be precise and avoid confusing others, we can not use= =09 the terminology "IPv6-only" in a generic way, and we need to define what part of the network we are referring to. =20 From that perspective, we define the "IPv6-only" status in a given part(s) of a network, depending on if there is actual native forwarding of IPv4, so IPv4 is not configured neither managed." =20 The document defines IPv6-only not only for the network parts but also = for a host/router. -> I see this document as to have view "end-to-end". So, from host A (sourc= e) to host B (destination), is it IPv6-only? Under that perspective, the ho= sts, routers, involve in that end-to-end communication, are also part of th= e network. If this is not clear, I could expand the text on this section to= clarify that. Do you have any suggested wording? =20 "7. IPv6-only WAN/access =20 IPv6-only WAN or access can be used only if the WAN or access networ= k isn't actually natively forwarding IPv4." =20 Should use affirmative kind of definitions for IPv6-only, not only here= but also in other sections. Instead of "isn't actually natively forwarding= IPv4" should define what it IS forwarding, like "is natively forwarding IP= v6". -> I think it is clearer with the negative form, unless this is incorrect i= n English? I'm not native speaker. If I use affirmative it gets more comple= x: "isn't actually natively forwarding IPv4" vs "is actually forwarding natively IPv6 and not natively IPv4" =20 "10. Transitional IPv6 host/router =20 Transitional IPv6 host/router is a dual-stack host/router with IPv6-only WAN where IPv4 service support is provided by means of transition mechanism, IPv4aaS (IPv4-as-a-service)." -> not sure what is the input here? =20 Dusan =20 Why is it important to mention WAN address family? Why WAN must be IPv6= -only? -> Because the full reason or "starting-point" of the document is the IPv6-= only terminology clarification. =20 > -----Original Message----- > From: v6ops On Behalf Of Fred Baker > Sent: Tuesday, July 16, 2019 8:27 PM > To: IPv6 Operations > Subject: [v6ops] IPv6-only draft >=20 > The author is asking for time on the agenda at IETF 105; I told him t= hat if there > was time at the end of the meeting, it could be part of "AOB". I don'= t see any > discussion on the draft since November 2017. >=20 > FYI, draft-ietf-6man-ipv6only-flag is a different topic. >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dpalet-2Dv6ops-2Dipv6- > 2Donly&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrh > IoUWB8YLZU23029sMQGQ2kY&m=3D1nAt78nefTz-p_aiWCrcg5YAes1Z- > E1BJms0WuHLM2M&s=3DUNkIjLs2G5OnvxDyoSyysQPWYTYrk9wTfadmnnr57kg > &e=3D > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__mailarchive.ietf.org_arch_search_-3Fqdr-3Da-26q-3D-2522draft- > 2Dpalet-2Dv6ops-2Dipv6-2Donly- > 2522&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > UWB8YLZU23029sMQGQ2kY&m=3D1nAt78nefTz-p_aiWCrcg5YAes1Z- > E1BJms0WuHLM2M&s=3DE1m_qHn7RsRktmhF07Nf9eanzgGmtNP7lQ29Kyr5su > E&e=3D >=20 > Your comments appreciated. >=20 > ---------------------------------------------------------------------= ----------- > The fact that there is a highway to hell and a stairway to heaven is = an > interesting comment on projected traffic volume... >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D1nAt > 78nefTz-p_aiWCrcg5YAes1Z-E1BJms0WuHLM2M&s=3D595l- > RsCyu_0mPOHtZ0uecureSaBYL3jaFjC9O1xAwY&e=3D =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Sun Jul 21 08:08:36 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124512004E; Sun, 21 Jul 2019 08:08:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otpLMIbSFqVH; Sun, 21 Jul 2019 08:08:25 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 8A85612004D; Sun, 21 Jul 2019 08:08:23 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6LF7GuH000611; Sun, 21 Jul 2019 11:07:16 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6LF7GuH000611 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563721637; bh=tDXdBT6tuxddnN6Xk4xM9QUMNStvRa+ATtcItm/tBXQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=BGPz6S2zHsq/xv7KVyQ+keeFpPS7iz/fQx0RlskFLXuv8hv4J03Uf511J7GaLmFxF yuHDwgKHRTJ7Oxun7nWJ4yyxES3U9c+TjqPQuxmtT4Bc/twXgVhVpDlRTSwuLddm6d ToBfkMa2jTli67uZ1TStIoNfISEzVNo5WvbHPB/I= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6LF7F7H023437; Sun, 21 Jul 2019 11:07:15 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Sun, 21 Jul 2019 11:07:15 -0400 From: Roman Danyliw To: JORDI PALET MARTINEZ , =?utf-8?B?Sm9yZGkgUGFsZXQgTWFydMOtbmV6?= , "mohamed.boucadair@orange.com" , =?utf-8?B?Sm9yZGkgUGFsZXQgTWFydMOtbmV6?= , The IESG CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) Thread-Index: AQHVOJSLz80E9LpUO0GqUszue7UbHabVOk8Q Date: Sun, 21 Jul 2019 15:07:14 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33DE230@marchand> References: <429F374B-C5A0-4038-9DA6-48138E1946D0@consulintel.es> In-Reply-To: <429F374B-C5A0-4038-9DA6-48138E1946D0@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 15:08:28 -0000 SGkhDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZXMgaW4gLTA4IHRvIGFkZHJlc3MgIG15IGNvbW1l bnRzLg0KDQpSb21hbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpP UkRJIFBBTEVUIE1BUlRJTkVaIFttYWlsdG86am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXNdDQo+ IFNlbnQ6IEZyaWRheSwgSnVseSAxMiwgMjAxOSA1OjMxIEFNDQo+IFRvOiBSb21hbiBEYW55bGl3 IDxyZGRAY2VydC5vcmc+OyBKb3JkaSBQYWxldCBNYXJ0w61uZXoNCj4gPGpvcmRpLnBhbGV0QHRo ZWlwdjZjb21wYW55LmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207DQo+IEpvcmRp IFBhbGV0IE1hcnTDrW5leiA8am9yZGkucGFsZXQ9NDB0aGVpcHY2Y29tcGFueS5jb21AZG1hcmMu aWV0Zi5vcmc+Ow0KPiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IHY2b3BzQGlldGYu b3JnOyBkcmFmdC1pZXRmLXY2b3BzLW5hdDY0LWRlcGxveW1lbnRAaWV0Zi5vcmc7IHY2b3BzLQ0K PiBjaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gUm9tYW4gRGFueWxpdydz IE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXY2b3BzLQ0KPiBuYXQ2NC1kZXBsb3ltZW50LTA3 OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gVGhhbmtzIGEgbG90LCBkb25lIGFscmVhZHkgaW4gdjA4 Lg0KPiANCj4gUmVnYXJkcywNCj4gSm9yZGkNCj4gQGpvcmRpcGFsZXQNCj4gDQo+IA0KPiANCj4g 77u/RWwgMTIvNy8xOSAzOjM3LCAidjZvcHMgZW4gbm9tYnJlIGRlIFJvbWFuIERhbnlsaXciIDx2 Nm9wcy0NCj4gYm91bmNlc0BpZXRmLm9yZyBlbiBub21icmUgZGUgcmRkQGNlcnQub3JnPiBlc2Ny aWJpw7M6DQo+IA0KPiAgICAgSGkhDQo+IA0KPiAgICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiAgICAgPiBGcm9tOiBKb3JkaSBQYWxldCBNYXJ0w61uZXogW21haWx0bzpqb3JkaS5w YWxldEB0aGVpcHY2Y29tcGFueS5jb21dDQo+ICAgICA+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEx LCAyMDE5IDM6MjcgQU0NCj4gICAgID4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207 IEpvcmRpIFBhbGV0IE1hcnTDrW5leg0KPiAgICAgPiA8am9yZGkucGFsZXQ9NDB0aGVpcHY2Y29t cGFueS5jb21AZG1hcmMuaWV0Zi5vcmc+OyBSb21hbiBEYW55bGl3DQo+ICAgICA+IDxyZGRAY2Vy dC5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gICAgID4gQ2M6IHY2b3BzQGlldGYu b3JnOyBkcmFmdC1pZXRmLXY2b3BzLW5hdDY0LWRlcGxveW1lbnRAaWV0Zi5vcmc7IHY2b3BzLQ0K PiAgICAgPiBjaGFpcnNAaWV0Zi5vcmcNCj4gICAgID4gU3ViamVjdDogUmU6IFJvbWFuIERhbnls aXcncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC0NCj4gICAgID4gZGVw bG95bWVudC0wNzogKHdpdGggQ09NTUVOVCkNCj4gICAgID4NCj4gICAgID4gSGkgTWVkLA0KPiAg ICAgPg0KPiAgICAgPiBUaGFua3MgYSBsb3QhIHRoYXQncyBhIHZlcnkgZ29vZCAibWlkZGxlIHBv aW50IiByZWZlcmVuY2UuIEl0IGlzIG9ubHkgYWJvdXQNCj4gVVMsDQo+ICAgICA+IEkgd2lsbCB0 cnkgdG8gc2VlIGlmIHRoZXJlIGlzIGEgc2ltaWxhciBvbmUgdGhhdCBzaG93cyBhbHNvIG90aGVy IHJlZ2lvbnMuDQo+ICAgICA+DQo+ICAgICA+IFJlZ2FyZHMsDQo+ICAgICA+IEpvcmRpDQo+ICAg ICA+IEBqb3JkaXBhbGV0DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+IO+7v0VsIDExLzcvMTkg OTowNSwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iDQo+ICAgICA+IDxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPiBlc2NyaWJpw7M6DQo+ICAgICA+DQo+ICAgICA+ICAgICBIaSBK b3JkaSwgYWxsLA0KPiAgICAgPg0KPiAgICAgPiAgICAgT25lIGNvbW1lbnQgYmVsb3cuDQo+ICAg ICA+DQo+ICAgICA+ICAgICBDaGVlcnMsDQo+ICAgICA+ICAgICBNZWQNCj4gICAgID4NCj4gICAg ID4gICAgID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ICAgICA+ICAgICA+IERlIDog djZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvcmRp IFBhbGV0DQo+ICAgICA+ICAgICA+IE1hcnTDrW5leg0KPiAgICAgPiAgICAgPiBFbnZvecOpIDog amV1ZGkgMTEganVpbGxldCAyMDE5IDA4OjQxDQo+ICAgICA+ICAgICA+IMOAIDogUm9tYW4gRGFu eWxpdzsgVGhlIElFU0cNCj4gICAgID4gICAgID4gQ2MgOiB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi12Nm9wcy1uYXQ2NC1kZXBsb3ltZW50QGlldGYub3JnOw0KPiB2Nm9wcy0NCj4gICAgID4g ICAgID4gY2hhaXJzQGlldGYub3JnDQo+ICAgICA+ICAgICA+IE9iamV0IDogUmU6IFt2Nm9wc10g Um9tYW4gRGFueWxpdydzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLQ0KPiB2Nm9wcy0NCj4g ICAgID4gICAgID4gbmF0NjQtZGVwbG95bWVudC0wNzogKHdpdGggQ09NTUVOVCkNCj4gICAgID4g ICAgID4NCj4gICAgID4gICAgID4gSGkgUm9tYW4sDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAg ICA+IFRoYW5rcyBhIGxvdCBmb3IgeW91ciBpbnB1dHMuDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ ICAgICA+IFNlZSBiZWxvdywgaW4tbGluZS4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4g UmVnYXJkcywNCj4gICAgID4gICAgID4gSm9yZGkNCj4gICAgID4gICAgID4gQGpvcmRpcGFsZXQN Cj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4g77u/RWwgMTEvNy8x OSAyOjQ0LCAiUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRyYWNrZXIiDQo+IDxub3JlcGx5QGlldGYu b3JnPg0KPiAgICAgPiAgICAgPiBlc2NyaWJpw7M6DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAg ICA+ICAgICBSb21hbiBEYW55bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPiAgICAgPiAgICAgPiAgICAgZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1kZXBs b3ltZW50LTA3OiBObyBPYmplY3Rpb24NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAg IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvDQo+IGFsbA0KPiAgICAgPiAgICAgPiAgICAgZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0DQo+ICAgICA+ICAg ICA+IHRoaXMNCj4gICAgID4gICAgID4gICAgIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgUGxl YXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt DQo+ICAgICA+ICAgICA+IGNyaXRlcmlhLmh0bWwNCj4gICAgID4gICAgID4gICAgIGZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVA0KPiBwb3NpdGlvbnMu DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ICAgICBUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kDQo+ IGhlcmU6DQo+ICAgICA+ICAgICA+ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXY2b3BzLW5hdDY0LQ0KPiBkZXBsb3ltZW50Lw0KPiAgICAgPiAgICAgPg0K PiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAgICAgPiAgICAgPiAgICAgQ09NTUVOVDoNCj4gICAgID4gICAgID4gICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAgICgxKSBTZWN0aW9uIDUu ICBJcyB0aGVyZSBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdGhhdCBjYW4gYmUgbWFkZQ0KPiAg ICAgPiAgICAgPiBhYm91dCB0aGUNCj4gICAgID4gICAgID4gICAgIHN1Y2Nlc3NmdWwgZGVwbG95 bWVudCBvbiBjZWxsdWxhciBuZXR3b3Jrcz8NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4g RG8geW91IG1lYW4gY2l0aW5nIHNwZWNpZmljIG9wZXJhdG9ycz8gSSBjYW4gbmFtZSBzZXZlcmFs IGluIGFsbW9zdA0KPiAgICAgPiBldmVyeQ0KPiAgICAgPiAgICAgPiBjb250aW5lbnQsIGJ1dCBJ J20gbm90IGNvbnZpbmNlZCB0aGlzIGlzIGNvcnJlY3QgaW4gYW4gSUVURiBkb2N1bWVudA0KPiAu Li4NCj4gICAgID4gICAgID4NCj4gDQo+ICAgICBJJ20gZmxleGlibGUuICBUaGUgdGV4dCBhc3Nl cnRzIHRoaXMgaXMgdXNlZCB3aWRlbHkuICBJIHdhcyB3b25kZXJpbmcgaWYgYW55DQo+IGluZm9y bWF0aXZlIHJlZmVyZW5jZSBjb3VsZCBwb2ludCB0byB0aGF0Lg0KPiANCj4gICAgID4gICAgIFtN ZWRdIE5vIG5lZWQgdG8gYmUgZXhoYXVzdGl2ZSBoZXJlLCBJIHN1Z2dlc3QgdG8gYWRkIG9uZSBz aW5nbGUNCj4gcG9pbnRlcjoNCj4gICAgID4gaHR0cHM6Ly93d3cud29ybGRpcHY2bGF1bmNoLm9y Zy9tYWpvci1tb2JpbGUtdXMtbmV0d29ya3MtcGFzcy01MC0NCj4gaXB2Ni0NCj4gICAgID4gdGhy ZXNob2xkLy4gSGF2aW5nIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSBpcyBoZWxwZnVsIGZvciB0 aGlzIGtpbmQgb2YNCj4gICAgID4gc3RhdGVtZW50cyAoYmVjYXVzZSBvdGhlcndpc2UsIHRoaXMg bWF5IGJlIGNvbnNpZGVyZWQgYXMgc3BlY3VsYXRpdmUpLg0KPiAgICAgPg0KPiAgICAgPg0KPiAg ICAgPiAgICAgPiAgICAgKDIpIFNlY3Rpb24gNy4gIENvbnNpZGVyIGFkZGluZyBhbiBleHBsaWNp dCBzdGF0ZW1lbnQgc3VjaCBhcyB0aGUNCj4gICAgID4gICAgID4gZm9sbG93aW5nDQo+ICAgICA+ ICAgICA+ICAgICBhZnRlciB0aGUgaW50cm8gc2VudGVuY2UgdGhhdCDigJxubyBuZXcgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgYXJlDQo+ICAgICA+ICAgICA+IGFkZGVk4oCdOg0KPiAgICAgPiAg ICAgPg0KPiAgICAgPiAgICAgPiAgICAgQXMgbm90ZWQgaW4gdGhlIHJlbGV2YW50IHNlY3Rpb25z IGFib3ZlLCB0aGUgTkFUNjQgYW5kIEROUzY0DQo+ICAgICA+ICAgICA+IHRlY2hub2xvZ2llcyBj YW4NCj4gICAgID4gICAgID4gICAgIGltcGFjdCB0aGUgZWZmaWNhY3kgb3IgZnVuY3Rpb25hbGl0 eSBvZiBrZXkgc2VjdXJpdHkgKGkuZS4sIEROU1NFQw0KPiBhbmQNCj4gICAgID4gICAgID4gVlBO cykNCj4gICAgID4gICAgID4gICAgIGFuZCBwcml2YWN5IHByZXNlcnZpbmcgKGkuZS4sIEROUy1v dmVyLVRMUyBhbmQgRE5TLW92ZXItSFRUUCkNCj4gICAgID4gICAgID4gdGVjaG5vbG9naWVzLg0K PiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAtPiBJIHdpbGwgbmVlZCB0byByZXdvcmQgaXQu IFRoaXMgaXMgcmlnaHQgaW4gdGhlIHJlZmVyZW5jZSB0byBETlNTRUMuDQo+ICAgICA+ICAgICA+ IEhvd2V2ZXIgVlBOcyBhbmQgRE5TIHByaXZhY3ksIHRoZSBwb2ludCBpcyBvbiB0aGUgb3RoZXIg d2F5DQo+IGFyb3VuZA0KPiAgICAgPiAodGhvc2UNCj4gICAgID4gICAgID4gdGVjaG5vbG9naWVz IGNhbiBhdm9pZCB0aGUgRE5TNjQgcGVyZm9ybWluZyBjb3JyZWN0bHksIGFuZCB0aHVzLA0KPiBi cmVhaw0KPiAgICAgPiAgICAgPiBOQVQ2NCkuDQo+IA0KPiAgICAgUmlnaHQuICBJIGJvdGNoZWQg d2hhdC1icmVha3Mtd2hhdCBzbyBwbGVhc2UgZG8gcmV3b3JkIGl0Lg0KPiANCj4gICAgID4gICAg ID4gICAgICgzKSBFZGl0b3JpYWwgTml0cw0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAg ICAgKiogU2VjdGlvbiAxLiAgRWRpdG9yaWFsLiBzL3RvZGF5IHVucmVhbGlzdGljL3VucmVhbGlz dGljIHRvZGF5Lw0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgKiogU2VjdGlvbiA1 LiAgVHlwby4gIHMvbGVhcm4gaGUvbGVhcm4gdGhlLw0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAg ICAgPiAgICAgKiogU2VjdGlvbiA1LiAgRWRpdG9yaWFsLiAg4oCcSHVuZHJlZHMgb2YgbWlsbGlv bnMgb2YgdXNlcnPigJ0gbWVudGlvbmVkDQo+ICAgICA+ICAgICA+IHR3aWNlLg0KPiAgICAgPiAg ICAgPg0KPiAgICAgPiAgICAgPiAgICAgT0xEOg0KPiAgICAgPiAgICAgPiAgICAgTkFUNjQvNDY0 WExBVCBoYXMgZGVtb25zdHJhdGVkIHRvIGJlIGEgdmFsaWQgY2hvaWNlIGluIHNldmVyYWwNCj4g ICAgID4gICAgID4gc2NlbmFyaW9zDQo+ICAgICA+ICAgICA+ICAgICAoSVB2Ni1JUHY0IGFuZCBJ UHY0LUlQdjYtSVB2NCksIHdpdGggaHVuZHJlZHMgb2YgbWlsbGlvbnMgb2YgdXNlcnMsDQo+ICAg ICA+ICAgICA+IGJlaW5nIHRoZQ0KPiAgICAgPiAgICAgPiAgICAgcHJlZG9taW5hbnQgbWVjaGFu aXNtIGluIHRoZSBtYWpvcml0eSBvZiB0aGUgY2VsbHVsYXIgbmV0d29ya3MNCj4gICAgID4gKHdo aWNoDQo+ICAgICA+ICAgICA+IGFjY291bnQNCj4gICAgID4gICAgID4gICAgIGZvciBodW5kcmVk cyBvZiBtaWxsaW9ucyBvZiB1c2VycykuDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ICAg ICBORVc6DQo+ICAgICA+ICAgICA+ICAgICBOQVQ2NC80NjRYTEFUIGhhcyBkZW1vbnN0cmF0ZWQg dG8gYmUgYSB2YWxpZCBjaG9pY2UgaW4gc2V2ZXJhbA0KPiAgICAgPiAgICAgPiBzY2VuYXJpb3MN Cj4gICAgID4gICAgID4gICAgIChJUHY2LUlQdjQgYW5kIElQdjQtSVB2Ni1JUHY0KSBpbiBjZWxs dWxhciBuZXR3b3JrcyB3aGljaCBhY2NvdW50DQo+IGZvcg0KPiAgICAgPiAgICAgPiBodW5kcmVk cw0KPiAgICAgPiAgICAgPiAgICAgb2YgbWlsbGlvbnMgb2YgdXNlcnMuDQo+ICAgICA+ICAgICA+ DQo+ICAgICA+ICAgICA+IE5vdGVkIGFuZCBjb3JyZWN0ZWQgYWxsIHRob3NlIG5pdHMgaW4gbXkg aW50ZXJuYWwgdmVyc2lvbi4gSSB3aWxsIHdhaXQgYQ0KPiAgICAgPiAgICAgPiBjb3VwbGUgb2Yg ZGF5cyBiZWZvcmUgcHVibGlzaGluZyBpdCwgaW4gY2FzZSB0aGVyZSBhcmUgYW55IGZ1cnRoZXIN Cj4gaW5wdXRzLg0KPiANCj4gICAgIFRoYW5rcyBmb3IgZml4aW5nIHRoZXNlLg0KPiANCj4gICAg IFRoYW5rcywNCj4gICAgIFJvbWFuDQo+IA0KPiAgICAgPiAgICAgPg0KPiAgICAgPg0KPiAgICAg Pg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQo+ICAgICA+IElQdjQgaXMgb3Zlcg0KPiAgICAgPiBBcmUgeW91 IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gICAgID4gaHR0cDovL3d3dy50aGVpcHY2 Y29tcGFueS5jb20NCj4gICAgID4gVGhlIElQdjYgQ29tcGFueQ0KPiAgICAgPg0KPiAgICAgPiBU aGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUg cHJpdmlsZWdlZCBvcg0KPiAgICAgPiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBp bnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YNCj4gdGhlDQo+ICAgICA+IGlu ZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9y aXplZA0KPiBkaXNjbG9zdXJlLA0KPiAgICAgPiBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNl IG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmDQo+ICAgICA+IHBh cnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCB3aWxsIGJlDQo+ICAgICA+IGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlDQo+IGF3YXJlDQo+ICAgICA+IHRo YXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNv bnRlbnRzIG9mIHRoaXMNCj4gICAgID4gaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBp bmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5DQo+IHByb2hpYml0ZWQsDQo+ICAg ICA+IHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJl cGx5IHRvIHRoZSBvcmlnaW5hbA0KPiAgICAgPiBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMg Y29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiAgICAgPg0KPiAgICAgPg0KPiANCj4gICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICB2 Nm9wcyBtYWlsaW5nIGxpc3QNCj4gICAgIHY2b3BzQGlldGYub3JnDQo+ICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiANCj4gDQo+IA0KPiAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zl cg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cDovL3d3dy50 aGVpcHY2Y29tcGFueS5jb20NCj4gVGhlIElQdjYgQ29tcGFueQ0KPiANCj4gVGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg b3INCj4gY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFu ZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwNCj4gY29weWlu ZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlv biwgZXZlbiBpZg0KPiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZQ0KPiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2Zm ZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZQ0KPiB0 aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBj b250ZW50cyBvZiB0aGlzDQo+IGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVk aW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLA0KPiB3aWxsIGJlIGNv bnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3Jp Z2luYWwNCj4gc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRl bGV0ZSBpdC4NCj4gDQo+IA0KDQo= From nobody Sun Jul 21 09:36:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB34120254 for ; Sun, 21 Jul 2019 09:36:47 -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_HELO_NONE=0.001, 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 AXjIbcYQFOC8 for ; Sun, 21 Jul 2019 09:36:46 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 85FD41201A2 for ; Sun, 21 Jul 2019 09:36:45 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id x22so31166171qtp.12 for ; Sun, 21 Jul 2019 09:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:reply-to:mime-version:subject :message-id:date:to; bh=V7LrPaffjjLChORVxnMA3S5e9bHGcmUCrbDLJknykXQ=; b=uT6u01DjKIE8Lzq4EzMcITvItz/oOO7MPuKw/fgQCusxP1yDX1vDlIbCh5EHQhkiKg Sr4ttVxyRBpRy/BpLwEKEIGF/n7aBRZwcnBW57Udj5AnrGaYqYCq1FByz4RfumRrjFNi WAH/Dqf4wgYNT7TZbV4UQeKTAh8KlPw7ncW32a9sg+RJegd5EPfIC9nDO+PF8KOmNCeC WltkD0iy+4Q+MVBWdk2mw2d06Q7KW/ibDQ9FV9tNXo0tUb8xwmniTwYdT0bONHOUnWDR qbVJqpngxk6gLrK7jYyHQSi9afalJM0OQfc4URQhqoDfjMMwcwq5hHAZPkrztYfjklyY DO+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:reply-to :mime-version:subject:message-id:date:to; bh=V7LrPaffjjLChORVxnMA3S5e9bHGcmUCrbDLJknykXQ=; b=OcVHQyrlb2+uk5tZPb23dNNuNhON6DR93cjP+DibGZs0YzLnASzoehzqy748Cttk0d o5FsDNINeEbJKnQfo4m2Z0tuA20bmnDe3/Ax5aAP/4Wk1Gp2CU8Y+dYonL7GRX0Ffykf peTIryoRRzrwXo9DZmvG6nElYBtk2/x3c2pIkrCnmJNwg8UAr2Q5ysYVGi4UPAT6bF1D T/I1iATyVNJI1X/EZ7albSR3+VRmkkMOg7vQuBTeXbA9ccpHVjbkrp8O0+wIcqQh1+we NsbF2R3CQB2lSUPZR3YeILOe86dcjnxTapcMHNen4vrnlhxSTZE+ChuTAR9cxBmm7JAg JheA== X-Gm-Message-State: APjAAAXsMlrQIpwXPJb4h0lhaovoa2naoDppnHrSbmG2B5RWAwef51GB lYzupySccH3+4ygwzVErZhg2ckOyJyM= X-Google-Smtp-Source: APXvYqxRp6CGL/1ASRqC6XYgCWSFBYWQjRGkPTFL6YnOtFafemOAV2DZwUNULv0TCGH4sfIsdZBFlQ== X-Received: by 2002:ac8:43d8:: with SMTP id w24mr46532552qtn.25.1563727004514; Sun, 21 Jul 2019 09:36:44 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:5470:143a:253a:fae? ([2001:67c:1232:144:5470:143a:253a:fae]) by smtp.gmail.com with ESMTPSA id o10sm19695807qti.62.2019.07.21.09.36.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 09:36:44 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: V6Ops Chairs Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\)) Message-Id: Date: Sun, 21 Jul 2019 12:36:43 -0400 To: IPv6 Operations X-Mailer: Apple Mail (2.3566.0.1) Archived-At: Subject: [v6ops] Need a note taker and jabber scribe for v6ops Monday X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 16:36:56 -0000 Let us know, please, if you're willing to help with minutes and/or jabber. From nobody Mon Jul 22 06:45:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDF212027B for ; Mon, 22 Jul 2019 06:45:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=avaya365.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 Q62n7-2MKMKz for ; Mon, 22 Jul 2019 06:45:12 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 0CA5B1201CD for ; Mon, 22 Jul 2019 06:45:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EWAADyvDVd/wUHmMZlHAEBAQQBAQcEA?= =?us-ascii?q?QGBUwcBAQsBgUNQcHIDBDUKhBODRwOEUoksgluXUIEuFIEQAxg8CQEBAQ0BIwo?= =?us-ascii?q?CAQEChD4CF4JNIzQJDgEDAQEBBAEBAQEFAQICaYRlOQwJCIJnTS8KAjABAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAg8pHgEBGAEBAQEDEhE?= =?us-ascii?q?EDQwBASwMCwQCAQgNBAQBAQMCJgICAjAVCAgCBAESCBqDAYFqAx0BAgIKn18Cg?= =?us-ascii?q?QgwiF8BAXB/MxoCgl0BAQWFBhiCEwMGCQGBAigBiEGBf4EeF4FBPiaBMYJMPoJ?= =?us-ascii?q?hBBiBCz4VgnQygiaMAQEHARyCUptvCQKCGYZYgUKJP4JOgi2HJYN5A4o8jTWHS?= =?us-ascii?q?Iw5g08CAgICBAUCDgEBBYFQOYFYcBU7gmyCQoNxilNygSmNUAGBFQsBAQ?= X-IPAS-Result: =?us-ascii?q?A2EWAADyvDVd/wUHmMZlHAEBAQQBAQcEAQGBUwcBAQsBgUN?= =?us-ascii?q?QcHIDBDUKhBODRwOEUoksgluXUIEuFIEQAxg8CQEBAQ0BIwoCAQEChD4CF4JNI?= =?us-ascii?q?zQJDgEDAQEBBAEBAQEFAQICaYRlOQwJCIJnTS8KAjABAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEFAg8pHgEBGAEBAQEDEhEEDQwBASwMCwQCA?= =?us-ascii?q?QgNBAQBAQMCJgICAjAVCAgCBAESCBqDAYFqAx0BAgIKn18CgQgwiF8BAXB/Mxo?= =?us-ascii?q?Cgl0BAQWFBhiCEwMGCQGBAigBiEGBf4EeF4FBPiaBMYJMPoJhBBiBCz4VgnQyg?= =?us-ascii?q?iaMAQEHARyCUptvCQKCGYZYgUKJP4JOgi2HJYN5A4o8jTWHSIw5g08CAgICBAU?= =?us-ascii?q?CDgEBBYFQOYFYcBU7gmyCQoNxilNygSmNUAGBFQsBAQ?= X-IronPort-AV: E=Sophos;i="5.64,295,1559534400"; d="scan'208";a="357470629" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Jul 2019 09:45:10 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2019 09:45:10 -0400 Received: from PWEXCVMAP02.global.avaya.com (135.11.85.81) by AZ-US1EXHC01.global.avaya.com (135.11.85.12) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Jul 2019 09:45:09 -0400 Received: from PWEXCVMAP02.global.avaya.com (135.11.85.81) by PWEXCVMAP02.global.avaya.com (135.11.85.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Mon, 22 Jul 2019 09:45:09 -0400 Received: from PW365VMAP02.avaya.com (135.8.98.110) by PWEXCVMAP02.global.avaya.com (135.11.85.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1531.3 via Frontend Transport; Mon, 22 Jul 2019 09:45:09 -0400 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (104.47.50.50) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Mon, 22 Jul 2019 08:45:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UDZtlR7Wu2xVTlfNjBdyQcj9pL6MtNLLpi3Oo7d0B/AJ2F2YZWTI5AG9hBa4usXrqgtPEQYwUKNdBkmQbyF1Ib8LJf2vYhwxaDMMW43l5w4XaLjKDKd0YVakNJV5yLwqEL+0pMZ3Jev6tiUlbrsUJQBiIlqNoXr8yn1oVuVl1aaJ+fYH2KDs3T/e9Ow8/GxdvWjE+4xoSUaFoNy3sWRXftMFiDN+SXZdwak04b570jXcHqhEKrJ9h/i9U3dRKdhysU9kt/KUjGd0uN7NKKS5eT4YTxnGjCB91tlNeU2s5CMffzGwzw9bpnB2aKJufPckS8ZxqvnjcBIOGrr9/Z8xiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PNQ9Mx5xtCudIxj2Rbfur/u/XfZID7+M69vRSbwTgsc=; b=mfdceH6gK1frbXJOF9zjYhN/uN0YswKU7eCfqCoGAhRT3df+2zXcxfzgoCpsfGo0ugOGsG4hrNUeN7gGD3K3jFc1KzAMWizItPzgab7Ju2zP0yfSQKsxDFVkh84k5UcAmIK+fH8Bq1lIpN4JpUckweg7p8NStzkyht/UP6IhvRtZ2vIOLoYvRAWQUg4V8Em7V4mCOd+y6gVL5tHJdA0oESa4nYOADFTy/gDWzOq8P63L3uzotLWuskcu1eXuXgzZX19eiDM/qv5gfAbcsa3SOmpwXB7z6Vd8sKyN1xMPCU/NcAqAa8EG4dqr4lXUVvOQWM3EyVykfVZuJIc0mCmm8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=avaya.com;dmarc=pass action=none header.from=avaya.com;dkim=pass header.d=avaya.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PNQ9Mx5xtCudIxj2Rbfur/u/XfZID7+M69vRSbwTgsc=; b=et8EI1wFFGi8ekUnNnLa8UOnMFSEc4mzMdWnYGPnbniqZ/zC5l8iHJDzHqQOGtozb/DHo+BkBc49C8dsCy2jGmW5/VI5cwonXadiGUnQisTDE5kmpFFSIt5wrL42lfa+vABygoZZTSd1bZJUnW02ttsIGszp7DRDOxbMYLQo3X0= Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2393.namprd15.prod.outlook.com (20.176.71.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 13:45:07 +0000 Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2094.017; Mon, 22 Jul 2019 13:45:07 +0000 From: "Mudric, Dusan (Dusan)" To: JORDI PALET MARTINEZ , IPv6 Operations Thread-Topic: [v6ops] IPv6-only draft Thread-Index: AQHVPDZ9IJfHmZTVHkuopK5mC67geabSTZIwgAFP8oCAAwcbIA== Date: Mon, 22 Jul 2019 13:45:07 +0000 Message-ID: References: <5694C033-A38F-4455-9673-EACAAC6324F3@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com; x-originating-ip: [104.129.196.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba9b9cfe-f194-464b-2e9d-08d70eaacecf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2393; x-ms-traffictypediagnostic: DM6PR15MB2393: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1201; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(136003)(366004)(346002)(39860400002)(199004)(189003)(13464003)(186003)(6246003)(14444005)(86362001)(26005)(476003)(53936002)(5024004)(19627235002)(11346002)(76176011)(7696005)(6116002)(3846002)(446003)(256004)(966005)(478600001)(2906002)(81166006)(81156014)(486006)(53546011)(6506007)(55236004)(102836004)(14454004)(25786009)(229853002)(68736007)(9686003)(316002)(110136005)(33656002)(71200400001)(8936002)(71190400001)(66066001)(66574012)(99286004)(52536014)(305945005)(7736002)(74316002)(66946007)(66476007)(66556008)(76116006)(8676002)(66446008)(64756008)(6436002)(6306002)(55016002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2393; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5nXnD0czDXLImvfAfvadb2BNPlBV6WVzL3EFVb4ql3Bz6nETzZlQxiUZcPD4HtDaka3Eg5VZkpS4+loiU1DhGSFJ6VtwqXf9oa9TtAlNVfHBfalR+RleY98unVYnMpBVfx0E1Wh5IcROgfzUz/77nyDdV5TnYV3Zpgv/2cRn/c3ElbqYw9dDoqfyfycV11jEHJD4f4z0wyWX13YRxRtjjdkVe3Li5ExxzM7+0OAATXCe/U20SNecCOfcAjgxIkcfeh4loy5ck9g0KAp3iZsFW4L3omkDTZKqz68UzpeA1nvFLZfI/OHYEx9TPnFgwcdf8Ra6PNY9IP47OK/tIX5TeukH6nNoi3AeqVPA5TOrV7EwMKThYuBYPbI7bRfSigy71GIF4xH0IYLFTcRddcPHbu5J2IyXwL0y7jTrjiTWJrE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ba9b9cfe-f194-464b-2e9d-08d70eaacecf X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 13:45:07.1199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2393 X-OriginatorOrg: avaya.com Archived-At: Subject: Re: [v6ops] IPv6-only draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:45:20 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSk9SREkgUEFMRVQgTUFS VElORVogPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0KPiBTZW50OiBTYXR1cmRheSwgSnVs eSAyMCwgMjAxOSAxMDo1NCBBTQ0KPiBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pIDxkbXVkcmlj QGF2YXlhLmNvbT47IElQdjYgT3BlcmF0aW9ucw0KPiA8djZvcHNAaWV0Zi5vcmc+DQo+IFN1Ympl Y3Q6IFJlOiBbdjZvcHNdIElQdjYtb25seSBkcmFmdA0KPiANCj4gSGkgRHVzYW4sDQo+IA0KPiAN Cj4g77u/RWwgMjAvNy8xOSA3OjM1LCAidjZvcHMgZW4gbm9tYnJlIGRlIE11ZHJpYywgRHVzYW4g KER1c2FuKSIgPHY2b3BzLQ0KPiBib3VuY2VzQGlldGYub3JnIGVuIG5vbWJyZSBkZSBkbXVkcmlj QGF2YXlhLmNvbT4gZXNjcmliacOzOg0KPiANCj4gDQo+IA0KPiAgICAgIjMuICBEZWZpbml0aW9u IG9mIElQdjYtb25seQ0KPiANCj4gICAgICAgIENvbnNlcXVlbnRseSwgY29uc2lkZXJpbmcgdGhl IGNvbnRleHQgZGVzY3JpYmVkIGluIHRoZSBzZWN0aW9uIGFib3ZlLA0KPiAgICAgICAgaWYgd2Ug d2FudCB0byBiZSBwcmVjaXNlIGFuZCBhdm9pZCBjb25mdXNpbmcgb3RoZXJzLCB3ZSBjYW4gbm90 IHVzZQ0KPiANCj4gICAgICAgIHRoZSB0ZXJtaW5vbG9neSAiSVB2Ni1vbmx5IiBpbiBhIGdlbmVy aWMgd2F5LCBhbmQgd2UgbmVlZCB0byBkZWZpbmUNCj4gICAgICAgIHdoYXQgcGFydCBvZiB0aGUg bmV0d29yayB3ZSBhcmUgcmVmZXJyaW5nIHRvLg0KPiANCj4gICAgICAgIEZyb20gdGhhdCBwZXJz cGVjdGl2ZSwgd2UgZGVmaW5lIHRoZSAiSVB2Ni1vbmx5IiBzdGF0dXMgaW4gYSBnaXZlbg0KPiAg ICAgICAgcGFydChzKSBvZiBhIG5ldHdvcmssIGRlcGVuZGluZyBvbiBpZiB0aGVyZSBpcyBhY3R1 YWwgbmF0aXZlDQo+ICAgICAgICBmb3J3YXJkaW5nIG9mIElQdjQsIHNvIElQdjQgaXMgbm90IGNv bmZpZ3VyZWQgbmVpdGhlciBtYW5hZ2VkLiINCj4gDQo+ICAgICBUaGUgZG9jdW1lbnQgZGVmaW5l cyBJUHY2LW9ubHkgbm90IG9ubHkgZm9yIHRoZSBuZXR3b3JrIHBhcnRzIGJ1dCBhbHNvIGZvcg0K PiBhIGhvc3Qvcm91dGVyLg0KPiANCj4gLT4gSSBzZWUgdGhpcyBkb2N1bWVudCBhcyB0byBoYXZl IHZpZXcgImVuZC10by1lbmQiLiBTbywgZnJvbSBob3N0IEENCj4gKHNvdXJjZSkgdG8gaG9zdCBC IChkZXN0aW5hdGlvbiksIGlzIGl0IElQdjYtb25seT8gVW5kZXIgdGhhdCBwZXJzcGVjdGl2ZSwg dGhlDQo+IGhvc3RzLCByb3V0ZXJzLCBpbnZvbHZlIGluIHRoYXQgZW5kLXRvLWVuZCBjb21tdW5p Y2F0aW9uLCBhcmUgYWxzbyBwYXJ0IG9mDQo+IHRoZSBuZXR3b3JrLiBJZiB0aGlzIGlzIG5vdCBj bGVhciwgSSBjb3VsZCBleHBhbmQgdGhlIHRleHQgb24gdGhpcyBzZWN0aW9uIHRvDQo+IGNsYXJp ZnkgdGhhdC4gRG8geW91IGhhdmUgYW55IHN1Z2dlc3RlZCB3b3JkaW5nPw0KW0R1c2FuXSBQbGVh c2UgcmV2aXNlIHRoaXMgc3VnZ2VzdGlvbjoNCiAgICAgICAgRnJvbSB0aGF0IHBlcnNwZWN0aXZl LCB3ZSBkZWZpbmUgdGhlICJJUHY2LW9ubHkiIHNlcnZpY2UgYXMgYSB1c2FnZSBvZiANCiAgICAg ICAgSVB2NiBhZGRyZXNzIGZhbWlseSB0aHJvdWdob3V0IHRoZSBlbmQtdG8tZW5kIHBhdGhzIGJl dHdlZW4gdGhlIGFwcGxpY2F0aW9ucy4NCiAgICAgICAgQm90aCAgdGhlIGFwcGxpY2F0aW9ucyBh bmQgdGhlIHVuZGVybGluZWQgbmV0d29yayB0cmFuc3BvcnQgdXNlIG9ubHkgSVB2NiBpbmZyYXN0 cnVjdHVyZS4NCg0KPiANCj4gICAgICI3LiAgSVB2Ni1vbmx5IFdBTi9hY2Nlc3MNCj4gDQo+ICAg ICAgICBJUHY2LW9ubHkgV0FOIG9yIGFjY2VzcyBjYW4gYmUgdXNlZCBvbmx5IGlmIHRoZSBXQU4g b3IgYWNjZXNzIG5ldHdvcmsNCj4gICAgICAgIGlzbid0IGFjdHVhbGx5IG5hdGl2ZWx5IGZvcndh cmRpbmcgSVB2NC4iDQo+IA0KPiAgICAgU2hvdWxkIHVzZSBhZmZpcm1hdGl2ZSBraW5kIG9mIGRl ZmluaXRpb25zIGZvciBJUHY2LW9ubHksIG5vdCBvbmx5IGhlcmUgYnV0DQo+IGFsc28gaW4gb3Ro ZXIgc2VjdGlvbnMuIEluc3RlYWQgb2YgImlzbid0IGFjdHVhbGx5IG5hdGl2ZWx5IGZvcndhcmRp bmcgSVB2NCINCj4gc2hvdWxkIGRlZmluZSB3aGF0IGl0IElTIGZvcndhcmRpbmcsIGxpa2UgImlz IG5hdGl2ZWx5IGZvcndhcmRpbmcgSVB2NiIuDQo+IA0KPiAtPiBJIHRoaW5rIGl0IGlzIGNsZWFy ZXIgd2l0aCB0aGUgbmVnYXRpdmUgZm9ybSwgdW5sZXNzIHRoaXMgaXMgaW5jb3JyZWN0IGluDQo+ IEVuZ2xpc2g/IEknbSBub3QgbmF0aXZlIHNwZWFrZXIuIElmIEkgdXNlIGFmZmlybWF0aXZlIGl0 IGdldHMgbW9yZSBjb21wbGV4Og0KPiAiaXNuJ3QgYWN0dWFsbHkgbmF0aXZlbHkgZm9yd2FyZGlu ZyBJUHY0Ig0KPiB2cw0KPiAiaXMgYWN0dWFsbHkgZm9yd2FyZGluZyBuYXRpdmVseSBJUHY2IGFu ZCBub3QgbmF0aXZlbHkgSVB2NCINCltEdXNhbl0gU2F5aW5nIHdoYXQgaXQgaXMgbm90LCBvcGVu cyBhIGJyb3RoZXIgc3BhY2UgZm9yIHdoYXQgaXQgaXMuIElmIGl0IGlzIG5vdCBJUHY0LCBpdCBt aWdodCBiZSBJUHY2IG9yIElQdjEwLg0KDQo+IA0KPiAgICAgIjEwLiAgVHJhbnNpdGlvbmFsIElQ djYgaG9zdC9yb3V0ZXINCj4gDQo+ICAgICAgICBUcmFuc2l0aW9uYWwgSVB2NiBob3N0L3JvdXRl ciBpcyBhIGR1YWwtc3RhY2sgaG9zdC9yb3V0ZXIgd2l0aA0KPiAgICAgICAgSVB2Ni1vbmx5IFdB TiB3aGVyZSBJUHY0IHNlcnZpY2Ugc3VwcG9ydCBpcyBwcm92aWRlZCBieSBtZWFucyBvZg0KPiAg ICAgICAgdHJhbnNpdGlvbiBtZWNoYW5pc20sIElQdjRhYVMgKElQdjQtYXMtYS1zZXJ2aWNlKS4i DQo+IA0KPiAtPiBub3Qgc3VyZSB3aGF0IGlzIHRoZSBpbnB1dCBoZXJlPw0KPiANCj4gICAgIER1 c2FuDQo+IA0KPiAgICAgV2h5IGlzIGl0IGltcG9ydGFudCB0byBtZW50aW9uIFdBTiBhZGRyZXNz IGZhbWlseT8gV2h5IFdBTiBtdXN0IGJlDQo+IElQdjYtb25seT8NCj4gDQo+IC0+IEJlY2F1c2Ug dGhlIGZ1bGwgcmVhc29uIG9yICJzdGFydGluZy1wb2ludCIgb2YgdGhlIGRvY3VtZW50IGlzIHRo ZSBJUHY2LQ0KPiBvbmx5IHRlcm1pbm9sb2d5IGNsYXJpZmljYXRpb24uDQpbRHVzYW5dIFRoZW4g dGhlcmUgc2hvdWxkIGJlIHR3byBkZWZpbml0aW9ucywgb25lIGZvciBob3N0cy9yb3V0ZXJzIGFu ZCBhbm90aGVyIGZvciBXQU4uIEhvc3RzIGFuZCByb3V0ZXJzIGNhbiBydW4gYXBwbGljYXRpb25z IHRoYXQgYXJlIG5vdCByZWxhdGVkIHRvIHRyYW5zcG9ydC9mb3J3YXJkaW5nLiBUaGVzZSBhcHBs aWNhdGlvbnMgc2hvdWxkIHVzZSBJUHY2LW9ubHkgYWRkcmVzcyBmYW1pbHkgYW5kIEFQSXMgdGhh dCBwcm92aWRlIElQdjYtb25seSBmdW5jdGlvbmFsaXR5LiBSb3V0ZXJzIHNob3VsZCByb3V0ZSBJ UHY2LW9ubHkgcGFja2V0cy4NCg0KPiANCj4gDQo+ICAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ICAgICA+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgRnJlZCBCYWtlcg0KPiAgICAgPiBTZW50OiBUdWVzZGF5LCBKdWx5IDE2LCAyMDE5 IDg6MjcgUE0NCj4gICAgID4gVG86IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+DQo+ ICAgICA+IFN1YmplY3Q6IFt2Nm9wc10gSVB2Ni1vbmx5IGRyYWZ0DQo+ICAgICA+DQo+ICAgICA+ IFRoZSBhdXRob3IgaXMgYXNraW5nIGZvciB0aW1lIG9uIHRoZSBhZ2VuZGEgYXQgSUVURiAxMDU7 IEkgdG9sZCBoaW0gdGhhdCBpZg0KPiB0aGVyZQ0KPiAgICAgPiB3YXMgdGltZSBhdCB0aGUgZW5k IG9mIHRoZSBtZWV0aW5nLCBpdCBjb3VsZCBiZSBwYXJ0IG9mICJBT0IiLiBJIGRvbid0IHNlZQ0K PiBhbnkNCj4gICAgID4gZGlzY3Vzc2lvbiBvbiB0aGUgZHJhZnQgc2luY2UgTm92ZW1iZXIgMjAx Ny4NCj4gICAgID4NCj4gICAgID4gRllJLCBkcmFmdC1pZXRmLTZtYW4taXB2Nm9ubHktZmxhZyBp cyBhIGRpZmZlcmVudCB0b3BpYy4NCj4gICAgID4NCj4gICAgID4gaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAgICAgPiAzQV9fdG9vbHMuaWV0Zi5v cmdfaHRtbF9kcmFmdC0yRHBhbGV0LTJEdjZvcHMtMkRpcHY2LQ0KPiAgICAgPg0KPiAyRG9ubHkm ZD1Ed0lDQWcmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmgN Cj4gICAgID4gSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT0xbkF0NzhuZWZUei1wX2FpV0NyY2c1 WUFlczFaLQ0KPiAgICAgPg0KPiBFMUJKbXMwV3VITE0yTSZzPVVOa0lqTHMyRzVPbnZ4RHlvU3l5 c1FQV1lUWXJrOXdUZmFkbW5ucjU3a2cNCj4gICAgID4gJmU9DQo+ICAgICA+IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gICAgID4gM0FfX21haWxh cmNoaXZlLmlldGYub3JnX2FyY2hfc2VhcmNoXy0zRnFkci0zRGEtMjZxLTNELTI1MjJkcmFmdC0N Cj4gICAgID4gMkRwYWxldC0yRHY2b3BzLTJEaXB2Ni0yRG9ubHktDQo+ICAgICA+DQo+IDI1MjIm ZD1Ed0lDQWcmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJ bw0KPiAgICAgPiBVV0I4WUxaVTIzMDI5c01RR1Eya1kmbT0xbkF0NzhuZWZUei1wX2FpV0NyY2c1 WUFlczFaLQ0KPiAgICAgPg0KPiBFMUJKbXMwV3VITE0yTSZzPUUxbV9xSG43UnNSa3RtaEYwN05m OWVhbnpnR210TlA3bFEyOUt5cjVzdQ0KPiAgICAgPiBFJmU9DQo+ICAgICA+DQo+ICAgICA+IFlv dXIgY29tbWVudHMgYXBwcmVjaWF0ZWQuDQo+ICAgICA+DQo+ICAgICA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ICAgICA+IFRoZSBmYWN0IHRoYXQgdGhlcmUgaXMgYSBoaWdod2F5IHRvIGhl bGwgYW5kIGEgc3RhaXJ3YXkgdG8gaGVhdmVuIGlzIGFuDQo+ICAgICA+IGludGVyZXN0aW5nIGNv bW1lbnQgb24gcHJvamVjdGVkIHRyYWZmaWMgdm9sdW1lLi4uDQo+ICAgICA+DQo+ICAgICA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICA+IHY2 b3BzIG1haWxpbmcgbGlzdA0KPiAgICAgPiB2Nm9wc0BpZXRmLm9yZw0KPiAgICAgPiBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ICAgICA+DQo+IDNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192Nm9wcyZkPUR3SUNBZyZjPUJGcFdRdzhi c3VLcGwNCj4gICAgID4NCj4gMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZ TFpVMjMwMjlzTVFHUTJrWSZtPTFuQXQNCj4gICAgID4gNzhuZWZUei1wX2FpV0NyY2c1WUFlczFa LUUxQkptczBXdUhMTTJNJnM9NTk1bC0NCj4gICAgID4gUnNDeXVfMG1QT0h0WjB1ZWN1cmVTYUJZ TDNqYUZqQzlPMXhBd1kmZT0NCj4gDQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+ICAgICB2Nm9w c0BpZXRmLm9yZw0KPiAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1E d0lGYVEmYz1CRnBXUXc4YnN1S3BsDQo+IDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3Jo SW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1uVmkxDQo+IGt4Q3hGZGxCMUYyenB6N0JvNkFPa0FX dU40ZFhBR1ZkYVF2YzhkVSZzPVJhMEJpXzdCYjRCbF9IV2VuDQo+IFcxbjFoWHYtb1Bqd3ZqMnBo TnN2b0xWd0IwJmU9DQo+IA0KPiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZv ciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtDQo+IDNBX193d3cudGhlaXB2NmNvbXBhbnkuY29tJmQ9RHdJRmFRJmM9 QkZwV1F3OGJzdUtwbDFTZ2laSDY0UQ0KPiAmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlM WlUyMzAyOXNNUUdRMmtZJm09blZpMWt4Q3hGZGxCMQ0KPiBGMnpwejdCbzZBT2tBV3VONGRYQUdW ZGFRdmM4ZFUmcz1VN19yTHRHUVUzT0RQNlp6dHZPYnJSdkFpSVMNCj4gYXFVSnZ3YnplYzVobXpo byZlPQ0KPiBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBj b250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvcg0KPiBjb25maWRl bnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9u LWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLA0KPiBjb3B5aW5nLCBkaXN0cmlidXRp b24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmDQo+ IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYQ0KPiBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55DQo+IGRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMgaW5mb3JtYXRpb24sDQo+IGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQg ZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUNCj4gY29uc2lkZXJlZCBhIGNy aW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIg dG8NCj4gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiAN Cj4gDQoNCg== From nobody Mon Jul 22 14:37:34 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E541200B6 for ; Mon, 22 Jul 2019 14:37:33 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWdbRKdtsAyA for ; Mon, 22 Jul 2019 14:37:31 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 C575112001B for ; Mon, 22 Jul 2019 14:37:30 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from ) id 1hpfzr-0003L6-2U for v6ops@ietf.org; Mon, 22 Jul 2019 23:37:28 +0200 Date: Mon, 22 Jul 2019 23:37:27 +0200 From: David Lamparter To: IPv6 Operations Message-ID: <20190722213727.GI34551@eidolon.nox.tf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:37:33 -0000 Hi all, to clarify and document the point I made on the mic a few minutes ago: I'm generating a privacy address. I do DAD for it, and I send it to, say, ff02::1:ffc6:3a4b. On shitty networks, this will be a broadcast, so everyone knows the address I'm using and can associate the MAC. But on non-shitty networks, it doesn't go anywhere because no one is interested in that particular group. I really don't want to suggest advertising privacy addrs to ff02::1. Yes, the privacy might already be broken due to nonexistent multicast filtering, but it's not broken by design. Broadcasting it to ff02::1 breaks it by design. ff02::2 has the problem Lorenzo mentioned with battery lifetimes. It might be broken in practice, but would work in theory, if you had proper multicast filtering everywhere. That might not even be the device's wifi chip firmware, it could also be in APs. I feel some strong deja vu here from 802.11 multicast discussions. The third option is for the router to pick up all DAD groups. It certainly won't report /ALL/ DAD groups in MLD, so this would break if you have MLD-snooping switches... unless you configure multicast routing properly with "all multicast on router ports". Is there another choice? How about ff02::16 (All MLDv2-capable routers)? -David From nobody Mon Jul 22 16:13:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A01F120048 for ; Mon, 22 Jul 2019 16:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 iiRdiIlCt5DW for ; Mon, 22 Jul 2019 16:13:31 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 A3F16120045 for ; Mon, 22 Jul 2019 16:13:31 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id r21so36038739otq.6 for ; Mon, 22 Jul 2019 16:13:31 -0700 (PDT) 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=gfj4clfQIFMAHT6V6/WuoYlGABMTDfhxqjoGE5meSn0=; b=b+iXKwA1+TrWX15g09J7AAAACplZC7I2WLB923nwezy5Szjoj6K8Z8kyOqy+O/iyfU x26dxpKXxrR3BlG+rfLXgPaVG1Tj1TJMXn8O0qItCTlSI9InHypBSlk7MB+kwURAi5cj zT/SO+jwxQWS+mAOX0SHV9pfqYRqozaIqQ4CqM5gGDK4ywZiBowEASc1hqM3uu7HimRX 7+eKeHPhYFJG08m2VNADFwGdsUI3YtziUTG5ELvZBkqS1TnvFhVS8vOC1yqWIWnIqCkQ JKvIIIk8KR8vtBTLuW1O5IgEK7sxxT2F1GOpVr8gKuAOwlnuCX9huz8PoSs4I96Msvbo 9lSQ== 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=gfj4clfQIFMAHT6V6/WuoYlGABMTDfhxqjoGE5meSn0=; b=MS84WrCEucEY6g/HOEZTYsZ2xxF/lOUNKy03zZdBOtvOaP/6adNHwPyrkb5JZveTi2 6YHjPhZiRVIVcJb8Q2Qj1wRAn2RtlAUN8xlRl5xwcQAorX/zhSMYeP1nh1aBXLi6V+L/ iyRfiF+xBAkprw9lGOUsjPht4VIrDfyHup8r5+GhYgxHriqlisidzsOYTa84qYybHbN0 ZVFWACUn1zCPG7oNZhXCZEgGbl5kAclKquZbpYHy0sUEFFz630a3C0ezRzrmGKHPGFN8 W8dEuwAU30C5VQ48Qmshza0yjQO6IeTqtLNjph4huDV5LNufX0fEGfHbBdVRLq2GRsy3 pCtA== X-Gm-Message-State: APjAAAXIo/QUjchcXfkvrlIUCfiO+1ztVjAjoFDD+yYAk16v1T53j/+5 Jom6LuhaWEBkIV942LlWBwJFrMjgwvwhZimKmwp9mQ== X-Google-Smtp-Source: APXvYqz+xKRJQirtP+z9Fw0chpNMMuIb+nZtC5PFoA5hmgED6C/2AS0RFTPinQ8Ztq18DHVmgqYqA2LlMJKvybO3oHI= X-Received: by 2002:a9d:65da:: with SMTP id z26mr43491158oth.257.1563837211008; Mon, 22 Jul 2019 16:13:31 -0700 (PDT) MIME-Version: 1.0 References: <20190722213727.GI34551@eidolon.nox.tf> In-Reply-To: <20190722213727.GI34551@eidolon.nox.tf> From: Mark Smith Date: Tue, 23 Jul 2019 09:13:19 +1000 Message-ID: To: David Lamparter Cc: v6ops list Content-Type: multipart/alternative; boundary="00000000000072e26b058e4d39a8" Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:13:33 -0000 --00000000000072e26b058e4d39a8 Content-Type: text/plain; charset="UTF-8" On Tue., 23 Jul. 2019, 07:37 David Lamparter, wrote: > Hi all, > > > to clarify and document the point I made on the mic a few minutes ago: > > I'm generating a privacy address. I do DAD for it, and I send it to, > say, ff02::1:ffc6:3a4b. On shitty networks, this will be a broadcast, > so everyone knows the address I'm using and can associate the MAC. But > on non-shitty networks, it doesn't go anywhere because no one is > interested in that particular group. > > I really don't want to suggest advertising privacy addrs to ff02::1. > Yes, the privacy might already be broken due to nonexistent multicast > filtering, but it's not broken by design. Broadcasting it to ff02::1 > breaks it by design. > > ff02::2 has the problem Lorenzo mentioned with battery lifetimes. It > might be broken in practice, but would work in theory, if you had proper > multicast filtering everywhere. That might not even be the device's > wifi chip firmware, it could also be in APs. I feel some strong deja vu > here from 802.11 multicast discussions. > > The third option is for the router to pick up all DAD groups. It > certainly won't report /ALL/ DAD groups in MLD, so this would break if > you have MLD-snooping switches... unless you configure multicast routing > properly with "all multicast on router ports". > > Is there another choice? How about ff02::16 (All MLDv2-capable routers)? > Why not have routers on the link learn of a node's link-local address via source addresses of the node's RSes and MLDv2 joins, and then have the routers query the node via unicast for all its other addresses. There's already two ways the unicast query could be supported to collect the node's other addresses, via ICMPv6 Node Information queries (RFC 4620) , or Inverse ND (RFC 3122). Regards, Mark. > > -David > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000072e26b058e4d39a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue., 23 Jul. 2019, 07:37 David Lamparter, <equinox@diac24.net&g= t; wrote:
Hi all,


to clarify and document the point I made on the mic a few minutes ago:

I'm generating a privacy address.=C2=A0 I do DAD for it, and I send it = to,
say, ff02::1:ffc6:3a4b.=C2=A0 On shitty networks, this will be a broadcast,=
so everyone knows the address I'm using and can associate the MAC.=C2= =A0 But
on non-shitty networks, it doesn't go anywhere because no one is
interested in that particular group.

I really don't want to suggest advertising privacy addrs to ff02::1. Yes, the privacy might already be broken due to nonexistent multicast
filtering, but it's not broken by design.=C2=A0 Broadcasting it to ff02= ::1
breaks it by design.

ff02::2 has the problem Lorenzo mentioned with battery lifetimes.=C2=A0 It<= br> might be broken in practice, but would work in theory, if you had proper multicast filtering everywhere.=C2=A0 That might not even be the device'= ;s
wifi chip firmware, it could also be in APs.=C2=A0 I feel some strong deja = vu
here from 802.11 multicast discussions.

The third option is for the router to pick up all DAD groups.=C2=A0 It
certainly won't report /ALL/ DAD groups in MLD, so this would break if<= br> you have MLD-snooping switches... unless you configure multicast routing properly with "all multicast on router ports".

Is there another choice? How about ff02::16 (All MLDv2-capable routers)?

Why= not have routers on the link learn of a node's link-local address via = source addresses of the node's RSes and MLDv2 joins, and then have the = routers query the node via unicast for all its other addresses.

There's already two ways the un= icast query could be supported to collect the node's other addresses, v= ia ICMPv6 Node Information queries (RFC 4620) , or Inverse ND (RFC 3122).

Regards,
Mark.


<= div dir=3D"auto">


-David

_______________________________________________
v6ops mailing list
v6ops@ietf.or= g
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000072e26b058e4d39a8-- From nobody Mon Jul 22 17:00:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35472120094 for ; Mon, 22 Jul 2019 17:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 k0PKofWWasLp for ; Mon, 22 Jul 2019 17:00:53 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 B32AA120045 for ; Mon, 22 Jul 2019 17:00:53 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from ) id 1hpiEb-000lIn-RB; Tue, 23 Jul 2019 02:00:50 +0200 Date: Tue, 23 Jul 2019 02:00:49 +0200 From: David Lamparter To: Mark Smith Cc: v6ops list Message-ID: <20190723000049.GJ34551@eidolon.nox.tf> References: <20190722213727.GI34551@eidolon.nox.tf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 00:00:56 -0000 On Tue, Jul 23, 2019 at 09:13:19AM +1000, Mark Smith wrote: > On Tue., 23 Jul. 2019, 07:37 David Lamparter, wrote: > > I'm generating a privacy address. I do DAD for it, and I send it to, > > say, ff02::1:ffc6:3a4b. On shitty networks, this will be a broadcast, > > so everyone knows the address I'm using and can associate the MAC. But > > on non-shitty networks, it doesn't go anywhere because no one is > > interested in that particular group. [...] > > The third option is for the router to pick up all DAD groups. It > > certainly won't report /ALL/ DAD groups in MLD, so this would break if > > you have MLD-snooping switches... unless you configure multicast routing > > properly with "all multicast on router ports". > > > > Is there another choice? How about ff02::16 (All MLDv2-capable routers)? > > > > Why not have routers on the link learn of a node's link-local address via > source addresses of the node's RSes and MLDv2 joins, and then have the > routers query the node via unicast for all its other addresses. Neither of these contains the global address(es) that a host generated, so you would need... > There's already two ways the unicast query could be supported to collect > the node's other addresses, via ICMPv6 Node Information queries (RFC 4620) > , or Inverse ND (RFC 3122). ... either of these options, which I strongly hope no one implements because then I can just chuck all my privacy considerations straight out the window... (Coincidentally, I'm pretty sure most hosts won't respond to either of these two.) I'm tentatively in the DAD snooping camp, but this is a tricky problem. My decision tree for DAD is this: 1. do you have a network with multicast snooping / limited multicast propagation? => No: your router sees all DAD anyway, but also your privacy is already f*cked from the DADs you sent. Either way we're not making it worse by picking the DADs up on the router. End tree. => Yes: it seems someone configured multicast. (You don't get this without config, it's a bit of a PITA honestly.) Proceed to 2. 2. is whoever configured multicast competent? => No: you're screwed already because broken multicast is broken DAD. So if not all DAD makes it to the router, some or all clients will experience connectivity delays. ff02::1 or ff02::2 could /lessen/ these issues, but they come with their own bag of troubles and your broken multicast setup might be messing with them anyway. => Yes: the competent person needs to understand that unicast routers need to receive all multicast traffic in order to catch and snoop DAD. Set the "multicast router present" bits on the appropriate ports on your L2 devices and you're golden. Also, this is the only scenario where some measure of address privacy can be provided, since this is the only scenario in which DAD wouldn't turn into a broadcast, and it remains so even with the router picking up all DAD. -David From nobody Mon Jul 22 17:34:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06181200BA for ; Mon, 22 Jul 2019 17:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 U_rgGijosieh for ; Mon, 22 Jul 2019 17:34:18 -0700 (PDT) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 A116C120045 for ; Mon, 22 Jul 2019 17:34:18 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id 60so2697366otr.7 for ; Mon, 22 Jul 2019 17:34:18 -0700 (PDT) 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=e486O7rj1rKdG/18iipGxVRFsPyMDCIVKdJhIjv6Rjk=; b=K99VTa1pPbY/nQrWEQ41qYA+RvjBCMvJonSMIkOcBRZXbJ4M2w6K5NPMdRR1+lFBNX 9WJ15G0wjBRI7haEiTyTpjO6ahxU84Pm/a4sgRhxMI+LaE1i53CJjnEVTiPRUHZpKQqm +0UZl8ZuWpBc9cQFDUbO/sRin7xs5tRJkBlt57aNK70VhNadgbJB4IwFsQSPEO2WmIb+ 4Zn7am9dhITcx+bj2q6r24+1kmaKKrxcszDpvdRVgGC5pnu9ridu8cPukqRarWB5NTIT eTd+nKYrrgnHkE1efprsv8zZkAfCnJlgWzf3Zo4gAnxdoL1Dst777c2UZnQO+NX/Q6b5 j06A== 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=e486O7rj1rKdG/18iipGxVRFsPyMDCIVKdJhIjv6Rjk=; b=IwTLt8vYfSxHFjTC5lCXZBMAaie1bCNDg5QQ3CQnWPJvEY9zyC5LPinln16+5Gd/Mi jiEuKHKEtpIFtPzhOSzkxrJ/+5pPMHEHOPJFxF+c14n+OGvfECoGaklqbe4TTpeWWi5U LU7ufXlbl8LX/WcQcQ/MtBTqjX6CIJQh9pxYPdszHCPDJPi4hAOSNVJWbiadMf5RjF/I biGtdxJo/Jyw1QQ72hIs6pKyjiGWfcdR/PfFtnA3VCKzorQu9sCMKnzKLKBnaZ6N8h8L 4byZwa9q0NP6UMZc1N2ffvkq/hLy0cgCVwc5g5XNcfhT0mvwvngRJ0k1kf7jLcSsIlI5 qB7w== X-Gm-Message-State: APjAAAU7LYK2yL2uRE9l4l/25LL+u4nWP9x2lQq/5Uqwp7wLUF7KaqlR hnMFl2q2GDb5hds6bBoupvbU7XDdnsxY3G39grfsDA== X-Google-Smtp-Source: APXvYqwWwSBIrBbnLjTCZgsO079EFtelKVC2usfwXQOeFUdIDkDX0lrBMlnsnFMuY6ZcDuTBSr7+/dDwmmGNq7AF+Qc= X-Received: by 2002:a9d:65da:: with SMTP id z26mr43714903oth.257.1563842056893; Mon, 22 Jul 2019 17:34:16 -0700 (PDT) MIME-Version: 1.0 References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> In-Reply-To: <20190723000049.GJ34551@eidolon.nox.tf> From: Mark Smith Date: Tue, 23 Jul 2019 10:34:05 +1000 Message-ID: To: David Lamparter Cc: v6ops list Content-Type: multipart/alternative; boundary="000000000000493a0a058e4e5a2d" Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 00:34:21 -0000 --000000000000493a0a058e4e5a2d Content-Type: text/plain; charset="UTF-8" On Tue., 23 Jul. 2019, 10:00 David Lamparter, wrote: > On Tue, Jul 23, 2019 at 09:13:19AM +1000, Mark Smith wrote: > > On Tue., 23 Jul. 2019, 07:37 David Lamparter, > wrote: > > > I'm generating a privacy address. I do DAD for it, and I send it to, > > > say, ff02::1:ffc6:3a4b. On shitty networks, this will be a broadcast, > > > so everyone knows the address I'm using and can associate the MAC. But > > > on non-shitty networks, it doesn't go anywhere because no one is > > > interested in that particular group. > [...] > > > The third option is for the router to pick up all DAD groups. It > > > certainly won't report /ALL/ DAD groups in MLD, so this would break if > > > you have MLD-snooping switches... unless you configure multicast > routing > > > properly with "all multicast on router ports". > > > > > > Is there another choice? How about ff02::16 (All MLDv2-capable > routers)? > > > > > > > Why not have routers on the link learn of a node's link-local address via > > source addresses of the node's RSes and MLDv2 joins, and then have the > > routers query the node via unicast for all its other addresses. > > Neither of these contains the global address(es) that a host generated, > so you would need... > > > There's already two ways the unicast query could be supported to collect > > the node's other addresses, via ICMPv6 Node Information queries (RFC > 4620) > > , or Inverse ND (RFC 3122). > > ... either of these options, which I strongly hope no one implements > because then I can just chuck all my privacy considerations straight out > the window... > If that's enough of a concern to you, them you must isolate your hosts to their own individual links, virtual or physical, so the only other devices on the link is one or more trusted routers. You can't attach a set of untrustworthy hosts to a mutual trust, multi-access link and then trust those hosts to always behave. The explicit point of those types of links is to be able to send anything to anyone. > (Coincidentally, I'm pretty sure most hosts won't respond to either of > these two.) > We invent the future here. However, I have some small distant evidence that Mac OS X already does, because it sends MLDv2 joins for the NI multicast group. (I don't have access to OS X to further look, and it wasn't something I was looking into at the time.) There's already a BSD/Linux NI implementation available. The out of the box version of 'ping' that comes with Fedora 30 can send NI queries. So we're not talking about 'from scratch' implementation, or complete replacement of ND. There would need to be a transition mechanism and period for hosts that don't support these queries. That's no different to any other solution that requires changes to either or both host and router behaviour. > > > I'm tentatively in the DAD snooping camp, but this is a tricky problem. > My decision tree for DAD is this: > DAD doesn't occur with anycast addresses, do it isn't a complete solution. I'm pretty sure Ericsson have IPR for that idea, because it came up with the discussion of this draft. Not that IPR is a reason not to use the idea, however I think it is better to avoid it, combined with not supporting onlink anycast addresses. Triggering ND Address Resolution on Receiving DAD-NS https://tools.ietf.org/id/draft-halpern-6man-nd-pre-resolve-addr-00.txt > 1. do you have a network with multicast snooping / limited multicast > propagation? > > => No: your router sees all DAD anyway, but also your privacy is already > f*cked from the DADs you sent. Either way we're not making it worse > by picking the DADs up on the router. End tree. > > => Yes: it seems someone configured multicast. (You don't get this > without config, it's a bit of a PITA honestly.) Proceed to 2. > > 2. is whoever configured multicast competent? > > => No: you're screwed already because broken multicast is broken DAD. > So if not all DAD makes it to the router, some or all clients will > experience connectivity delays. ff02::1 or ff02::2 could /lessen/ > these issues, but they come with their own bag of troubles and your > broken multicast setup might be messing with them anyway. > > => Yes: the competent person needs to understand that unicast routers > need to receive all multicast traffic in order to catch and snoop > DAD. Set the "multicast router present" bits on the appropriate > ports on your L2 devices and you're golden. Also, this is the only > scenario where some measure of address privacy can be provided, since > this is the only scenario in which DAD wouldn't turn into a > broadcast, and it remains so even with the router picking up all DAD. > > > -David > --000000000000493a0a058e4e5a2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue., 23 Jul. 2019, 10:00 David Lamparter, <equinox@diac24.net> wrote:
On Tue, Jul 23, 2019 at 09:13:19AM +1000, Mark = Smith wrote:
> On Tue., 23 Jul. 2019, 07:37 David Lamparter, <equinox@diac24.net> wrote:
> > I'm generating a privacy address.=C2=A0 I do DAD for it, and = I send it to,
> > say, ff02::1:ffc6:3a4b.=C2=A0 On shitty networks, this will be a = broadcast,
> > so everyone knows the address I'm using and can associate the= MAC.=C2=A0 But
> > on non-shitty networks, it doesn't go anywhere because no one= is
> > interested in that particular group.
[...]
> > The third option is for the router to pick up all DAD groups.=C2= =A0 It
> > certainly won't report /ALL/ DAD groups in MLD, so this would= break if
> > you have MLD-snooping switches... unless you configure multicast = routing
> > properly with "all multicast on router ports".
> >
> > Is there another choice? How about ff02::16 (All MLDv2-capable ro= uters)?
> >
>
> Why not have routers on the link learn of a node's link-local addr= ess via
> source addresses of the node's RSes and MLDv2 joins, and then have= the
> routers query the node via unicast for all its other addresses.

Neither of these contains the global address(es) that a host generated,
so you would need...

> There's already two ways the unicast query could be supported to c= ollect
> the node's other addresses, via ICMPv6 Node Information queries (R= FC 4620)
> , or Inverse ND (RFC 3122).

... either of these options, which I strongly hope no one implements
because then I can just chuck all my privacy considerations straight out the window...

If that's enough of a concern to you, them you must isolat= e your hosts to their own individual links, virtual or physical, so the onl= y other devices on the link is one or more trusted routers.

You can't attach a set of untrust= worthy hosts to a mutual trust, multi-access link and then trust those host= s to always behave. The explicit point of those types of links is to be abl= e to send anything to anyone.



(Coincidentally, I'm pretty sure most hosts won't respond to either= of
these two.)

We invent the future here.

However, I have some small distant evidence that Mac OS X alr= eady does, because it sends MLDv2 joins for the NI multicast group. (I don&= #39;t have access to OS X to further look, and it wasn't something I wa= s looking into at the time.)

There's already a BSD/Linux NI implementation available. The out o= f the box version of 'ping' that comes with Fedora 30 can send NI q= ueries.

So we're not= talking about 'from scratch' implementation, or complete replaceme= nt of ND.

There would ne= ed to be a transition mechanism and period for hosts that don't support= these queries. That's no different to any other solution that requires= changes to either or both host and router behaviour.=C2=A0





I'm tentatively in the DAD snooping camp, but this is a tricky problem.=
My decision tree for DAD is this:

DAD doesn't occur with anycast address= es, do it isn't a complete solution.

<= div dir=3D"auto">I'm pretty sure Ericsson have IPR for that idea, becau= se it came up with the discussion of this draft.
Not that IPR is a reason not to use the idea, howe= ver I think it is better to avoid it, combined with not supporting onlink a= nycast addresses.

Triggering ND Address Resolution on Receiving=
 DAD-NS
https://tools.ietf.org/id/draft-halpern-6man-nd-p=
re-resolve-addr-00.txt




1. do you have a network with multicast snooping / limited multicast
=C2=A0 =C2=A0propagation?

=3D> No: your router sees all DAD anyway, but also your privacy is alrea= dy
=C2=A0 =C2=A0f*cked from the DADs you sent.=C2=A0 Either way we're not = making it worse
=C2=A0 =C2=A0by picking the DADs up on the router.=C2=A0 End tree.

=3D> Yes: it seems someone configured multicast.=C2=A0 (You don't ge= t this
=C2=A0 =C2=A0without config, it's a bit of a PITA honestly.)=C2=A0 Proc= eed to 2.

2. is whoever configured multicast competent?

=3D> No: you're screwed already because broken multicast is broken D= AD.
=C2=A0 =C2=A0So if not all DAD makes it to the router, some or all clients = will
=C2=A0 =C2=A0experience connectivity delays.=C2=A0 ff02::1 or ff02::2 could= /lessen/
=C2=A0 =C2=A0these issues, but they come with their own bag of troubles and= your
=C2=A0 =C2=A0broken multicast setup might be messing with them anyway.

=3D> Yes: the competent person needs to understand that unicast routers<= br> =C2=A0 =C2=A0need to receive all multicast traffic in order to catch and sn= oop
=C2=A0 =C2=A0DAD.=C2=A0 Set the "multicast router present" bits o= n the appropriate
=C2=A0 =C2=A0ports on your L2 devices and you're golden.=C2=A0 Also, th= is is the only
=C2=A0 =C2=A0scenario where some measure of address privacy can be provided= , since
=C2=A0 =C2=A0this is the only scenario in which DAD wouldn't turn into = a
=C2=A0 =C2=A0broadcast, and it remains so even with the router picking up a= ll DAD.


-David
--000000000000493a0a058e4e5a2d-- From nobody Tue Jul 23 00:01:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594DE12007A for ; Tue, 23 Jul 2019 00:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 CLcdKNsESxhx for ; Tue, 23 Jul 2019 00:01:45 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1376912004C for ; Tue, 23 Jul 2019 00:01:44 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 16CF242298 for ; Tue, 23 Jul 2019 09:01:42 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0769542297; Tue, 23 Jul 2019 09:01:42 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id EC6B61FE2D; Tue, 23 Jul 2019 09:01:41 +0200 (CEST) Date: Tue, 23 Jul 2019 09:01:41 +0200 From: Gert Doering To: David Lamparter Cc: Mark Smith , v6ops list Message-ID: <20190723070141.GG60824@Space.Net> References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190723000049.GJ34551@eidolon.nox.tf> X-NCC-RegID: de.space User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 07:01:47 -0000 Hi, On Tue, Jul 23, 2019 at 02:00:49AM +0200, David Lamparter wrote: > => Yes: it seems someone configured multicast. (You don't get this > without config, it's a bit of a PITA honestly.) Proceed to 2. > > 2. is whoever configured multicast competent? The general assumption for on-link multicast should be "it's broadcast or it is getting lost". Switch vendor track record shows that this is a constantly recurring problem, and the *best* you can hope for operational robustness is "on-link multicast is handled like broadcast". All the other snooping things just cause more work in figuring out this week's bugs and how to turn off the snopping bits. The general idea that on-link multicast is a positive aspect of IPv6 is nice, but wrong. 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 Tue Jul 23 01:29:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9611B120104; Tue, 23 Jul 2019 01:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 jx0esgkA6Nn7; Tue, 23 Jul 2019 01:29:19 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 12075120132; Tue, 23 Jul 2019 01:29:19 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id h18so41085629qtm.9; Tue, 23 Jul 2019 01:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=ub0Sn5q1yasNdWAzvjaBgECbexPmEy4kfvn4FcY7M8Q=; b=qvW3ihF4MN9L+pG4rLy5yjq1yw9YPyqwXWf9btiWV1KZU5P0Bh/0b9aMP848E01lYe sSJQpem+4CCE8STOwBCYy1cjFeShVQXnu4XdTuuhoBfuk+4o+FZQzhucFJLMAKAPzrBP p2eM98EF/p/OH6+eLPoyE9i5p5ehnzMnFjm4HZLVL1WuRlFPWDTqGoYkkCfhZFay95sv QeIIJrdihZ+HIWkNoFzyUKO7y1935W6sgWMV8KKEEDm9Zn2sLzDPHUR42tyscSaWWkWV hhOO9D4CZs9KuVF65evHogt7eXpT9bW/NPlsQZn+y/mUIM+yQeuBxv3bc3349K364rbD 5gcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=ub0Sn5q1yasNdWAzvjaBgECbexPmEy4kfvn4FcY7M8Q=; b=ecUR7eQ12t3+T7JDzROCYpKv8FD+adlxFrcvG2aKnkkvdorqi7+ZX26zZOzunOryPv T1wpLatNTtVz9kh0KSy6x9SlnjsBumUyI8fmSKo2mYWvlHIWX358WiFlmIQmhnQbMiXL KaquCh640qLnxn6l3wwuXjCgRFCZ4U/ThwUXBUSdetIYIxBGbWO4AWRZ1PpyQgiKNGBH 2QkVfSjRjooOq9YHrKZ6dXvD2h9zgvA4YS+jf8ws4+YmEFsQaESrpxEt6eA7TCHuOZPo BFUxgYtvo2SdQ3iZlTDskHXvAXJ8MAMM2LJaQw4nf784DsoZpV7KA6DAiFuMxLI0+5Oj OdYw== X-Gm-Message-State: APjAAAUST9GHu3of0m9Q6BXd6uk1Hy7T7LZdbvgX1s+VCKrifsk8v72z VeNKJ1FKaTvl9WHvztCG7HmWxCFHJM8= X-Google-Smtp-Source: APXvYqyKFMrg+rNpzn4L2nogAOangEVpHb1xLf7D1rwYRlOzExnbIH0oUrZlBWmiwfSiwvED6XRPTg== X-Received: by 2002:aed:3fb0:: with SMTP id s45mr53578071qth.136.1563870558014; Tue, 23 Jul 2019 01:29:18 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:5908:c9bd:b360:a7ae? ([2001:67c:1232:144:5908:c9bd:b360:a7ae]) by smtp.gmail.com with ESMTPSA id s11sm18332437qkm.51.2019.07.23.01.29.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 01:29:17 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\)) Message-Id: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> Date: Tue, 23 Jul 2019 04:29:15 -0400 Cc: 6man Chairs <6man-chairs@ietf.org> To: IPv6 Operations X-Mailer: Apple Mail (2.3566.0.1) Archived-At: Subject: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 08:29:21 -0000 In yesterday's meeting, the sense of the room and a discussion of = charters at the mike suggested that draft-linkova-v6ops-nd-cache-init = should become a working group draft. Doing so will require 6man to agree = to let v6ops suggest specific changes to RFC 4861 under the rubric of = "operational solutions", as discussed in the draft and = https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighb= or-cache-entries-on-first-hop-routers-operational-considerations-00; the = argument for not kicking those out to 6man is that the authors of RFC = 4861 are no longer in a position to approve errata to it, which would be = the other obvious approach (I'm not sure that's true of Erik Nordmark, = but whatever). It would also need to be considered to update RFC 4861. Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group = draft? Ron and I look through this thread next week and take the necessary = action, whatever the outcome might be.= From nobody Tue Jul 23 02:06:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEB4120155; Tue, 23 Jul 2019 02:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 6rPb_gbIPkWC; Tue, 23 Jul 2019 02:06:40 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607B9120151; Tue, 23 Jul 2019 02:06:39 -0700 (PDT) Received: from [192.168.1.30] (unknown [160.177.77.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AE054851CA; Tue, 23 Jul 2019 11:06:37 +0200 (CEST) To: Fred Baker , IPv6 Operations Cc: 6man Chairs <6man-chairs@ietf.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <894233ad-f403-5817-7dd5-07c19b0b9cdd@si6networks.com> Date: Tue, 23 Jul 2019 10:02:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 09:06:44 -0000 Fred, On 23/7/19 09:29, Fred Baker wrote: > In yesterday's meeting, the sense of the room and a discussion of > charters at the mike suggested that draft-linkova-v6ops-nd-cache-init > should become a working group draft. Doing so will require 6man to > agree to let v6ops suggest specific changes to RFC 4861 under the > rubric of "operational solutions", as discussed in the draft and > https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00; > the argument for not kicking those out to 6man is that the authors of > RFC 4861 are no longer in a position to approve errata to it, which > would be the other obvious approach (I'm not sure that's true of Erik > Nordmark, but whatever). It would also need to be considered to > update RFC 4861. My understanding is that, if anything, it is the relevant working groups that maintain and accept/reject errata, rather than their authors alone. (In fact, at the point the corresponding RFCs (at internet-draft stage) became wg items, they became adopted by the relevant wgs). That's why draft-ietf documents reflect the opinion of the relevant wg, rather than that of the authors. If a protocol needs to be updated, so be it. But that, I understand, is what 6man is for. I can see myself reasons for wanting to do it in v6ops. But unless I'm missing something, that's the charter of 6man, rather than of v6ops. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 23 04:08:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3A1201D2 for ; Tue, 23 Jul 2019 04:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, 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 HZCDKADHILU1 for ; Tue, 23 Jul 2019 04:08:06 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 3306A1200A4 for ; Tue, 23 Jul 2019 04:08:06 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id x15so38090326wmj.3 for ; Tue, 23 Jul 2019 04:08:06 -0700 (PDT) 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=nsB/1YvlTtBAByTXKJx8tptAkzNMTaxS45shafkCzM0=; b=Bmnr/2rFnPE1Sx9PqA1yCN5B8N1nDYOh6xre1FW6GECAGdhAyc68DieyQslVMBHIHh aryJuR4yRQPMY0Y45ol8TDJQ1NkUR3IUkoFdvmVC4mPvm4piSm99l8+Kyh3EiqEjxefB /UIE+gVJ17uZA+6AJB91nasJgr+dWzqz1uw2XByLxJB3JzRR/HgDOeLi8dO9vTcnyCgF 9W5WHdtyuL+5FsxJ4ZgVe99KTRiPaFYmHG8on0LPF3wjM6yFaDqrepf5IG3D5bkR2B2G Y5CQJNM76L/bSrdW4nh8gwPRVteRQVAYoY9WWLjJ6e/IazBmyAUt1HsP2U39Gh4eNuuT V6PQ== 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=nsB/1YvlTtBAByTXKJx8tptAkzNMTaxS45shafkCzM0=; b=lJ76OvKFj8OVDQs6sBbKSsO2TSYSi/XuC+mCfv7UH94FCfxuZQ/RpD0ILeyHdlhoLD wjhQFnGr5fJ5j/oVKlh9aphDlvVWMVlIIr/vf7Pc4YI4UIp8d1Clj122mwTpu70ObPYs IHzTYg3FHFZJ5HCItxlTnJ8EZsg/J7cMhr75fgP2Vewzbc0rlZGUcrD46W+vCbc4Zx3M znaRm6+bMnuXwuZYScCSPgfBmfSUI3mJ7mMhAhVp9GI5NZ4d+t5eddBbz1yGqK93k5H6 DNbiQHCIU5hSHcI902Y17fcqssJJiAREo5cHx3RHEb+pKtau2uIFEB5rC7840AF0hDBP yxYw== X-Gm-Message-State: APjAAAXlCBqXB4jq3q5p1iE9GwRTWFnOFKyI0oZC/QMKe0Uhnr3L5GLJ Uy8qpcwBQzax6ecDvv5hauygBX3ORgrnbx31HhCNDA== X-Google-Smtp-Source: APXvYqzWJE7NBnESgsyvzDFzx6WMgRCz/jiJ2mLiCa2vXj1UjXpZD2xHw3WJaRVjFsrcLez1pzfywDra8fEXdLz7YWU= X-Received: by 2002:a1c:20c3:: with SMTP id g186mr56434319wmg.15.1563880084233; Tue, 23 Jul 2019 04:08:04 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <894233ad-f403-5817-7dd5-07c19b0b9cdd@si6networks.com> In-Reply-To: <894233ad-f403-5817-7dd5-07c19b0b9cdd@si6networks.com> From: Lorenzo Colitti Date: Tue, 23 Jul 2019 07:07:52 -0400 Message-ID: To: Fernando Gont Cc: Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary="000000000000e4c6af058e5734e3" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 11:08:08 -0000 --000000000000e4c6af058e5734e3 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 23, 2019 at 5:07 AM Fernando Gont wrote: > My understanding is that, if anything, it is the relevant working groups > that maintain and accept/reject errata, rather than their authors alone. > (In fact, at the point the corresponding RFCs (at internet-draft stage) > became wg items, they became adopted by the relevant wgs). That's why > draft-ietf documents reflect the opinion of the relevant wg, rather than > that of the authors. > The assertion from Warren was that an erratum would not be approved because such an erratum would be clearly changing the intent of the original document, making it say the opposite of what it used to say. If a protocol needs to be updated, so be it. But that, I understand, is > what 6man is for. I can see myself reasons for wanting to do it in > v6ops. But unless I'm missing something, that's the charter of 6man, > rather than of v6ops. > And it is in the charter of v6ops to suggest those modifications: ====== 1. Solicit input from network operators and users to identify operational issues with IPv6 networks, and determine solutions or workarounds to those issues. ... IPv6 operational and deployment issues with specific protocols [...] are the primary responsibility of the groups or areas responsible for those protocols [...] However, the v6ops Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. ====== This is an operational issue in IPv6-only networks, and this draft is about determining a solution and providing 6man with input on how to resolve it in the protocol. --000000000000e4c6af058e5734e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2019 at 5:07 AM Fernando = Gont <fgont@si6networks.com= > wrote:
My understanding is that, if anything, it is the rel= evant working groups
that maintain and accept/reject errata, rather than their authors alone. (In fact, at the point the corresponding RFCs (at internet-draft stage)
became wg items, they became adopted by the relevant wgs). That's why draft-ietf documents reflect the opinion of the relevant wg, rather than that of the authors.

The assertion from= Warren was that an erratum would not be approved because such an erratum w= ould be clearly changing the intent of the original document, making it say= the opposite of what it used to say.

If a protocol needs to be updated, so be i= t. But that, I understand, is
what 6man is for. I can see myself reasons for wanting to do it in
v6ops. But unless I'm missing something, that's the charter of 6man= ,
rather than of v6ops.

And it is in the = charter of v6ops to suggest those modifications:

= =3D=3D=3D=3D=3D=3D
1. Solicit input from network operators and users t= o identify
operational issues with IPv6 networks, and determine solution= s or
workarounds to those issues.
...
IPv6 operational= and deployment issues with specific protocols [...]
are the prim= ary responsibility of
the groups or areas responsible for those protocol= s [...]
However, the v6ops Working Group may provide input to=
those areas/groups, as needed, and cooperate with those areas/gr= oups in
reviewing solutions to IPv6 operational and deployment problems.=
=3D=3D=3D=3D=3D=3D

This is an opera= tional issue in IPv6-only networks, and this draft is about determining a s= olution and providing 6man with input on how to resolve it in the protocol.=
--000000000000e4c6af058e5734e3-- From nobody Tue Jul 23 04:39:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BE01200EC; Tue, 23 Jul 2019 04:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 VpzloAk74hti; Tue, 23 Jul 2019 04:39:07 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 390E11200C4; Tue, 23 Jul 2019 04:39:07 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id r6so37314399qtt.0; Tue, 23 Jul 2019 04:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q71zh6poHk8L/VLK8VY24fzVRRJHinMWFBZv2v4hQ+0=; b=JrckudZ4o1YeuNShfOnnxAYJ878VXxBr7UhP4JJ60TVo4CquRinvMQrSlSP4aiwqI6 jgNfMRVUIyvenAvagt9+++n8uFZsd7owZQ15lFTLg74YlG9KjS2nbc6S3OagW4O6gBXc +yeTL3WvzYe8bkwwUI8TAjQyWIRjGJCofwMlnaW8L3pURyp3Fr96iZbIimn2gtHnq3aG BLA7sOY6I4OwTjZ0J2W1ihoJk7a5dhIJT85cr8RqWQnI79vw6UszlGFXwONHDiAfJLfC mMbMzDjA9ZnNpMo3b1f43w4RxQhFYNtTGGfNWFI+t1KhPILUKXoyz2S9isD+QyWjMzra 4eeA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=q71zh6poHk8L/VLK8VY24fzVRRJHinMWFBZv2v4hQ+0=; b=lpQb+se6k/Es9WtQKmOw8QOr80kZMrl0HfSfNX7hWBJPll3cW2m8DLFRDL8Qg0wOG+ xTzkMEfgrEm0g/z39+GCS3Q6pwryuVI+0PkUzAJ+soyu6fFWjnM+2GQp+iJlmcTwpP+S dNWS6IHSFs748bcOlpTmWxnaA0ruyk6ltyzsiwTrCmdHcdA+v1ZT6Ogjoy+GfMne7TtH Z6Jhk1kGHX3EmBFERlTJ42Kiyj3Jl8hjqR6GFbYah9P4RB39rNtaP6NlNbX0VVTP9Hay V4BxmGbHFRsa1nemJT9qxLte1gLS4dZr75CaKr/89j+HXK9l8UCoJQptqg5GZrvf0NqP lycg== X-Gm-Message-State: APjAAAX0crwFEBW5CUaYRPoMJfPkz1bYW7IKiPXO3Af1nt9VyWBBINDd 3uq2jOFwwD72go4kZea3xj9vxHzF X-Google-Smtp-Source: APXvYqwfwi2gLnlox2E3uRz9P5PXBXi43wy1cc7kHEUsXzg3xHGDhP/ODgSVgTSGpMkuqqLk1xNpLQ== X-Received: by 2002:ac8:2d69:: with SMTP id o38mr52512747qta.169.1563881946133; Tue, 23 Jul 2019 04:39:06 -0700 (PDT) Received: from [31.133.129.140] (dhcp-818c.meeting.ietf.org. [31.133.129.140]) by smtp.gmail.com with ESMTPSA id d26sm18799899qkl.97.2019.07.23.04.39.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 04:39:05 -0700 (PDT) To: Fred Baker , IPv6 Operations Cc: 6man Chairs <6man-chairs@ietf.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 23 Jul 2019 23:39:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 11:39:09 -0000 1) Yes, we should *obviously* do this. 2) If the charter prevents that, fix the charter. 3) I'm not convinced it needs to update 4861. If what it does is explain the conditions in which an RFC2119 "SHOULD" should be ignored, that is *not* an update to the standard. To me it sounds exactly like a Best Current Practice. 4) In any case, if the IETF rules are alleged to prevent doing the obvious right thing, the IESG can vary the rules, as allowed by BCP9. Regards Brian Carpenter On 23-Jul-19 20:29, Fred Baker wrote: > In yesterday's meeting, the sense of the room and a discussion of charters at the mike suggested that draft-linkova-v6ops-nd-cache-init should become a working group draft. Doing so will require 6man to agree to let v6ops suggest specific changes to RFC 4861 under the rubric of "operational solutions", as discussed in the draft and https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00; the argument for not kicking those out to 6man is that the authors of RFC 4861 are no longer in a position to approve errata to it, which would be the other obvious approach (I'm not sure that's true of Erik Nordmark, but whatever). It would also need to be considered to update RFC 4861. > > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group draft? > > Ron and I look through this thread next week and take the necessary action, whatever the outcome might be. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Tue Jul 23 05:02:51 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1165D120221 for ; Tue, 23 Jul 2019 05:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=iol.unh.edu 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 nSP5sCSVrwoB for ; Tue, 23 Jul 2019 05:02:47 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 937A112000F for ; Tue, 23 Jul 2019 05:02:47 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id v19so38275745wmj.5 for ; Tue, 23 Jul 2019 05:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IaA/EXDQBFWbeAmt9asLudvqNViBajFMaXobbYxowDY=; b=jFeCekOgXttt7A77GG8eawIUTqTQLwxrzsL0Lt0pPW/Tta0R/DVl67CKR6qBLpxPVi CLf09M/tz+SEPQUgd30FxTv6Fr/SbbrIvsLPwxCRe6caSzdij6VStYk3iaHwI1sD3Bor vHdTa85mld/Hq5u2iVT8n4KZVwJV3ZBekr6Gk= 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=IaA/EXDQBFWbeAmt9asLudvqNViBajFMaXobbYxowDY=; b=cpqOwpEPBq2ZIEv+jAU6+6O3+47N0/Tx4hQuzyDA9CzCGEePRxX7SmIF7kVtUK4lcv kFL0kF6OxEiG3dIsgj/6J8WHpzN3U0Z1BTMp9D64ntVLU60j4Pf2o7/TKDm9CzsuHDjz BC0UzHGNKEY0oqz+3VgZ9pktC5cAu65q3hH7jOXlmLRzpAeRvUK4G1eiQvl4tr64y03u 5VUZZCX/vXlbEENdFhUNbFL0A/d66PuFdjc+W/NcP4mm+vaDPsot585FsiKIXg9+gxJa Er2a1anD9vCReAXrzvUVlwCOzra5/whXKBE7GYoPmK81vxUu3ON+8sxTeSEt5MGKGVMc NLRQ== X-Gm-Message-State: APjAAAXTKc1VW4BpBActTQpC2MhGJwGHUtfm5mebx9xAdPba3PRDD8u1 P1+Mhuax/wvdj1yaw/lteavZwdSmv/sFEfBcAuX7cQ== X-Google-Smtp-Source: APXvYqxjjtSNpp8lWKk1uP4GZvKswHnhwTOIYLz18vRB7rSJmpIvyY5+G9EF/lLDuB+ZAF3SCDSU2X6dv4gf9n/HU5U= X-Received: by 2002:a1c:6c14:: with SMTP id h20mr66105184wmc.168.1563883365760; Tue, 23 Jul 2019 05:02:45 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> In-Reply-To: From: Timothy Winters Date: Tue, 23 Jul 2019 08:02:30 -0400 Message-ID: To: Brian E Carpenter Cc: Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary="0000000000007ca977058e57f857" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 12:02:50 -0000 --0000000000007ca977058e57f857 Content-Type: text/plain; charset="UTF-8" I also think this should be working group draft, as I mentioned at the mic I'm happy to help survey what current implementations are capable of. I also agree with Lozenzo last statement. ~Tim On Tue, Jul 23, 2019 at 7:39 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > 1) Yes, we should *obviously* do this. > 2) If the charter prevents that, fix the charter. > 3) I'm not convinced it needs to update 4861. If what it does is explain > the conditions in which an RFC2119 "SHOULD" should be ignored, that is > *not* an update to the standard. To me it sounds exactly like a Best > Current Practice. > 4) In any case, if the IETF rules are alleged to prevent doing the obvious > right thing, the IESG can vary the rules, as allowed by BCP9. > > Regards > Brian Carpenter > > On 23-Jul-19 20:29, Fred Baker wrote: > > In yesterday's meeting, the sense of the room and a discussion of > charters at the mike suggested that draft-linkova-v6ops-nd-cache-init > should become a working group draft. Doing so will require 6man to agree to > let v6ops suggest specific changes to RFC 4861 under the rubric of > "operational solutions", as discussed in the draft and > https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00; > the argument for not kicking those out to 6man is that the authors of RFC > 4861 are no longer in a position to approve errata to it, which would be > the other obvious approach (I'm not sure that's true of Erik Nordmark, but > whatever). It would also need to be considered to update RFC 4861. > > > > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group > draft? > > > > Ron and I look through this thread next week and take the necessary > action, whatever the outcome might be. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > . > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000007ca977058e57f857 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also think this should be working group draft, as I ment= ioned at the mic I'm happy to help survey what current implementations = are capable of.

I also agree with Lozenzo last statement= .

~Tim

On Tue, Jul = 23, 2019 at 7:39 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
1) Yes, we should *obviously* do this.
2) If the charter prevents that, fix the charter.
3) I'm not convinced it needs to update 4861. If what it does is explai= n the conditions in which an RFC2119 "SHOULD" should be ignored, = that is *not* an update to the standard. To me it sounds exactly like a Bes= t Current Practice.
4) In any case, if the IETF rules are alleged to prevent doing the obvious = right thing, the IESG can vary the rules, as allowed by BCP9.

Regards
=C2=A0 =C2=A0Brian Carpenter

On 23-Jul-19 20:29, Fred Baker wrote:
> In yesterday's meeting, the sense of the room and a discussion of = charters at the mike suggested that draft-linkova-v6ops-nd-cache-init shoul= d become a working group draft. Doing so will require 6man to agree to let = v6ops suggest specific changes to RFC 4861 under the rubric of "operat= ional solutions", as discussed in the draft and https://datatracker.ietf.org/meeting/105/materials/slide= s-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-conside= rations-00; the argument for not kicking those out to 6man is that the = authors of RFC 4861 are no longer in a position to approve errata to it, wh= ich would be the other obvious approach (I'm not sure that's true o= f Erik Nordmark, but whatever). It would also need to be considered to upda= te RFC 4861.
>
> Do we agree to take draft-linkova-v6ops-nd-cache-init as a working gro= up draft?
>
> Ron and I look through this thread next week and take the necessary ac= tion, whatever the outcome might be.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
> .
>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000007ca977058e57f857-- From nobody Tue Jul 23 06:03:34 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3C71202CB; Tue, 23 Jul 2019 06:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 zLc_haR4vStC; Tue, 23 Jul 2019 06:03:25 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 2A085120119; Tue, 23 Jul 2019 06:03:25 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from ) id 1hpuRv-00107f-2H; Tue, 23 Jul 2019 15:03:23 +0200 Date: Tue, 23 Jul 2019 15:03:23 +0200 From: David Lamparter To: IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Message-ID: <20190723130323.GK34551@eidolon.nox.tf> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:03:30 -0000 +1 -David On Tue, Jul 23, 2019 at 08:02:30AM -0400, Timothy Winters wrote: > I also think this should be working group draft, as I mentioned at the mic > I'm happy to help survey what current implementations are capable of. > > I also agree with Lozenzo last statement. > > ~Tim > > On Tue, Jul 23, 2019 at 7:39 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > 1) Yes, we should *obviously* do this. > > 2) If the charter prevents that, fix the charter. > > 3) I'm not convinced it needs to update 4861. If what it does is explain > > the conditions in which an RFC2119 "SHOULD" should be ignored, that is > > *not* an update to the standard. To me it sounds exactly like a Best > > Current Practice. > > 4) In any case, if the IETF rules are alleged to prevent doing the obvious > > right thing, the IESG can vary the rules, as allowed by BCP9. > > > > Regards > > Brian Carpenter > > > > On 23-Jul-19 20:29, Fred Baker wrote: > > > In yesterday's meeting, the sense of the room and a discussion of > > charters at the mike suggested that draft-linkova-v6ops-nd-cache-init > > should become a working group draft. Doing so will require 6man to agree to > > let v6ops suggest specific changes to RFC 4861 under the rubric of > > "operational solutions", as discussed in the draft and > > https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00; > > the argument for not kicking those out to 6man is that the authors of RFC > > 4861 are no longer in a position to approve errata to it, which would be > > the other obvious approach (I'm not sure that's true of Erik Nordmark, but > > whatever). It would also need to be considered to update RFC 4861. > > > > > > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group > > draft? > > > > > > Ron and I look through this thread next week and take the necessary > > action, whatever the outcome might be. > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > . > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 23 06:13:28 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F0A120073 for ; Tue, 23 Jul 2019 06:13:27 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RJIi26ZrUqx for ; Tue, 23 Jul 2019 06:13:25 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 6799E12006F for ; Tue, 23 Jul 2019 06:13:25 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id a15so38488892wmj.5 for ; Tue, 23 Jul 2019 06:13:25 -0700 (PDT) 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=z0mZDf9XHCd5TO1GUheouonDkGciSgktmmf+BK6wuD8=; b=AOzYHFosNb6Wdasul7KF6Ak6kfwY7V7zaHObii4P+vG4wW2Tr/YUcwN22L9LfrZV+f aZg1UunSNoeXdr1DEGSw8R2d3BmAEaHZBoNGNTHolmzgET765MV1S7dbbOpyCR0ymdyc 5cB0O19sOtGarRkQvCdD1yECNjql25hz2qNYU8j49riyxihL43qJ3pqg6ZkoUu/k17yB ppM7WHfqZz4UQPUF95A4eihogNXQAW3U5WFWpB4FNcQp41QljZ5MzSSbBaBtHOMXaRdd Px4yo3aDyAwJJ7sQ7L8Yf5peC0NfhAVNpuiqWxny+/IdhW01uVU4ZTDBaU4lXb23avtM PGrg== 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=z0mZDf9XHCd5TO1GUheouonDkGciSgktmmf+BK6wuD8=; b=PZ4JX3YcPVYPmiZUsyakPlpcwVwZOiVRCT2jNZIUVKpPRtUTGJ6CXRZkdpsQIs5uKx FI6cqGs5KOaYaJj4SiUch+V8TcN49tXoZLeBlMc0IEPk5qcHUAf1vPma4k9P7vlhhXJq WBtxf1brhKy25GXGKTDyhsSATa6ZQj6XHsgWa5O/VgyZdLOFuaSjnB2fytkf2ZsKoHIk 11RlneHlOPNzKo4gT/mEBfyIJpnusMkyrdgurlq7B9QNpxVfmUxobGd+AslfjVyejR6s veTQ63MrfVbbZXLhdPULyirNKVmk4hp4IEAfI+U7yv0WFe5fTRBctBXAgI7R5s5AhdIY aM/Q== X-Gm-Message-State: APjAAAXGmecH88bjEfzXdH+lmXY+pxzwdwE/wA49ElPRA9ztuitenOzw VsBYiO7rVFmTk9B2hAfdMkEVjLW5uDWVAceTK0+JxA== X-Google-Smtp-Source: APXvYqwEExxTysh/g8rfrCwUyk/M9KBwFyIcLIyRo6NX1ZSCOI5zbtgH0MRLqPsN3fbpmLdZmWVIcedEnrcywmR1A4M= X-Received: by 2002:a1c:ac81:: with SMTP id v123mr71098573wme.145.1563887603667; Tue, 23 Jul 2019 06:13:23 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> In-Reply-To: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> From: Lorenzo Colitti Date: Tue, 23 Jul 2019 09:13:09 -0400 Message-ID: To: Fred Baker Cc: IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary="00000000000016470e058e58f510" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:13:28 -0000 --00000000000016470e058e58f510 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 23, 2019 at 4:29 AM Fred Baker wrote: > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group > draft? > I support adopting this draft as a WG document. --00000000000016470e058e58f510 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000016470e058e58f510-- From nobody Tue Jul 23 06:16:40 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA471120119; Tue, 23 Jul 2019 06:16:37 -0700 (PDT) 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, 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 header.b=ckI7Yl/o; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ycpWMBcp 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 eVCnDoVeVpmW; Tue, 23 Jul 2019 06:16:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0E412006D; Tue, 23 Jul 2019 06:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4312; q=dns/txt; s=iport; t=1563887795; x=1565097395; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lGwwZVBJR7UFLpfWJlTybTpOTp/FRBWRZWVEn1suVU4=; b=ckI7Yl/oYLIoTEFXITNm9KOcH0axa6At8KKoS69+DwV/Lt5OlyulXgYb ovQ7swULw43dR40tRmFbVfNaWhiiu/pzYzfWC16ePRc81+Y37w2x+ki67 yQUGbrjBPRtBupPiMDo2qdOPEEL8sb7StOTK7GAvjAudhyqEgDInx9bhO E=; IronPort-PHdr: =?us-ascii?q?9a23=3AhBhcrR3hGri1diegsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADnBTdd/4QNJK1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgUNQA21VIAQLKoQdg0cDhFKJLYJbiVS?= =?us-ascii?q?NfIEugSQDVAkBAQEMAQEYBg8CAQGEQAIXgjcjNAkOAQMBAQQBAQIBBm2FHgy?= =?us-ascii?q?FSgEBAQMBAQEQBgsRDAEBLAsBBAsCAQgOCgICJgICAh8GCxUQAgQOBRsHgwA?= =?us-ascii?q?BgWoDDg8BAgyfWwKBOIhgcYEygnkBAQWBMgEDAgKBDYJADQuCEwMGgQwoAYk?= =?us-ascii?q?VgkkXgUA/gREnH4JMPoIaIiUBAQOEaTKCJo54my9ACQKCGYZYiUCDdBuCLZV?= =?us-ascii?q?djmaGF4F1jhMCBAIEBQIOAQEFgVA4gVhwFTsqAYJBgkKDcYUUhT9yAYEojiU?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.64,299,1559520000"; d="scan'208";a="600874094" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jul 2019 13:16:34 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x6NDGYdY018903 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jul 2019 13:16:34 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 08:16:33 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 08:16:33 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 23 Jul 2019 08:16:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jv1x/BS1znmJw+i+JnFKZnQowg3yl9jp7SmSfbdyHma+nERTEOYMJMFqg2yX9cl+g8gywJZxuNzvtbGN0Q9xMT9Ny4c72jIhQSbMS89N6WsuYQkCWLQE8Dc0qldaduikOBGm9FUktyCC7QnUgPCS8uKPpr/BUsLMqND4DSxJreat0ypLAdubk5FSg90TqYSwVpyGj17rs1Btd63g8ZoyHpMWIDlt33+N951zD5SZOR6i/SPNFDecvPct/zB0xSSaq/hjaxmFPN+yKAd+FJw6FnnbASgJupp2lTUvYgLMwUBWGr9RTougQI3efFKP/WvfBMHh455P97wzWPZE7UfeCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lGwwZVBJR7UFLpfWJlTybTpOTp/FRBWRZWVEn1suVU4=; b=VO/2NQQSaL5VBLJ6eOZgBnTXh4mHBF3OfpgKcRha2DukhW1lJZ4zCutPFMiFi02n1GHjzBSv1uJbPFigAf8Z4yaik+LFIXpZu/zLnHDkr+SQudUmofJg07dZwVVTPmAG7Dsi3bi+MS8mvLCDMI+4S3r6Kx17bUZUc0o+iSUqA0mpHH1io+KLrh/VgsoivC6KTDBCUrkkM2NQuAfVxzIUnM1Zo823/PaciI31nYIBEmah/vzgw/c7tsYBZ1fmNqXjjSoGDCCT00HmUloen0mR7G+aIjjbNhKiCkyF7bLLhFO/8pNpe0ZUAkk75P5LnEmgYSfcQducXb/tosZ21pBOZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lGwwZVBJR7UFLpfWJlTybTpOTp/FRBWRZWVEn1suVU4=; b=ycpWMBcppz7HxgstSaEyoOR2JLPKmkjlTmRB8egPGglrkL4W6sihUyuODdXAZFrt4EAhAuJlMQ010JJIhzFIIugZICiBv9FpTkAPXSLXEUxq29pB+WljcsTAVkb/lyRrstIEY8lZYUnnMhn11pfljKAk9ZNJt20ITJlY7tYQf14= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4128.namprd11.prod.outlook.com (20.179.150.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Tue, 23 Jul 2019 13:16:29 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2094.013; Tue, 23 Jul 2019 13:16:29 +0000 From: "Pascal Thubert (pthubert)" To: David Lamparter CC: IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Thread-Topic: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft Thread-Index: AQHVQTDJQIJu4w3G6EWWHtrdc581RKbYFBSAgAAGiwCAABEDgIAAA6lR Date: Tue, 23 Jul 2019 13:16:29 +0000 Message-ID: <4F9991E5-AB39-464E-BBF8-87D3B6A6B677@cisco.com> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> , <20190723130323.GK34551@eidolon.nox.tf> In-Reply-To: <20190723130323.GK34551@eidolon.nox.tf> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:67c:370:128:7150:45d3:56e4:b349] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 034ec00c-bfbb-4fc4-83b4-08d70f6ff986 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4128; x-ms-traffictypediagnostic: MN2PR11MB4128: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(366004)(396003)(39860400002)(376002)(189003)(199004)(86362001)(6512007)(81156014)(6306002)(14454004)(6436002)(2906002)(36756003)(6246003)(81166006)(33656002)(256004)(6486002)(7736002)(68736007)(6116002)(53936002)(8936002)(66574012)(71200400001)(71190400001)(5660300002)(14444005)(4326008)(229853002)(54906003)(186003)(476003)(25786009)(66446008)(66946007)(446003)(91956017)(316002)(64756008)(66556008)(66476007)(76176011)(966005)(478600001)(76116006)(11346002)(6916009)(2616005)(102836004)(46003)(486006)(6506007)(53546011)(8676002)(305945005)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4128; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /o6XqqO1e6l+J37ZC5yZGafo55K5xP6uJ7atknK+E7XngqtWQ8NK7K2gIF+L5ncKF/6J5CxzDQT/B0nKLyPDJ4eIy9UqX+0kV7mSBtaC46TSkR02yZ+0j3mcprqZ+dIVtv1nmzYaifFCESNXqkimjins1ydewVPGiwbFMrh8mmvNXTKvZQ9hxgu86k+Wf2wgXhhkqI35n66yI4H0dJhoaDt1pwQfYB1v4B+bjEdozXR2aY4Sk6Ev+6UosHWOztQqeGO4041hEK93VQ83Vjyxv5JgJjn33cAfUkwaDq3rN0vQQ8B2+OtHN4xYbivYjz9DHglcTZOq11eJ5sxK2HybiP1qgwomffVx3yCWMquKIJZsyjo1hQEh49PKffwdgMWqOddDNokSortiGvZxrNfLZdi9j+wnCJ48cEqfCHJyBtw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 034ec00c-bfbb-4fc4-83b4-08d70f6ff986 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 13:16:29.7393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4128 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:16:38 -0000 SSBzdXBwb3J0IHRoZSBpZGVhIHRvIGFkb3B0IHRoZSBkcmFmdCBhbmQgZG9jdW1lbnQgdGhlIGdl bmVyYWwgcHJvYmxlbSB0aGF04oCZcyBiZWhpbmQgaXQuDQpUaGUgYXR0YWNrIHZlY3RvcnMgb24g dGhlIHJvdXRlciBhcmUgcGFydCBvZiB0aGF0IGdlbmVyYWwgcHJvYmxlbS4NCg0KQXMgSSB1bmRl cnN0YW5kIExvcmVuem8g4oCYcyBwb2ludCwgdGhlIGZ1bGwgc29sdXRpb24gcHJvYmFibHkgYmVs b25ncyB0byA2bWFuLiBXZSBhcmUgbm93IGZpbmRpbmcgdGhhdCB3ZSBuZWVkIHRvIHJlY29uc2lk ZXIgdGhlIHJlYWN0aXZlIGJlaGF2aW9yIG9mIE5EIEFSLiBUcmlja2luZyB0aGUgY3VycmVudCBt b2RlbCBjYW4gaW1wcm92ZSB0aGluZ3MgYnV0IG9ubHkgc28gZmFyLiANCg0KDQpSZWdhcmRzLA0K DQpQYXNjYWwNCg0KPiBMZSAyMyBqdWlsLiAyMDE5IMOgIDA5OjA1LCBEYXZpZCBMYW1wYXJ0ZXIg PGVxdWlub3hAZGlhYzI0Lm5ldD4gYSDDqWNyaXQgOg0KPiANCj4gKzENCj4gDQo+IC1EYXZpZA0K PiANCj4+IE9uIFR1ZSwgSnVsIDIzLCAyMDE5IGF0IDA4OjAyOjMwQU0gLTA0MDAsIFRpbW90aHkg V2ludGVycyB3cm90ZToNCj4+IEkgYWxzbyB0aGluayB0aGlzIHNob3VsZCBiZSB3b3JraW5nIGdy b3VwIGRyYWZ0LCBhcyBJIG1lbnRpb25lZCBhdCB0aGUgbWljDQo+PiBJJ20gaGFwcHkgdG8gaGVs cCBzdXJ2ZXkgd2hhdCBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBhcmUgY2FwYWJsZSBvZi4NCj4+ IA0KPj4gSSBhbHNvIGFncmVlIHdpdGggTG96ZW56byBsYXN0IHN0YXRlbWVudC4NCj4+IA0KPj4g flRpbQ0KPj4gDQo+PiBPbiBUdWUsIEp1bCAyMywgMjAxOSBhdCA3OjM5IEFNIEJyaWFuIEUgQ2Fy cGVudGVyIDwNCj4+IGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+ PiAxKSBZZXMsIHdlIHNob3VsZCAqb2J2aW91c2x5KiBkbyB0aGlzLg0KPj4+IDIpIElmIHRoZSBj aGFydGVyIHByZXZlbnRzIHRoYXQsIGZpeCB0aGUgY2hhcnRlci4NCj4+PiAzKSBJJ20gbm90IGNv bnZpbmNlZCBpdCBuZWVkcyB0byB1cGRhdGUgNDg2MS4gSWYgd2hhdCBpdCBkb2VzIGlzIGV4cGxh aW4NCj4+PiB0aGUgY29uZGl0aW9ucyBpbiB3aGljaCBhbiBSRkMyMTE5ICJTSE9VTEQiIHNob3Vs ZCBiZSBpZ25vcmVkLCB0aGF0IGlzDQo+Pj4gKm5vdCogYW4gdXBkYXRlIHRvIHRoZSBzdGFuZGFy ZC4gVG8gbWUgaXQgc291bmRzIGV4YWN0bHkgbGlrZSBhIEJlc3QNCj4+PiBDdXJyZW50IFByYWN0 aWNlLg0KPj4+IDQpIEluIGFueSBjYXNlLCBpZiB0aGUgSUVURiBydWxlcyBhcmUgYWxsZWdlZCB0 byBwcmV2ZW50IGRvaW5nIHRoZSBvYnZpb3VzDQo+Pj4gcmlnaHQgdGhpbmcsIHRoZSBJRVNHIGNh biB2YXJ5IHRoZSBydWxlcywgYXMgYWxsb3dlZCBieSBCQ1A5Lg0KPj4+IA0KPj4+IFJlZ2FyZHMN Cj4+PiAgIEJyaWFuIENhcnBlbnRlcg0KPj4+IA0KPj4+PiBPbiAyMy1KdWwtMTkgMjA6MjksIEZy ZWQgQmFrZXIgd3JvdGU6DQo+Pj4+IEluIHllc3RlcmRheSdzIG1lZXRpbmcsIHRoZSBzZW5zZSBv ZiB0aGUgcm9vbSBhbmQgYSBkaXNjdXNzaW9uIG9mDQo+Pj4gY2hhcnRlcnMgYXQgdGhlIG1pa2Ug c3VnZ2VzdGVkIHRoYXQgZHJhZnQtbGlua292YS12Nm9wcy1uZC1jYWNoZS1pbml0DQo+Pj4gc2hv dWxkIGJlY29tZSBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuIERvaW5nIHNvIHdpbGwgcmVxdWlyZSA2 bWFuIHRvIGFncmVlIHRvDQo+Pj4gbGV0IHY2b3BzIHN1Z2dlc3Qgc3BlY2lmaWMgY2hhbmdlcyB0 byBSRkMgNDg2MSB1bmRlciB0aGUgcnVicmljIG9mDQo+Pj4gIm9wZXJhdGlvbmFsIHNvbHV0aW9u cyIsIGFzIGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQgYW5kDQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9tZWV0aW5nLzEwNS9tYXRlcmlhbHMvc2xpZGVzLTEwNS12Nm9wcy1uZWlnaGJv ci1jYWNoZS1lbnRyaWVzLW9uLWZpcnN0LWhvcC1yb3V0ZXJzLW9wZXJhdGlvbmFsLWNvbnNpZGVy YXRpb25zLTAwOw0KPj4+IHRoZSBhcmd1bWVudCBmb3Igbm90IGtpY2tpbmcgdGhvc2Ugb3V0IHRv IDZtYW4gaXMgdGhhdCB0aGUgYXV0aG9ycyBvZiBSRkMNCj4+PiA0ODYxIGFyZSBubyBsb25nZXIg aW4gYSBwb3NpdGlvbiB0byBhcHByb3ZlIGVycmF0YSB0byBpdCwgd2hpY2ggd291bGQgYmUNCj4+ PiB0aGUgb3RoZXIgb2J2aW91cyBhcHByb2FjaCAoSSdtIG5vdCBzdXJlIHRoYXQncyB0cnVlIG9m IEVyaWsgTm9yZG1hcmssIGJ1dA0KPj4+IHdoYXRldmVyKS4gSXQgd291bGQgYWxzbyBuZWVkIHRv IGJlIGNvbnNpZGVyZWQgdG8gdXBkYXRlIFJGQyA0ODYxLg0KPj4+PiANCj4+Pj4gRG8gd2UgYWdy ZWUgdG8gdGFrZSBkcmFmdC1saW5rb3ZhLXY2b3BzLW5kLWNhY2hlLWluaXQgYXMgYSB3b3JraW5n IGdyb3VwDQo+Pj4gZHJhZnQ/DQo+Pj4+IA0KPj4+PiBSb24gYW5kIEkgbG9vayB0aHJvdWdoIHRo aXMgdGhyZWFkIG5leHQgd2VlayBhbmQgdGFrZSB0aGUgbmVjZXNzYXJ5DQo+Pj4gYWN0aW9uLCB3 aGF0ZXZlciB0aGUgb3V0Y29tZSBtaWdodCBiZS4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+Pj4+ IHY2b3BzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHMNCj4+Pj4gLg0KPj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4+IHY2 b3BzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KPj4+IA0KPiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcw0K From nobody Tue Jul 23 06:33:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309DE12028E for ; Tue, 23 Jul 2019 06:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 oahOnPFTOrpP for ; Tue, 23 Jul 2019 06:32:58 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 164D6120281 for ; Tue, 23 Jul 2019 06:32:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 2F3D24B; Tue, 23 Jul 2019 15:32:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1563888771; bh=vV8pfASp/Jpzk65JmGW EbjDyq3QAw3iWEn/lirTNJ4U=; b=eNZ5MZ24rcE/7V6wZvRZimtGJtaFgA1YNA8 tXAe+RElEDmKL+PxLDWkvzcXDiZVvKW0YX3aZwT7CxsH1SQerG7JR/ZYh91g9ki2 F6vlGV7LqsfXF3dmkIanFX+HcBY/EGt3/Hajs5LPAF/yweP7b1NRScVnqruTgN/3 6U8dIWlg= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bVenLnftGzF1; Tue, 23 Jul 2019 15:32:51 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:ce80:e0c8:ace:ff75:2302] (unknown [IPv6:2a02:a213:a300:ce80:e0c8:ace:ff75:2302]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 6024849; Tue, 23 Jul 2019 15:32:48 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <9740316D-61DE-4BF4-87C2-5BCA5575BC27@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_3B9BF320-D524-41A9-A7BA-2CB44BE7610D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 23 Jul 2019 15:32:47 +0200 In-Reply-To: <20190723070141.GG60824@Space.Net> Cc: David Lamparter , v6ops list To: =?utf-8?Q?Gert_D=C3=B6ring?= References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:33:07 -0000 --Apple-Mail=_3B9BF320-D524-41A9-A7BA-2CB44BE7610D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > The general idea that on-link multicast is a positive aspect of IPv6 > is nice, but wrong. Well, a little bit :) There is still the advantage that the NIC can apply its MAC address = filter. L2 destination FF:FF:FF:FF:FF:FF can't be filtered there, but = 33:33:* can :) Cheers, Sander --Apple-Mail=_3B9BF320-D524-41A9-A7BA-2CB44BE7610D 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----- iQEzBAEBCAAdFiEE9VC3eloaasvH0nE1oC0DsP4kE7kFAl03DH8ACgkQoC0DsP4k E7nQOwf/eTTzNm7zK8m8qkFoarC/Oe8e1Hrb/kIILtF63KhuGnsskozNLlaanLBR 0pCvZ/HfJGVWLiVJzOFkeazJi2usjXVJqu2qu4Gx61EuAK2avoLWl6rG6sf6Cys/ JGGYss8EZVEijUDEwO9nxpw/TcP1MMyyvadaZZZ46kVxB79q2nMd5P+psfnmOMf1 ip6pZJV6/+6UZlvqB3+pq4jPcw8Avaib+0IpNbBLFBaRGSIGTnEYLp5ocfZ6jGXV zentJRLBb46RhSH13Ss3D+aiUZG8S28IkHI4QfHsE6+ozmZZl6ZD2yzBlfQ4CKZj 7M4XM47ULi/4SliL674N5hmzzs8J6A== =W1oE -----END PGP SIGNATURE----- --Apple-Mail=_3B9BF320-D524-41A9-A7BA-2CB44BE7610D-- From nobody Tue Jul 23 06:45:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55422120119 for ; Tue, 23 Jul 2019 06:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 905rksZKdF38 for ; Tue, 23 Jul 2019 06:45:28 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 E04CF12024E for ; Tue, 23 Jul 2019 06:45:26 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id n4so43324977wrs.3 for ; Tue, 23 Jul 2019 06:45:26 -0700 (PDT) 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=VGommA4P7o2Db+/WHMiXif266h/3U3aXZB+xz+Ev44w=; b=NA9hR8T12DlZUrf+F8BOPhk+cTwJisus9dvXFsK2MnHiHgylVm/Sx2gdHL8uUA98rl 0059AYNCrR1mN37GxDjW/lmo3Q12cnsNSjJzGLJxDHRhzLu/PBaGVPbxcoFqsw3C7HU0 k+aj+3EgMiL+WdhFlQbxSKsNcNf/EHg5CVhP+JlqeYy+IeqsXj1xGeaOVaEjR1hA5xSp cwMWVIs5tRO75Ey7tBfNthWxG/QqDviaFWuB4S7+5wCwFiSmxdP4dzJUJ8bacIVPXfO2 QmLLPt+b+29gdbk73GLtvJz/KsIbhWjMzs8vGJCEtf/PWceA3h3Bmj8NMQGHoxZq+qZa Heuw== 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=VGommA4P7o2Db+/WHMiXif266h/3U3aXZB+xz+Ev44w=; b=gksBY93PHVl20JQLOt8E2Z1V/8msS0hvDICOk1rRtr8xHp3mOsRGk8/BtxXFSgF5/8 QnreVoLVLt1G42rqcRaqTggKLi8gqODqocslc32jWEmdKWbjw/AZtrUP5HNlQiI17xSL mYDEuRIyWNAFK3kj4MiRIBp+b8mbKDexj+LJd8RhuVSqE7UTxqytCM1DckPn9RC+VvNQ qLkX94QIhlK9/4gFZMH6slgWNq8O/JUtUMw7gX8kBDpLAHx7ix70frIe1pfrJkF5tIEj ADZcU4NUE8XcvzhbHP5shpkOiEBPmauAHZWUAQEcf9Bevnv5N66k1ff+COiBBdvs7IjS G08w== X-Gm-Message-State: APjAAAVzjk5mVBNlG3ZaN+82TWtxlhuwPxQz6B2byAF76LmEqK3DVt6D KjL1FW0VqibyczQVvH3SAZd0LMvvmg1x152jqbw62w== X-Google-Smtp-Source: APXvYqxMVa5OQ4wSDMrdJq4zy8NUja5QdHh3uRShhoRayMtGgb6v6qYV6wpVssOS74qj+/fQWGOIRXegD+DPz/Oy+WM= X-Received: by 2002:adf:e50c:: with SMTP id j12mr11179909wrm.117.1563889525128; Tue, 23 Jul 2019 06:45:25 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <20190723130323.GK34551@eidolon.nox.tf> <4F9991E5-AB39-464E-BBF8-87D3B6A6B677@cisco.com> In-Reply-To: <4F9991E5-AB39-464E-BBF8-87D3B6A6B677@cisco.com> From: Lorenzo Colitti Date: Tue, 23 Jul 2019 09:45:13 -0400 Message-ID: To: "Pascal Thubert (pthubert)" Cc: David Lamparter , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary="0000000000009d552a058e5967d4" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:45:32 -0000 --0000000000009d552a058e5967d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2019 at 9:16 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > I support the idea to adopt the draft and document the general problem > that=E2=80=99s behind it. > The attack vectors on the router are part of that general problem. > > As I understand Lorenzo =E2=80=98s point, the full solution probably belo= ngs to > 6man. For the record, actually no, that is not my position. Protocol changes do belong in 6man. But as Brian says, we may not need protocol changes. A BCP seems like a fine place to say "here's a good reason not to implement this SHOULD in a router". > We are now finding that we need to reconsider the reactive behavior of ND > AR. Tricking the current model can improve things but only so far. > For the record, I don't agree with this. Changing the reactive behaviour has far-reaching implications and a number of difficult trade-offs with regard to scalability, crash recovery, availability of addresses to network nodes, and so on. --0000000000009d552a058e5967d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the idea to adopt the draft and docu= ment the general problem that=E2=80=99s behind it.
The attack vectors on the router are part of that general problem.

As I understand Lorenzo =E2=80=98s point, the full solution probably belong= s to 6man.

For the record, actually no, tha= t is not my position. Protocol changes do belong in 6man. But as Brian says= , we may not need protocol changes. A BCP seems like a fine place to say &q= uot;here's a good reason not to implement this SHOULD in a router"= .
=C2=A0
W= e are now finding that we need to reconsider the reactive behavior of ND AR= . Tricking the current model can improve things but only so far.

For the record, I don't agree with this. Cha= nging the reactive=C2=A0behaviour has far-reaching implications and a numbe= r of difficult trade-offs with regard to scalability, crash recovery, avail= ability of addresses to network nodes, and so on.
--0000000000009d552a058e5967d4-- From nobody Tue Jul 23 06:48:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83557120119 for ; Tue, 23 Jul 2019 06:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 IwmQiV7mwn2f for ; Tue, 23 Jul 2019 06:48:28 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCD3120043 for ; Tue, 23 Jul 2019 06:48:28 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 14FB541B93 for ; Tue, 23 Jul 2019 15:48:26 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 04F80406BC; Tue, 23 Jul 2019 15:48:26 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 00E2A20C1B; Tue, 23 Jul 2019 15:48:25 +0200 (CEST) Date: Tue, 23 Jul 2019 15:48:25 +0200 From: Gert Doering To: Sander Steffann Cc: Gert =?iso-8859-1?Q?D=F6ring?= , David Lamparter , v6ops list Message-ID: <20190723134825.GT60824@Space.Net> References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> <9740316D-61DE-4BF4-87C2-5BCA5575BC27@steffann.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oQzL12nKbmSHS3MD" Content-Disposition: inline In-Reply-To: <9740316D-61DE-4BF4-87C2-5BCA5575BC27@steffann.nl> X-NCC-RegID: de.space User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:48:31 -0000 --oQzL12nKbmSHS3MD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 23, 2019 at 03:32:47PM +0200, Sander Steffann wrote: > > The general idea that on-link multicast is a positive aspect of IPv6 > > is nice, but wrong. >=20 > Well, a little bit :) >=20 > There is still the advantage that the NIC can apply its MAC address filte= r. L2 destination FF:FF:FF:FF:FF:FF can't be filtered there, but 33:33:* ca= n :) Given the insanity of modern NICs, I have no doubt it could filter about everything the host want to see :-) (Shall I say "LLDP agent inside the NIC that you can't easily get rid of"?) But seriously - given that the amount of multicast traffic that goes=20 to a group address is totally negilible compared to the amount of=20 "TO ALL!" traffic caused by netbios, bonjour, ... - and that we do not really have 10 Mbit NICs anymore, I still maintain that this was one of the IPv6 "improvements" where unintended side effects by far outweigh the small benefits. 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 --oQzL12nKbmSHS3MD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl03ECcACgkQ31bAZeTO f8X+BA//Qlhu3DTLmuaqHuOxeG8fuqkPfrnwMlFeuHF3fac/o+yChcCdT5Ry4Odo ZZNoscnbc4XOEYNcrxgk17tD8+nmd2tP1B1Ikq2C0LF74IM/hmIE+1QIoxfE52wc 6QLIstw4hvE2k7rtIAiqyffVT+KNuhAuL4+CwagSkpGqbm/kV7StyDW65jV9N+WM Y6b3BAel0JZ2tapCflHMgmDFckXbAEhGp3BQ8ljyIeL/FHCqpcE4wK2dIuKRbo2s voXghXCm8Y0zxnR5wUx2CVgFfL/gsKuMOo5UNSFyhTOTXLf3IrcBvgCqW3kZbEEN uPLXjIf/v0o+/5vq+5VQwFCuV4KE8vqP9ptd3CnRmZk+iqnC6pefVQt1KBWqwTzR bZ7tPBOw2p8mYJeuMl+Oe5JauazhmNonhJWTkO8Cu2vk9Rd3nsCyoRaZGiS6+biQ 6MMkrLhedNrpq9qhf6nAB9wK/XIKVNCoeqtIcNvt6BXlSCNvo+GHbvb6oOAA8oAd BDNtxrrUdvrouX8UA+d1Z3/nIWK60e57e6SjSa8348NTtHZJiIndDdcO50+N2xS9 oZUex5qfgmRmj00ra0xRLwIhYZkwpvtQtXGhDsNcnGNM9M6r8x/3T0lTgK1pk7t1 gLNf7CdLkX84FLp7eL3oSInuqwTYTR/kZMCxQusp13KMKxmzOYc= =Wg7m -----END PGP SIGNATURE----- --oQzL12nKbmSHS3MD-- From nobody Tue Jul 23 06:58:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE51120119 for ; Tue, 23 Jul 2019 06:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 y6YlqhLQarma for ; Tue, 23 Jul 2019 06:58:32 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 03297120116 for ; Tue, 23 Jul 2019 06:58:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0E5B84C; Tue, 23 Jul 2019 15:58:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1563890307; bh=hkgTTpIkULBG8sHBtQs 2JB8s75ofTJ0onmgU/fzqITE=; b=qIKDfCoyvANEARvvTD81eX9sopJ//OI7In+ Uadc0+G7TpKbhZ0Lch/tiJtCLh16XAlHAHPkiElfWgiG1ofbpNGIoo8nkEbqadA5 OkcrBk7ktL6gZtXwHNY3cWd7jjkV8RKsQYHEFOZkN6XD3+sms2YUUgUtSLOGsLOh LHWJquQM= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xi1Rbbm5dQgz; Tue, 23 Jul 2019 15:58:27 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:ce80:e0c8:ace:ff75:2302] (unknown [IPv6:2a02:a213:a300:ce80:e0c8:ace:ff75:2302]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 6919B4B; Tue, 23 Jul 2019 15:58:27 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <19240B81-04D9-461F-B5C3-5FBDCC104AE0@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_36FD6A9E-1D6D-4666-A30F-0B4DBE2A4F4F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 23 Jul 2019 15:58:26 +0200 In-Reply-To: <20190723134825.GT60824@Space.Net> Cc: David Lamparter , v6ops list To: =?utf-8?Q?Gert_D=C3=B6ring?= References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> <9740316D-61DE-4BF4-87C2-5BCA5575BC27@steffann.nl> <20190723134825.GT60824@Space.Net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:58:34 -0000 --Apple-Mail=_36FD6A9E-1D6D-4666-A30F-0B4DBE2A4F4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > (Shall I say "LLDP agent inside the NIC that you can't easily get rid = of"?) Hello X710! Device ID Local Intf Hold-time Capability Port ID 246e.9646.6890 Te1/0/1 121 = 246e.9646.6890 246e.9646.6892 Te1/0/2 121 = 246e.9646.6892 To be absolutely clear: the device connected to those ports is currently = switched off... This is the NIC speaking from standby-mode. Cheers, Sander --Apple-Mail=_36FD6A9E-1D6D-4666-A30F-0B4DBE2A4F4F 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----- iQEzBAEBCAAdFiEE9VC3eloaasvH0nE1oC0DsP4kE7kFAl03EoIACgkQoC0DsP4k E7nrJAf7BXoT67O08eC81bMx28zVbGSoEn4tSFnxFfzVLMS9aNfM77YIKvMZ6Z9L YkXzYgcfDucjpsLIt46WwOoyw21Q1wKOODCImBGwvesYDt7Dsf2BSC/1sdgy5Lpu DfLytmcUjA+DEzA34xGWwHLML5sK0cQxzxcmSNDwikHQ0RQRFhLJLkZbGk91lqu4 H6h04ShUbSWoySnViptPLejYbkjQ1rZSHH7Xqyxetaw/f2ECSSSEzzSmnkGr4z6h 5C5N8d9dsd0FY0464D5dGjKaPbKAFbr6QDncxJmPabg0FH1uZon3ckRoXQ2EZGa/ yY3OssmFphUUMC6YUD61lmH1FGVpSQ== =WBky -----END PGP SIGNATURE----- --Apple-Mail=_36FD6A9E-1D6D-4666-A30F-0B4DBE2A4F4F-- From nobody Tue Jul 23 06:59:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684791202FA; Tue, 23 Jul 2019 06:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=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 5_k9S5NWRndG; Tue, 23 Jul 2019 06:59:44 -0700 (PDT) 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 13A081202CE; Tue, 23 Jul 2019 06:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1563890382; x=1564495182; 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; bh=zq290zdA6gNlS2lrCtwaKG Z5rUPoRvVnF6YEg5lwP1w=; b=E5TgvcWUqd5TMEvdrsY1OK43axKruRvoskUn3h 4Wj4wuiivAgaUxD/szkW3d0gYFQTnBRT7RIHpk5Zwy60kdI2K/l5+7NJT5fV2xW5 0zl4OOL9XWbKfFFEneMkNGt8O+cVw2CTc/l9XsAN4QDZV2O2WKhGH6Q4JfgAfum6 zMXu0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 23 Jul 2019 15:59:42 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 23 Jul 2019 15:59:42 +0200 Received: from [31.133.129.166] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006333921.msg; Tue, 23 Jul 2019 15:59:40 +0200 X-MDRemoteIP: 2001:67c:370:128:c5ac:9470:527a:43b9 X-MDHelo: [31.133.129.166] X-MDArrival-Date: Tue, 23 Jul 2019 15:59:40 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1107c8e3d3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.c.190715 Date: Tue, 23 Jul 2019 09:59:37 -0400 From: JORDI PALET MARTINEZ To: IPv6 Operations CC: 6man Chairs <6man-chairs@ietf.org> Message-ID: Thread-Topic: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3646720777_1356634143" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:59:55 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3646720777_1356634143 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable +1 =20 Regards, Jordi @jordipalet =20 =20 =20 El 23/7/19 9:14, "v6ops en nombre de Lorenzo Colitti" escribi=C3=B3: =20 On Tue, Jul 23, 2019 at 4:29 AM Fred Baker wrote= : Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group dr= aft? =20 I support adopting this draft as a WG document.=20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=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. --B_3646720777_1356634143 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

+1

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/7/1= 9 9:14, "v6ops en nombre de Lorenzo Colitti" <v6ops-bounces@ietf.org en nombre de lorenzo=3D40google.com@dm= arc.ietf.org> escribi=C3=B3:

 

<= div>

On Tue, Jul 23, 2019 = at 4:29 AM Fred Baker <fredb= aker.ietf@gmail.com> wrote:

Do we agree to take draft-linkova-v6ops-nd-cache-init as a work= ing group draft?

 

I support adopting this draft as a WG docume= nt. 

_______________________________________________ v6ops mail= ing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


**********************************************
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.

--B_3646720777_1356634143-- From nobody Tue Jul 23 07:31:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F03112011F for ; Tue, 23 Jul 2019 07:31:04 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_ldvDPcKuNT for ; Tue, 23 Jul 2019 07:31:01 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 0694E120226 for ; Tue, 23 Jul 2019 07:31:01 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from ) id 1hpvof-001nCS-IC; Tue, 23 Jul 2019 16:30:57 +0200 Date: Tue, 23 Jul 2019 16:30:57 +0200 From: David Lamparter To: Gert Doering Cc: David Lamparter , Mark Smith , v6ops list Message-ID: <20190723143057.GC258193@eidolon.nox.tf> References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190723070141.GG60824@Space.Net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:31:05 -0000 On Tue, Jul 23, 2019 at 09:01:41AM +0200, Gert Doering wrote: > On Tue, Jul 23, 2019 at 02:00:49AM +0200, David Lamparter wrote: > > => Yes: it seems someone configured multicast. (You don't get this > > without config, it's a bit of a PITA honestly.) Proceed to 2. > > > > 2. is whoever configured multicast competent? > > The general assumption for on-link multicast should be "it's broadcast > or it is getting lost". > > Switch vendor track record shows that this is a constantly recurring > problem, and the *best* you can hope for operational robustness is > "on-link multicast is handled like broadcast". All the other snooping > things just cause more work in figuring out this week's bugs and how > to turn off the snopping bits. > > The general idea that on-link multicast is a positive aspect of IPv6 > is nice, but wrong. I'm happy to agree that in most cases multicast will be broadcast, and gleaning DAD on the router(s) to prime a neighbor cache entry works perfectly fine for that situation. I also think that we shouldn't break things by design, and the address-dependent DAD multicast groups are a feature both in terms of limiting flooding as well as improving privacy, even if neither of these two materializes in common setups. Which of these matters more is of no impact for DAD gleaning since it happens to work out to a good solution for both. It *does* break for networks with badly configured multicast, but I believe this is an acceptable caveat -- what we're trying to fix here is a delay in establishing communication, so the failure case is that this delay remains. I'd argue this is an acceptable result of an incompatible multicast configuration made out of either ignorance or error. I'm also confident enough in saying I don't believe any relevant switch or router default configurations include such broken multicast snooping config. If it's broken, it's something the operator broke. I'd even agree with you that operators are well-advised to not enable multicast snooping in most cases, so it keeps being broadcast. Exceptions prove the rule. Cheers, -David From nobody Tue Jul 23 07:38:39 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DA6120043 for ; Tue, 23 Jul 2019 07:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=gashinsky-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJCa0Ez65xcp for ; Tue, 23 Jul 2019 07:38:35 -0700 (PDT) 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 A4F8F120072 for ; Tue, 23 Jul 2019 07:38:35 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id k8so82363831iot.1 for ; Tue, 23 Jul 2019 07:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gashinsky-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vo/ZuwKCIJ80bYnF5QIPMwSUqUrz9Ims7VOyEt1kbjc=; b=B3Y7iQZhgimm1Rn10HLuUJMZtg64wL2sFx4msDuP3cNsFe/HA201Osx+6heq2g+HR/ iXSz9PzCGI/RkxSyJ6ts1y2UNWwt/erGyWW7jhpvEYXq0F1BnRQkX2jIXG8ctbOvegnd fxWqNbpZ+oPLuITej+NXzdSjkhP4PRXTZmusaiClFpwaeskSdcaVBYTY1kwUvLuvjLjF 5JzmH4NRcktpMYT1SL/kSmJd63TnEp14ii6kGxYDedLY4nQf4M23hDps31XgIX06n8fF cIi1/sNvzNVil/fkjih6TTNu/iPUkuC+FcEiegpoyxsmU2BFT2YwesAeNuo/zSU7K138 nKtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vo/ZuwKCIJ80bYnF5QIPMwSUqUrz9Ims7VOyEt1kbjc=; b=gOLsy6CDzYp3TBUEbIVt8c0jNMan+mUn5wCNnuhgjsFlJahcw7QonD9miXUtJxtc+G 8060x4nOD96mtYCHuXJU1yMR05QjCc0Ag7jqq7mC0X3PB9RqMNaPIFS/w75qNj+/6xAY 342kkH3oWopeX+hUTY1tAOJB+GUDS2ZLcNZgmhDrU3DWRov3NnzdkadprcVs3k9srdCH 2wZLO2F1WYp5esRSA3+RM+aLPcaBJosVquKjybUwZM2+7C+axsU+zLiGiSZJQbzMPz/0 qaEe461GN/dRrnKPTAd3R2nh6x9beLe73BZOAIfmkjvTE//4JsQp/ax8LQ7RPOgiCKQw 2Q1Q== X-Gm-Message-State: APjAAAXpCuautVkpA+mqe+8dgi4XZWk03l020Qt2KOYpmdOQL6LNwIZu zD1hP1TWMtCjFo/+InS9w9Q= X-Google-Smtp-Source: APXvYqx74uhottaNw5widOjAPWl1QsT9vnAoSWTR8oYFPYXNDKSWv6xshu1AYjl89E6c67VFdKwcmQ== X-Received: by 2002:a02:242a:: with SMTP id f42mr78909965jaa.42.1563892714955; Tue, 23 Jul 2019 07:38:34 -0700 (PDT) Received: from [172.20.4.124] ([72.138.80.131]) by smtp.gmail.com with ESMTPSA id e26sm36862273iod.10.2019.07.23.07.38.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 07:38:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-19A80965-F257-4D8E-9B66-F635B1EE1BDB Mime-Version: 1.0 (1.0) From: Igor Gashinsky X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Tue, 23 Jul 2019 10:38:33 -0400 Cc: IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: 7bit Message-Id: <0A775E0D-E4AB-4391-8B6D-EB9D516A35CF@gashinsky.net> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> To: JORDI PALET MARTINEZ Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:38:37 -0000 --Apple-Mail-19A80965-F257-4D8E-9B66-F635B1EE1BDB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 as well.=20 -igor > On Jul 23, 2019, at 09:59, JORDI PALET MARTINEZ wrote: >=20 > +1 > =20 > Regards, > Jordi >=20 > @jordipalet >=20 > =20 >=20 > =20 > =20 > El 23/7/19 9:14, "v6ops en nombre de Lorenzo Colitti" escribi=C3=B3: > =20 > On Tue, Jul 23, 2019 at 4:29 AM Fred Baker wrot= e: > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group d= raft? > =20 > I support adopting this draft as a WG document.=20 > _______________________________________________ v6ops mailing list v6ops@i= etf.org https://www.ietf.org/mailman/listinfo/v6ops >=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-19A80965-F257-4D8E-9B66-F635B1EE1BDB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 as well. 

-igor

On Jul 23, 2019, at= 09:59, JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> w= rote:

+1

 

Regards,

Jordi

@jordipalet

 =

 

 

El 23/7/19 9:14, "v6ops en nombre de Lor= enzo Colitti" <v6ops-bounces@ie= tf.org en nombre de lorenzo=3D40google.com@dmarc.ietf.org> escribi=C3=B3:=

 

On Tue, Jul 23, 2019 at 4:29 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:<= /p>

Do we agree to take draft-linkova-v= 6ops-nd-cache-init as a working group draft?

 

I support adopt= ing this draft as a WG document. 

_____________________________= __________________ v6ops mailing list v6op= s@ietf.org https= ://www.ietf.org/mailman/listinfo/v6ops


********= **************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<= br> The IPv6 Company

This electronic message contains information which may be privileged or conf= idential. The information is intended to be for the exclusive use of the ind= ividual(s) named above and further non-explicilty authorized disclosure, cop= ying, distribution or use of the contents of this information, even if parti= ally, including attached files, is strictly prohibited and will be considere= d a criminal offense. If you are not the intended recipient be aware that an= y disclosure, copying, distribution or use of the contents of this informati= on, even if partially, including attached files, is strictly prohibited, wil= l be considered a criminal offense, so you must reply to the original sender= to inform about this communication and delete it.

________= _______________________________________
v6ops mailing list
v6ops@ietf.orghttps://www.= ietf.org/mailman/listinfo/v6ops
= --Apple-Mail-19A80965-F257-4D8E-9B66-F635B1EE1BDB-- From nobody Tue Jul 23 07:51:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A114F120355; Tue, 23 Jul 2019 07:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 I1gy5Nw0eGkT; Tue, 23 Jul 2019 07:51:06 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 2608112035B; Tue, 23 Jul 2019 07:50:40 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id l9so42171574qtu.6; Tue, 23 Jul 2019 07:50:40 -0700 (PDT) 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:content-transfer-encoding; bh=5zCN6Tz10FtgTi5H1n7cC/tMb+pzRfqphJ55Z56/PuE=; b=tLLz9emoDJqr6iXVN4FOvwd6pVupjvNJ/hU4k1F5vDNc9jNpOQFKXmWytHQTVW5HJr 6bUqu3Hcld6xsrAjrNqI0eRKaep8kABvrZqCRBiCVb5ORzHjzNVIj/BUirFq5FHyLlqu 5mz6t2+R1dPyfY3/oNgrmNEIIHXRLn3y9ONR7oW16K8NbKdk591W6OAzrCm3yVQT2QIY m6lsY26a82MgV0wYRD7PTlXmKU0v3HSjHv6On8b7lICEtBRmyhJDsv/JKl0EMiDe1AMy BsUfdx1uvRQspiY3R5aTzToySgtiC01RD6oyjGi0nDY/cGLjzUrAyhWfqygCGJd2gOox Maqg== 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=5zCN6Tz10FtgTi5H1n7cC/tMb+pzRfqphJ55Z56/PuE=; b=kcJ6bDNxOx766NFfDID4QIU/EwJZQitC2CvPEYErkdPcqTQGkt8w254MbzAjnhDqXt i913Y5r8ra4HlyPsJa0CF8IkHXdTuaQF8vL/tbXK5LkasauFcyrVrqTtPlN0ZQW7IY+Z QMhqOyDEUHzyyd9B4mLyh/vM69MI2gA418AMVSlps7fTvFDXzbUD/gBsGifW2kmVsPK/ 7iqkSf42x5hqhK0tKjxad0Mc6z7p18OxG8ybHt1XxZKHLzwCbaFjmnKSDUxoYy9pkKVg ZWoFThLsOIkRDjvWZYxxStTVa06GIyAw0D3tY2BCbRbQLfk5NXpUyQYJCKcnh0HM+iZG bRcA== X-Gm-Message-State: APjAAAUf5G1gPKx4Lil7VN2aLRy1vFHSFTDKcnMEIjCZFRi3xXw0t41y XK8NxfTa43E04uRq7ivYW5GD/aFo0M+82OQAD8Q= X-Google-Smtp-Source: APXvYqyj/39w7Bv2l2QG8kBtlGTeFPnNA4/7ya6AwZalkVTZpcNMlBG1MVZZ6vhxGU56A4eOs6FaAKIoiUmjWBY3es4= X-Received: by 2002:ac8:ce:: with SMTP id d14mr53932701qtg.149.1563893439028; Tue, 23 Jul 2019 07:50:39 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> In-Reply-To: From: Jen Linkova Date: Wed, 24 Jul 2019 00:50:27 +1000 Message-ID: To: Brian E Carpenter Cc: Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:51:08 -0000 On Tue, Jul 23, 2019 at 9:39 PM Brian E Carpenter wrote: > 3) I'm not convinced it needs to update 4861. If what it does is explain = the conditions in which an RFC2119 "SHOULD" should be ignored, that is *not= * an update to the standard. To me it sounds exactly like a Best Current Pr= actice. That's was my impression as well, glad to see I'm not alone ;) "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." So I guess as long as we document the case and implications, recommending routers to have a configuration knob to ignore "SHOULD" is not violating RFC4861. Probably getting the document reviewed by 6man WG would make sense as well to ensure that implications are understood. > On 23-Jul-19 20:29, Fred Baker wrote: > > In yesterday's meeting, the sense of the room and a discussion of chart= ers at the mike suggested that draft-linkova-v6ops-nd-cache-init should bec= ome a working group draft. Doing so will require 6man to agree to let v6ops= suggest specific changes to RFC 4861 under the rubric of "operational solu= tions", as discussed in the draft and https://datatracker.ietf.org/meeting/= 105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-= operational-considerations-00; the argument for not kicking those out to 6m= an is that the authors of RFC 4861 are no longer in a position to approve e= rrata to it, which would be the other obvious approach (I'm not sure that's= true of Erik Nordmark, but whatever). It would also need to be considered = to update RFC 4861. > > > > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working grou= p draft? > > > > Ron and I look through this thread next week and take the necessary act= ion, whatever the outcome might be. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > . > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Tue Jul 23 08:35:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFFC120442 for ; Tue, 23 Jul 2019 08:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 1ZR0tD_9yhD4 for ; Tue, 23 Jul 2019 08:34:59 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43DD12040A for ; Tue, 23 Jul 2019 08:34:58 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2B1B241B58 for ; Tue, 23 Jul 2019 17:34:57 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1C867406BC; Tue, 23 Jul 2019 17:34:57 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 0D5552202B; Tue, 23 Jul 2019 17:34:57 +0200 (CEST) Date: Tue, 23 Jul 2019 17:34:56 +0200 From: Gert Doering To: David Lamparter Cc: Gert Doering , Mark Smith , v6ops list Message-ID: <20190723153456.GU60824@Space.Net> References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> <20190723143057.GC258193@eidolon.nox.tf> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="otRuG/a1bzWynmKC" Content-Disposition: inline In-Reply-To: <20190723143057.GC258193@eidolon.nox.tf> X-NCC-RegID: de.space User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 15:35:10 -0000 --otRuG/a1bzWynmKC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 23, 2019 at 04:30:57PM +0200, David Lamparter wrote: > I'm also confident enough in saying I don't believe any relevant switch > or router default configurations include such broken multicast snooping > config. If it's broken, it's something the operator broke. =20 Yeah. That's what one would expect. Like "protocols igmp-snooping" either being off-by-default *or* not breaking IPv6. But hey, out there, we have the reality zone. Vendors will break *anything* that is not immediately obvious in their "we tested this with IPv4 unicast!" test sets. So yeah, if all this IPv6 multicast stuff *works*, it's not hurting much, but it breaks often enough, across enough gear of enough vendors, that=20 it's actually making IPv6 more brittle than IPv4. 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 --otRuG/a1bzWynmKC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl03KR4ACgkQ31bAZeTO f8Uaiw//SDZJCvwrY8H2yxDleb3Kwsjstx6JdO/rgflMRylr1l8JAeOdMVAsXP+S cMQ4XOWGI8NxTbeGnYQ3aJ1Nj67rMrqWJwWu6rov0R8VN4QD0ExJ2a+68HlnpK+M fjOVbPoxQE5jZ0zE2+7r+S/eIuug0GCDgcHoHJnJjqPbesnwgg4fdYwomPd5Dy2D CvZh74xav7ykMdm18fThWWPAiY/O6W+VD0HK1usSDfp7HGrDBNomxVjYJDXVMriO 5QiAWmq1a3XZTsXp93LV2ILLBhYyzZcsXHJf0bn6As5S/sAP2hjp2kgZtUEBES8+ 9LZu/jzBE+Krd5I2sFMKb5kzrf2IdwljigfguLeefdsyEQ8jBn7evBkMbjHZTEgO R8hx9FyeS6CaewxCwCHBhAyNY410iqbDONbfgnTb+fEyGvA8CYeynQ8/9cB4He48 /X82/21zsEXGQh/Kam9G5+3Uunk8K6rlpsjnpiHDrRSoqD1+HZaRxqTK5GdT7/O4 s8kPOnO9mg8hYzWKVxdhgUXXRmwyfQDvHjxLw64IXo2G4B0oNU/VETTQKXSrnqEW Lw9vFXgkXe66y2JXT2tAheJ/fcoz0G2nhYaP96Uivh1iR7w7rN6bD9eMR0hvn7q2 m/0gX0XCNqyTXkmEMIwLaNglHJllM2l2M/ceFZON70eqk48ps0I= =sXzk -----END PGP SIGNATURE----- --otRuG/a1bzWynmKC-- From nobody Tue Jul 23 10:50:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD04C120702; Tue, 23 Jul 2019 10:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 71FvPnFw9--G; Tue, 23 Jul 2019 10:50:05 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F050120700; Tue, 23 Jul 2019 10:50:05 -0700 (PDT) Received: from [192.168.0.131] (unknown [154.145.3.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1CD84850AD; Tue, 23 Jul 2019 19:50:02 +0200 (CEST) To: Lorenzo Colitti Cc: Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <894233ad-f403-5817-7dd5-07c19b0b9cdd@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <1dd3b5ed-4895-4446-cbb7-720dc62f6ecc@si6networks.com> Date: Tue, 23 Jul 2019 18:36:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 17:50:08 -0000 On 23/7/19 12:07, Lorenzo Colitti wrote: > On Tue, Jul 23, 2019 at 5:07 AM Fernando Gont > wrote: > > My understanding is that, if anything, it is the relevant working groups > that maintain and accept/reject errata, rather than their authors alone. > (In fact, at the point the corresponding RFCs (at internet-draft stage) > became wg items, they became adopted by the relevant wgs). That's why > draft-ietf documents reflect the opinion of the relevant wg, rather than > that of the authors. > > The assertion from Warren was that an erratum would not be approved > because such an erratum would be clearly changing the intent of the > original document, making it say the opposite of what it used to say. So... is this kind of a polite way of saying that we have to ignore the charter because 6man would not agree to work on a document that is meant to address what is deemed as a real world problem? If so, rather than circumvent the charters, whichever wg is relevant (6man in this case), should do what must be done. FWIW, I had a similar feeling with addressing the slaac-renum problem, which does have an operational workaround (deployment advice and tweaking protocol knobs), but that would also benefit from protocol updates (not necessarily all the ones we proposed). > If a protocol needs to be updated, so be it. But that, I understand, is > what 6man is for. I can see myself reasons for wanting to do it in > v6ops. But unless I'm missing something, that's the charter of 6man, > rather than of v6ops. > > > And it is in the charter of v6ops to suggest those modifications: > > ====== > 1. Solicit input from network operators and users to identify > operational issues with IPv6 networks, and determine solutions or > workarounds to those issues. > ... > IPv6 operational and deployment issues with specific protocols [...] > are the primary responsibility of > the groups or areas responsible for those protocols [...] > However, the v6ops Working Group may provide input to > those areas/groups, as needed, and cooperate with those areas/groups in > reviewing solutions to IPv6 operational and deployment problems. > ====== > > This is an operational issue in IPv6-only networks, and this draft is > about determining a solution and providing 6man with input on how to > resolve it in the protocol. While skimming the doc, it would seem to me that the document aims at updating the protocol spec (even when it's "Informational"), rather than providing input to 6man. If the problem is seen as a real problem (I'm not taking a position in that respect), this document should be std track, update the ND spec, and be done in 6man. (And yes, 6man should address protocol problems, rather than being guardians that prevent folks from solving them). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 23 11:00:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030F312073E for ; Tue, 23 Jul 2019 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dm0cZE8fECn for ; Tue, 23 Jul 2019 11:00:18 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 BE68B120743 for ; Tue, 23 Jul 2019 11:00:17 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id s15so17932970wmj.3 for ; Tue, 23 Jul 2019 11:00:17 -0700 (PDT) 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=QYoyGg4w4kN8GyOCS6p+iOLw0nlyzsAYMe3GSeMo9n0=; b=p9P+hthHoOJK1v4gcCOA8azn5RDm7EAfJgMFp1xLcWLiXp+7XWiTJncO76Wn++U48Q 7xV93jXPFVgJ0ywnt6YFM/25kKdyUitW9ma2cBzzeztILY2NoPWeSbJJV3jx5Y0r0Iyo Yypwojt2AyjGtJMsSOhiDM8xqq8C58L+g/gKTXClWs/fepQ9lTNrDDmHATowASxau+Rt rwKYLaYuHeXzI0kGUOitFky2sbZ/wA3xGbwnpHjSc/Jy2D7Qip/V7gfjsnuQJiVKvIK9 ipEquk98gfnuyLkbjagmW6yDT0n4sn3rK6ouRITZmpK6dNgyFWjD7Qxa7vzSS0v1hy1+ CLzQ== 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=QYoyGg4w4kN8GyOCS6p+iOLw0nlyzsAYMe3GSeMo9n0=; b=RMwDX5zIVLqt04v55T80pY4uocD22TNpksJviCXQQDtUAj6QAlzCynI4MP/w60jiBo d/evyIJ82VaJ1Rr/+PmgEiBQw4JrmWqURjpLxJEcUPUz1I1ZYWeVEGckO2XKd6a8amCc HXmIpnjlU9h9/m1V+9w/268xT4v4x1ifXBCcphb82w2A1VOYxG5Hl+1PYLuFHzroti3c yQbqccPkT7oLq13gV5sEamimacLqunIu3f9hBtNVGQumwBzrydkhRuSEfXZBj4IPhkuw ywSTzhT6yeJ4zaIvpJ+HiLKiQ0wpniP8zwjIw/64WBhnGoQ9eZ9N8Q6RulhidsW3L+gI Xh2Q== X-Gm-Message-State: APjAAAV7/iPPQHpAB8ROWVhbVHFgnHHpp86iH/Tu7xztjC77DvSLKXbn CAj9LEJsw7xLg22qUrD6M7zIzUm5TkZstfdv+RQRLA== X-Google-Smtp-Source: APXvYqybDRjcd9v+/I9vLV8yEF0xMffZU2TS3JNz3LVumDWIO6mWM9S/+HK5jJIOsnij1fJVqPDS0q4I3BBwu1WQyWU= X-Received: by 2002:a05:600c:23d2:: with SMTP id p18mr67715307wmb.108.1563904815994; Tue, 23 Jul 2019 11:00:15 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <894233ad-f403-5817-7dd5-07c19b0b9cdd@si6networks.com> <1dd3b5ed-4895-4446-cbb7-720dc62f6ecc@si6networks.com> In-Reply-To: <1dd3b5ed-4895-4446-cbb7-720dc62f6ecc@si6networks.com> From: Lorenzo Colitti Date: Tue, 23 Jul 2019 14:00:02 -0400 Message-ID: To: Fernando Gont Cc: Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary="000000000000059c4d058e5cf742" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 18:00:20 -0000 --000000000000059c4d058e5cf742 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 23, 2019 at 1:50 PM Fernando Gont wrote: > > The assertion from Warren was that an erratum would not be approved > > because such an erratum would be clearly changing the intent of the > > original document, making it say the opposite of what it used to say. > > So... is this kind of a polite way of saying that we have to ignore the > charter because 6man would not agree to work on a document that is meant > to address what is deemed as a real world problem? > No. It was a way to say that an erratum is not the way to address this issue. --000000000000059c4d058e5cf742 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2019 at 1:50 PM Fernando = Gont <fgont@si6networks.com= > wrote:
> The assertion from Warren was that an erratum w= ould not be approved
> because such an erratum would be clearly changing the intent of the > original document, making it say the opposite of what it used to say.<= br>
So... is this kind of a polite way of saying that we have to ignore the
charter because 6man would not agree to work on a document that is meant to address what is deemed as a real world problem?
No. It was a way to say that an erratum is not the way to addre= ss this issue.
--000000000000059c4d058e5cf742-- From nobody Tue Jul 23 11:37:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F204D12077D; Tue, 23 Jul 2019 11:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 UUarHIU0CsLK; Tue, 23 Jul 2019 11:37:44 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BF6120819; Tue, 23 Jul 2019 11:37:44 -0700 (PDT) Received: from [192.168.0.131] (unknown [196.85.157.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7CBFD850B1; Tue, 23 Jul 2019 20:37:40 +0200 (CEST) To: Brian E Carpenter , Fred Baker , IPv6 Operations Cc: 6man Chairs <6man-chairs@ietf.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> Date: Tue, 23 Jul 2019 18:59:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 18:37:55 -0000 On 23/7/19 12:39, Brian E Carpenter wrote: > 1) Yes, we should *obviously* do this. > 2) If the charter prevents that, fix the charter. I'm all for fixing problems and getting stuff done. And, if there's no other way than fixing the charter, so be it. However, it would seem to me that, the "bug" here is that we're defaulting to "6man wouldn't get this done, so let's do it elsewhere". IMO, should be willing to maintain its protocols, improve them, and fix problems where necessary. If a BCP is to go against the protocol spec recommendation for the general case, that's an indication that the protocol should be updated. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Jul 23 11:38:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADDE120811; Tue, 23 Jul 2019 11:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 iNoTk6kBQvSG; Tue, 23 Jul 2019 11:37:46 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5308612075B; Tue, 23 Jul 2019 11:37:46 -0700 (PDT) Received: from [192.168.0.131] (unknown [196.85.157.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 091E580B87; Tue, 23 Jul 2019 20:37:43 +0200 (CEST) To: Lorenzo Colitti Cc: IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <894233ad-f403-5817-7dd5-07c19b0b9cdd@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <6a1de1ae-06f4-9233-4ed1-440c5303343f@si6networks.com> Date: Tue, 23 Jul 2019 19:01:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 18:37:56 -0000 On 23/7/19 12:07, Lorenzo Colitti wrote: > On Tue, Jul 23, 2019 at 5:07 AM Fernando Gont > wrote: > > My understanding is that, if anything, it is the relevant working groups > that maintain and accept/reject errata, rather than their authors alone. > (In fact, at the point the corresponding RFCs (at internet-draft stage) > became wg items, they became adopted by the relevant wgs). That's why > draft-ietf documents reflect the opinion of the relevant wg, rather than > that of the authors. > > > The assertion from Warren was that an erratum would not be approved > because such an erratum would be clearly changing the intent of the > original document, making it say the opposite of what it used to say. Indeed, it shouldn't be an erratum, but an ID/RFC that formally updates the spec. Nobody should be scared of that. In fact, I guess that's why there is something called "6man". -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 23 12:08:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD311200CC; Tue, 23 Jul 2019 12:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-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 XFyXB37NwKOn; Tue, 23 Jul 2019 12:08:28 -0700 (PDT) Received: from clarinet.employees.org (unknown [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906B21206B2; Tue, 23 Jul 2019 12:08:26 -0700 (PDT) Received: from astfgl.hanazo.no (dhcp-8137.meeting.ietf.org [31.133.129.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 8C2A44E128F6; Tue, 23 Jul 2019 19:08:25 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 332AF194D804; Tue, 23 Jul 2019 15:08:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Ole Troan In-Reply-To: Date: Tue, 23 Jul 2019 15:08:23 -0400 Cc: Brian E Carpenter , Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> To: Jen Linkova X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:08:30 -0000 > wrote: >> 3) I'm not convinced it needs to update 4861. If what it does is = explain the conditions in which an RFC2119 "SHOULD" should be ignored, = that is *not* an update to the standard. To me it sounds exactly like a = Best Current Practice. >=20 > That's was my impression as well, glad to see I'm not alone ;) >=20 > "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label." >=20 > So I guess as long as we document the case and implications, > recommending routers to have a configuration knob to ignore "SHOULD" > is not violating RFC4861. > Probably getting the document reviewed by 6man WG would make sense as > well to ensure that implications are understood. We have decades of experience with gratuitous ARP in IPv4. Updating IPv6 = ND to also support (and make it recommended practice) gratuious ND seems = sensible. I believe this requires an update to RFC4861. And I don't see any reason = why that work shouldn't happen in 6man. Best regards, Ole (6man co-chair). From nobody Tue Jul 23 12:13:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E73D1202CD for ; Tue, 23 Jul 2019 12:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJBMecFlTx-1 for ; Tue, 23 Jul 2019 12:13:09 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450: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 1147A1200CC for ; Tue, 23 Jul 2019 12:13:09 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id y4so44358846wrm.2 for ; Tue, 23 Jul 2019 12:13:08 -0700 (PDT) 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=c8CcK37Day3VNEt/SMg1ao75xg7MMrVWRQbZ1y8K4oU=; b=cMgXwBuGHX+H+3/7GzmtJIMKBFh2tCZTatv1K2o4S63VEnYZoidLAikZwrD69Q+q7y rIErjvE2QW5yXiHk911VBTnafFeL5OH0aYIFAuHDnqIdfufFkelDtdzxgOgy1aBxftIn Uy+vzStisVVa++ImDogWK5rER4eycPsgmcgH8vFuUYHvCJqq8o45Et0djm8UgIGmhhxZ i3WCNVf84RkClk72CyjN3JUX2ZNpSQZMoAMYEh2eJgUVjD2l2WmZFyGBK1DOLh9cmsd3 +FzJvMpxf1AHf8TOehMYPNTpVJczbwt6Jqw+QU6fNMHWg0aNtBc9AVlFYybUMQpOzsjR SZAg== 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=c8CcK37Day3VNEt/SMg1ao75xg7MMrVWRQbZ1y8K4oU=; b=JVg+4/EDax6aT7US26eMkVvG6JTQ8uoLG+K5JBmSBQlhcGGs6R2XgbTY8A+5hjBdsV 5DdVzlOoJ+rHi2NHcbPI1IXRzlWlwoa/zLwwfisPUzTOKIKFcVE80bU/1GrGC8Ef9dy7 rObw8vKY/GVtJ/PdmzEaeSSXcMbqYTDIBcLFVab3ovxG8Dl3MZjr3dfdV9yFPHGhwAt/ DQX2fqvSbk7Po/+A7Z5XisFel+9ntyv94gup3EHIQc640FEiGfsWKHi9dVyqfYL2npjO IR6cldof4sEYVtQWfkyQaZ45yW6dag9pEQQ6+mlndgcc7+c9kHebzfOcIPIFaGh7PoMS lSuA== X-Gm-Message-State: APjAAAUpjOMbMrCUZ3v2RdeyXrUChbKiLvSwyTr7XzFAzIXt8nHSNBp9 m5iF051NwnoMgrhmM1huZ1l5uXezX1CwZ6wcRFdtRg== X-Google-Smtp-Source: APXvYqx3QxRJZ2Tp6awVQGtQSaaxo+X6KdTTB/u3dkaxVlZOdLqSg9VtyBa/TzesEUt4jFGJ8QyPEMlD3Aq8WPrINj0= X-Received: by 2002:adf:8183:: with SMTP id 3mr83133786wra.181.1563909187388; Tue, 23 Jul 2019 12:13:07 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org> In-Reply-To: <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org> From: Lorenzo Colitti Date: Tue, 23 Jul 2019 15:12:53 -0400 Message-ID: To: Ole Troan Cc: Jen Linkova , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary="00000000000093a87f058e5dfb30" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:13:11 -0000 --00000000000093a87f058e5dfb30 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 23, 2019 at 3:08 PM Ole Troan wrote: > I believe this requires an update to RFC4861. And I don't see any reason > why that work shouldn't happen in 6man. > Yup. I'd recommend we first adopt this draft to actually consider the operational issues and we come to consensus on what the best approach is. Once we have a conclusion, the standards change can go to 6man. Clearly 6man should review the operational document before it gets published. --00000000000093a87f058e5dfb30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2019 at 3:08 PM Ole Troan= <otroan@employees.org> w= rote:
I believe this requires an update to RFC4861. And I don= 9;t see any reason why that work shouldn't happen in 6man.

Yup. I'd recommend we first adopt this draft to= actually consider the operational issues and we come to consensus on what = the best approach is. Once we have a conclusion, the standards change can g= o to 6man. Clearly 6man should review the operational document before it ge= ts published.
--00000000000093a87f058e5dfb30-- From nobody Tue Jul 23 12:19:44 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79CF12088D; Tue, 23 Jul 2019 12:19:34 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEDv5Nl9KvfC; Tue, 23 Jul 2019 12:19:31 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 4AE471208BD; Tue, 23 Jul 2019 12:19:29 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from ) id 1hq0Jp-0045AJ-QI; Tue, 23 Jul 2019 21:19:26 +0200 Date: Tue, 23 Jul 2019 21:19:25 +0200 From: David Lamparter To: Fernando Gont Cc: Brian E Carpenter , Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Message-ID: <20190723191925.GF258193@eidolon.nox.tf> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:19:42 -0000 On Tue, Jul 23, 2019 at 06:59:23PM +0100, Fernando Gont wrote: > On 23/7/19 12:39, Brian E Carpenter wrote: > > 1) Yes, we should *obviously* do this. > > 2) If the charter prevents that, fix the charter. > > I'm all for fixing problems and getting stuff done. And, if there's no > other way than fixing the charter, so be it. > > However, it would seem to me that, the "bug" here is that we're > defaulting to "6man wouldn't get this done, so let's do it elsewhere". The discussion I see here is that we've located an operational issue with the IPv6 neighbor cache on routers, we have several candidates for fixing it, and each of these may or may not need a protocol change to go through 6man. Discussing whether any particular working group "gets things done" seems tangential to the question at hand. > IMO, should be willing to maintain its protocols, improve them, and fix > problems where necessary. > > If a BCP is to go against the protocol spec recommendation for the > general case, that's an indication that the protocol should be updated. Although I don't write the neighbour management code, I do write code that operates routers and I have absolutely no concerns in understanding that a particular "SHOULD" statement has turned out to be a bad choice for the specific situation of first-hop routers. Whether this is a specification change, to me, is decided by the intent. The intent under consideration here is: When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. The intent I see is that in most cases there's no point in having devices consume memory, and the "SHOULD" is correct behaviour for hosts. Routers *DO* "need to create an entry if none exists". I don't see a conflict with 4861's intent, which I take as "don't open yourself to DoS attacks". The router /will have the neighbor cache entry anyway/, just with a delay, later, and the resulting annoyance. 4861 just failed to invoke the magic 8-ball correctly to make the authors omniscient and recognize the specific circumstances under which this SHOULD is maybe not the best idea. This is implementation guidance based on operational experience. Just write it down and get it out there. -David From nobody Tue Jul 23 12:21:53 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76BF120893; Tue, 23 Jul 2019 12:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 5xH29Jg5mwYB; Tue, 23 Jul 2019 12:21:34 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 C1AEA1208A5; Tue, 23 Jul 2019 12:21:32 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id ay6so21006666plb.9; Tue, 23 Jul 2019 12:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=lBBiRgN9axICREb7NYxege13PXRtxIZw6B79NC9LVgs=; b=ASQArSCnhwBnrNUjf8cvVhU+x1wmyrRTWe8S/JAcoK15VuorxRBAqtmy+IDfN5tE30 d1L5nAGvR6EwW/2u6+H8QpUszTYqJcb7tBzCc5puVclw6x0nNisgpSwe2f/DUg3hG7m0 JbhcH1f1p76ZXLN5N8pzdtTjjt3MSvwKyydi5tFO7E+JpOjnv7cQXF75shyjEBaCPVVq Rz2y5BqVKBlW0N0g7x+aaVBv+tLdrZIghN0FB9ghrOMAXaY9JzKolSAoW5hg+SVPtWdh fHW4fLi/EUinLm3HZN9zEc00KsVMLRVQctcWyvskDC0NKVnxEJLyosTTR7JjXYDLcLbw H/dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=lBBiRgN9axICREb7NYxege13PXRtxIZw6B79NC9LVgs=; b=bdx3JRDsJ80vHcenfjS8JYQLxihT8AKfMYhWwICgKX+HyD43Ay+uQxq9WlqC5NgSI9 f4glHRThgnmQCGyvwGlKmhjMqKSOydTwq7PbfTilZW8y+U0xvwzg86QccyXJW06GXv22 kQ+yshpK9klI6yl86UivGPOJpiyKWCxdXQTOcZ0sNFE4NoNXizHPVyzWwNF792X7g4Cf wx78ga1lJNNYsdeicDIy1d0NjMpDLyhtSOKEIqUYvSV8HmVnk+H6M8wEN9Ar6UHjMiOB i7Y7lpT3opMD+vCDJFoBLZ5INb+AlvJrj//gP3bqLWSYlaJZYZZcauVnKeICahjZ1iuO EP+A== X-Gm-Message-State: APjAAAUE4BY4XH7CsEtYOqxhz+g8OSvovhseDdMM3DoJl/vrDvIOa3fO 6d9ndcW7zOqeUgQOPLRetmKBpOZKGds= X-Google-Smtp-Source: APXvYqxDChJLMuKej2hoeeg6KJ8pjudlnIUzqIWNCiRU20kqo6kR6efE2ztm4E19iORJ+RL9JjHhNA== X-Received: by 2002:a17:902:8548:: with SMTP id d8mr82325889plo.100.1563909692155; Tue, 23 Jul 2019 12:21:32 -0700 (PDT) Received: from [172.26.34.184] ([76.14.1.154]) by smtp.gmail.com with ESMTPSA id u69sm49881841pgu.77.2019.07.23.12.21.31 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 12:21:31 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-46F66E43-DC4D-473E-A07A-C3A3A7051994 Content-Transfer-Encoding: 7bit From: Fred Baker Mime-Version: 1.0 (1.0) Date: Tue, 23 Jul 2019 13:35:43 -0400 Message-Id: <2BF50E6F-82C9-42D4-BE9E-3FF11FFDF137@gmail.com> References: Cc: Brian E Carpenter , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> In-Reply-To: To: Timothy Winters X-Mailer: iPad Mail (17A5534f) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:21:48 -0000 --Apple-Mail-46F66E43-DC4D-473E-A07A-C3A3A7051994 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That might be an interesting survey, if only to validate the draft. It would= also give a heads-up to those developers, though, and give the working grou= p some operational experience in the case(s) of those that already implement= something like it. Sent from my iPad > On Jul 23, 2019, at 8:02 AM, Timothy Winters wrote:= >=20 > =EF=BB=BF > I also think this should be working group draft, as I mentioned at the mic= I'm happy to help survey what current implementations are capable of. >=20 > I also agree with Lozenzo last statement. >=20 > ~Tim >=20 >> On Tue, Jul 23, 2019 at 7:39 AM Brian E Carpenter wrote: >> 1) Yes, we should *obviously* do this. >> 2) If the charter prevents that, fix the charter. >> 3) I'm not convinced it needs to update 4861. If what it does is explain t= he conditions in which an RFC2119 "SHOULD" should be ignored, that is *not* a= n update to the standard. To me it sounds exactly like a Best Current Practi= ce. >> 4) In any case, if the IETF rules are alleged to prevent doing the obviou= s right thing, the IESG can vary the rules, as allowed by BCP9. >>=20 >> Regards >> Brian Carpenter >>=20 >> On 23-Jul-19 20:29, Fred Baker wrote: >> > In yesterday's meeting, the sense of the room and a discussion of chart= ers at the mike suggested that draft-linkova-v6ops-nd-cache-init should beco= me a working group draft. Doing so will require 6man to agree to let v6ops s= uggest specific changes to RFC 4861 under the rubric of "operational solutio= ns", as discussed in the draft and https://datatracker.ietf.org/meeting/105/= materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-opera= tional-considerations-00; the argument for not kicking those out to 6man is t= hat the authors of RFC 4861 are no longer in a position to approve errata to= it, which would be the other obvious approach (I'm not sure that's true of E= rik Nordmark, but whatever). It would also need to be considered to update R= FC 4861. >> >=20 >> > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working grou= p draft? >> >=20 >> > Ron and I look through this thread next week and take the necessary act= ion, whatever the outcome might be. >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > . >> >=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-46F66E43-DC4D-473E-A07A-C3A3A7051994 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPad

On Jul 23, 2019, at 8:02 AM, Timothy= Winters <twinters@iol.unh.edu> wrote:

=EF=BB=BF
I also think= this should be working group draft, as I mentioned at the mic I'm happy to h= elp survey what current implementations are capable of.

I= also agree with Lozenzo last statement.

~T= im

On Tue, Jul 23, 2019 at 7:39 AM Brian E Carpenter &= lt;brian.e.carpenter@gmail.co= m> wrote:
1) Yes, we should *obviously* do th= is.
2) If the charter prevents that, fix the charter.
3) I'm not convinced it needs to update 4861. If what it does is explain the= conditions in which an RFC2119 "SHOULD" should be ignored, that is *not* an= update to the standard. To me it sounds exactly like a Best Current Practic= e.
4) In any case, if the IETF rules are alleged to prevent doing the obvious r= ight thing, the IESG can vary the rules, as allowed by BCP9.

Regards
   Brian Carpenter

On 23-Jul-19 20:29, Fred Baker wrote:
> In yesterday's meeting, the sense of the room and a discussion of chart= ers at the mike suggested that draft-linkova-v6ops-nd-cache-init should beco= me a working group draft. Doing so will require 6man to agree to let v6ops s= uggest specific changes to RFC 4861 under the rubric of "operational solutio= ns", as discussed in the draft and ht= tps://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-c= ache-entries-on-first-hop-routers-operational-considerations-00; the arg= ument for not kicking those out to 6man is that the authors of RFC 4861 are n= o longer in a position to approve errata to it, which would be the other obv= ious approach (I'm not sure that's true of Erik Nordmark, but whatever). It w= ould also need to be considered to update RFC 4861.
>
> Do we agree to take draft-linkova-v6ops-nd-cache-init as a working grou= p draft?
>
> Ron and I look through this thread next week and take the necessary act= ion, whatever the outcome might be.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org<= br> > https://www.ietf.org/mailman/listinfo/v6ops
> .
>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
= --Apple-Mail-46F66E43-DC4D-473E-A07A-C3A3A7051994-- From nobody Tue Jul 23 12:40:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB60E1208F5 for ; Tue, 23 Jul 2019 12:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KasfT5vspOs1 for ; Tue, 23 Jul 2019 12:40:54 -0700 (PDT) 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 E9CDA1208F3 for ; Tue, 23 Jul 2019 12:40:53 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x6NJeoEP024296 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2019 20:40:51 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Sander Steffann Cc: =?UTF-8?Q?Gert_D=c3=b6ring?= , v6ops list References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> <9740316D-61DE-4BF4-87C2-5BCA5575BC27@steffann.nl> <20190723134825.GT60824@Space.Net> <19240B81-04D9-461F-B5C3-5FBDCC104AE0@steffann.nl> From: Nick Hilliard Message-ID: Date: Tue, 23 Jul 2019 20:40:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18 MIME-Version: 1.0 In-Reply-To: <19240B81-04D9-461F-B5C3-5FBDCC104AE0@steffann.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:40:56 -0000 Sander Steffann wrote on 23/07/2019 14:58: > To be absolutely clear: the device connected to those ports is currently switched off "switched off"? What a quaint, antiquated idea :-) Nick From nobody Tue Jul 23 12:49:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A35F120969 for ; Tue, 23 Jul 2019 12:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_HELO_NONE=0.001, 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 eXU-ag9drY-T for ; Tue, 23 Jul 2019 12:49:11 -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 BFEDF120964 for ; Tue, 23 Jul 2019 12:49:11 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id a93so20961622pla.7 for ; Tue, 23 Jul 2019 12:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y0sBjVQv2WB/dzcHC9IvD0spOLG27te2T5UcBAqqg8o=; b=FEB/r9yKXI1VpL03ca6dhwtSIs/52UppUHZCHtTpTFIfhddW9D473Fk0t67Ea8KksZ iCLgsWGmk5us2jUguCJ5ANF5Y0XESXV5Uv+v2Obk3Ec9HekXp8QtytD5fS3ebl6jQiyk iwsGm/WvJj4RT9QY5nI8reK2CAan6QX2J3Mu5mkVcr0L5d4E9dLWOHMLEkuue+CdKHXh xkiu+RmM3Y3KaKwBFiJ2ID3vZSPZ53icqQUf9a3649VfbUbB6GrhW1qoUcjERaQ67CYY NEALM4yE4XvobjvQlCWwS07PH1zGAYEKtayGBQNzRAkCDgxumpEHXNWYqk6xqAw6xNIG 5A4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y0sBjVQv2WB/dzcHC9IvD0spOLG27te2T5UcBAqqg8o=; b=s2ezkepwH7kwaa0coOJtq8dnzk36s4EKq+zDmSILH0mg05mC53QB1jwm8YqVW7vmBv HYjpGuJ1rFFu1/nvNElDj49KGxe3wciLbabUx+pPVNrumKL/rLc3EWGJdbf9UVH6LaRE 0ymIYIyNbW53P547rJTF8o8tb77g6qKMYEzC1fqzhqmXFniVROfKaDyhW3fqJMUoh+n4 X3QEkyu/hCsBOQgoLjnYKkeflbbCvi4DnWESSe5NdugnLgCvkROcp30njIMI9wUWpDl1 1EsQ/yTnNTt5eusA/MbK9QiTyQ/eoPoc5812e8KehsnYvzUCCL7mXjB47mhRroGy4hpH 9JkA== X-Gm-Message-State: APjAAAXJknke7zix+wl02YIDkLpRZnNN5N7wFSrgHykNGsmyAyxD/AA/ k5oZRZ3/2peV/m2dmcxc/gXUFmTh4qQ= X-Google-Smtp-Source: APXvYqw0PUMbsxYXYecdiEA+1K0fH8xEJlQaoq4qYSkk1mAkx1QEEIIl/iK16yLNQoCkVoN9YLCvOA== X-Received: by 2002:a17:902:4283:: with SMTP id h3mr79862036pld.15.1563911351389; Tue, 23 Jul 2019 12:49:11 -0700 (PDT) Received: from [172.26.35.62] ([76.14.1.154]) by smtp.gmail.com with ESMTPSA id b6sm38910600pgq.26.2019.07.23.12.49.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 12:49:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\)) From: Fred Baker In-Reply-To: <20190723143057.GC258193@eidolon.nox.tf> Date: Tue, 23 Jul 2019 12:49:09 -0700 Cc: Gert Doering , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <0A90737A-EF06-41AA-984E-A1ACA975BFC7@gmail.com> References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> <20190723143057.GC258193@eidolon.nox.tf> To: David Lamparter X-Mailer: Apple Mail (2.3566.0.1) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:49:21 -0000 > On Jul 23, 2019, at 7:30 AM, David Lamparter = wrote: >=20 > I'm happy to agree that in most cases multicast will be broadcast Technically, I think it is fair to say that, at least on anything called = "Ethernet", multicast is a filter that reviews received broadcasts. The = message either arrives at an end node or not. Unicast goes to a specific = node or goes nowhere at all, and broadcast is the service that gets it = to all of them. The end node then looks at the first 48 bits received, = and either stores the message or doesn't based on its configuration. = Multicast is broadcast with that filter. Speaking from the perspective of someone who has written several drivers = for such interfaces, it is a little amazing that the configuration of = the multicast filter seems to not be a ubiquitous feature. But = apparently it is not.= From nobody Tue Jul 23 12:52:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6ED120943; Tue, 23 Jul 2019 12:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 rauOLe0MWr6N; Tue, 23 Jul 2019 12:52:00 -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 AF926120914; Tue, 23 Jul 2019 12:52:00 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id d79so31975715qke.11; Tue, 23 Jul 2019 12:52:00 -0700 (PDT) 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=8UGN/C0uETZ1fGGWFh7hLbqczsEB9nGrWkvggWrBYZI=; b=gDDLXcNOSvxTkzZV1PG8i86z98ebKSiWbgRZzvt5VdnMExIIm4Uge3ZB6LeA0iZmaz VgbthHpDDhl+jNouOTKD7Y+povD7JJTeeg83W8PzJgdSCPx5J14mwF1iL4BTfkC4QiPd yn77a20IOFfdXWYOPZBtO8n/VR7IcLu8NcRRlSpxVu8mlISFBPbYX8OHRNNbtr43hkb1 YdawvnUTgZqd9k1cccxT3SeDT9hxrxxLDFJMRpdWSmUkv5N2FVwTwAA3IUoh9cQfWLjv t9k4OSctZuuwi+dQsnodEnlH3aYFSYFBrGLg9AkUNILZtyOYkQB7tR+wMK7kQbjULV7q B6oQ== 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=8UGN/C0uETZ1fGGWFh7hLbqczsEB9nGrWkvggWrBYZI=; b=G3F2lEli/j7UihSsWrvsaGll6sQMFacK3b1KM1nFn7hFhdfH8OSKXdiGRunmd/Ywb0 +XEFGuE5RWlxunD+oWBnE8YXxWpletr8fFhuEvou8l9lopuAXLNIoD/1TY3wc0Rx/X6W s8sJ9LsAHyE7bWAJGed5pPVYEJhBVEniKJRQsy5Xcg9OKJDUqGjfqLv0RwfMRFN8lsRl 0HImcXAcC/shqPCvbMB5oNU7Aobw1lRfpRhxHzX9FUC07oY5ufOL65LggE5CqKEctQNY SX6caH04gp54Hsy59uG97cCeAnKKvppCzR4dcC+C6v9NLS0q20FoSWvAUPHrgnVjuDqq t1og== X-Gm-Message-State: APjAAAUDpFH/Ec3tEDAjZJg8snHYvFrdvAbRZLZONB0OEKK6CAaiz8hp 19Y+6scsBCF5WT1E4Sytpidbwa0bR5BQrkvEEws= X-Google-Smtp-Source: APXvYqz85j8JSnHElROXw3NJg8DCvvPcxZyaJ2dJifxq2vXoxIBSRPFnU4OohllenFWJj8BICarKfsPli5YnEbwr0FU= X-Received: by 2002:a37:311:: with SMTP id 17mr48199259qkd.466.1563911519492; Tue, 23 Jul 2019 12:51:59 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> In-Reply-To: <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> From: Jen Linkova Date: Wed, 24 Jul 2019 05:51:48 +1000 Message-ID: To: Fernando Gont Cc: Brian E Carpenter , Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:52:12 -0000 On Wed, Jul 24, 2019 at 4:39 AM Fernando Gont wrote: > On 23/7/19 12:39, Brian E Carpenter wrote: > > 1) Yes, we should *obviously* do this. > > 2) If the charter prevents that, fix the charter. > > I'm all for fixing problems and getting stuff done. And, if there's no > other way than fixing the charter, so be it. > > However, it would seem to me that, the "bug" here is that we're > defaulting to "6man wouldn't get this done, so let's do it elsewhere". I'm confused. I'm not sure I understand how you came to the conclusion that we are trying fix the protocol in v6ops because 6man wouldn't do this. First of all, main goal of the draft in question is to describe an operational problem and discuss potential ways to deal with it. Based on the analysis the draft currently suggests that there are "valid reasons in particular circumstances when the particular behavior (violate SHOULD NOT and create a STALE entry upon receiving an unsolicited NA) is acceptable or even useful". It does not change ND as a protocol because RFC4861 does allow such behaviour (otherwise it would have said 'MUST NOT') so I'm inclined to say that it's not a protocol change. However I see why it might be seen as a protocol change and I'm willing to either: - write an additional 1-page draft for 6man updating 4861 based on analysis provided in this draft; - get this draft adopted and/or reviewed by 6man - whatever other ways to make sure all appropriate reviews are done, " full implications should be understood and the case carefully weighed" etc ;) > If a BCP is to go against the protocol spec recommendation for the > general case, that's an indication that the protocol should be updated. BCP does not go against the specification for the general case. It seems to me that the protocol discusses a general case and provides rationale for 'SHOULD NOT'. Then we have discovered one corner case which is not even in scope for the rationale provided in the standard. For me it's a typical example of 'valid reasons in particular circumstances when the particular behavior is acceptable'. If we were recommending that any arbitrary host SHOULD create an entry upon receiving an unsolicited NA - then yes, it's a clear indication that RFC4861 needs to be updated. Anyway, as I've said, I have no problem go to 6man with it - but I guess we need to look at all proposed solutions, decide which way we want to go and, if RFC4861 needs to be updated - well, I guess it SHOULD be easy ;) -- SY, Jen Linkova aka Furry From nobody Tue Jul 23 13:21:58 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80295120943; Tue, 23 Jul 2019 13:21:56 -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_HELO_NONE=0.001, 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 4sLmJdLXgGwB; Tue, 23 Jul 2019 13:21:55 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 6321E120932; Tue, 23 Jul 2019 13:21:55 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6NKJa3q014946; Tue, 23 Jul 2019 16:21:52 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2tx8bp1es7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 16:21:52 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6NKLpBX028990; Tue, 23 Jul 2019 16:21:51 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6NKLlU2028915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jul 2019 16:21:47 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 7C6014009E6E; Tue, 23 Jul 2019 20:21:47 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30484.vci.att.com (Service) with ESMTPS id 677384009E6C; Tue, 23 Jul 2019 20:21:47 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 16:21:47 -0400 From: "STARK, BARBARA H" To: "'Lorenzo Colitti'" , "'Fred Baker'" CC: "'IPv6 Operations'" , "'6man Chairs'" <6man-chairs@ietf.org> Thread-Topic: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft Thread-Index: AQHVQTDHi4750L2IvU+TY/UJBnM5XKbYcWuAgAA0TJA= Date: Tue, 23 Jul 2019 20:21:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E238A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.223.206] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E238A3DGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=579 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907230207 Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:21:57 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E238A3DGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCkkgdGhpbmsgdGhhdCBzdGFydGluZyBvdXQgYnkgZGVzY3JpYmluZyB0aGUgcHJvYmxlbSBh bmQgaWRlbnRpZnlpbmcgcG90ZW50aWFsIHNvbHV0aW9ucyBpcyBhYnNvbHV0ZWx5IHRoZSBwbGFj ZSB0byBzdGFydCwgYW5kIEkgYWdyZWUgdGhhdCB0aGlzIGlzIGEgcHJvYmxlbSB3b3J0aCBzb2x2 aW5nLg0KQmFyYmFyYQ0KDQpPbiBUdWUsIEp1bCAyMywgMjAxOSBhdCA0OjI5IEFNIEZyZWQgQmFr ZXIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbTxtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwu Y29tPj4gd3JvdGU6DQpEbyB3ZSBhZ3JlZSB0byB0YWtlIGRyYWZ0LWxpbmtvdmEtdjZvcHMtbmQt Y2FjaGUtaW5pdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQ/DQoNCkkgc3VwcG9ydCBhZG9wdGlu ZyB0aGlzIGRyYWZ0IGFzIGEgV0cgZG9jdW1lbnQuDQo= --_000_2D09D61DDFA73D4C884805CC7865E6114E238A3DGAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m IzQzOzE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCBz dGFydGluZyBvdXQgYnkgZGVzY3JpYmluZyB0aGUgcHJvYmxlbSBhbmQgaWRlbnRpZnlpbmcgcG90 ZW50aWFsIHNvbHV0aW9ucyBpcyBhYnNvbHV0ZWx5IHRoZSBwbGFjZSB0byBzdGFydCwgYW5kIEkg YWdyZWUgdGhhdCB0aGlzIGlzIGEgcHJvYmxlbSB3b3J0aCBzb2x2aW5nLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCAyMywgMjAx OSBhdCA0OjI5IEFNIEZyZWQgQmFrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVkYmFrZXIuaWV0 ZkBnbWFpbC5jb20iPmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRvIHdlIGFncmVlIHRvIHRha2UgZHJhZnQtbGlua292YS12Nm9wcy1uZC1jYWNoZS1pbml0 IGFzIGEgd29ya2luZyBncm91cCBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VwcG9ydCBhZG9wdGluZyB0aGlzIGRy YWZ0IGFzIGEgV0cgZG9jdW1lbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E238A3DGAALPA1MSGUSRBF_-- From nobody Tue Jul 23 13:45:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81B7120192; Tue, 23 Jul 2019 13:45:55 -0700 (PDT) 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, 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 header.b=e6WNdSH8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xm3vP3D0 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 NETFGmyDRUiw; Tue, 23 Jul 2019 13:45:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66187120159; Tue, 23 Jul 2019 13:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24406; q=dns/txt; s=iport; t=1563914753; x=1565124353; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sH+YRD2gTbENKxhB+p3VXvqvoTJsP4/s5KMCE8iB0gw=; b=e6WNdSH8pbUVeVF7SwATEHTkO1cXL53XeDl/sBqU9/VUMTVpuBwK7MGH Y71ZBOweKO3jRmACME5MCRyL9+jSkJZmczq6f/obK206+qdI6oRKYDnQ9 8cPJxIxW4OSX73TluMhQ3KTDi80h/sZBBbK44/z2u61+Uudk5yUn1sEJB c=; IronPort-PHdr: =?us-ascii?q?9a23=3AyeL0EhSV89uK/683U/lrvwdsLNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEDAAscTdd/5hdJa1mHQEBBQEHBQG?= =?us-ascii?q?BZ4EVL1ADbVUgBAsqhB2DRwOOAINZllKCUgNUCQEBAQwBAS0CAQGBS4J1Ahe?= =?us-ascii?q?CNyM4EwEDAQEEAQECAQZthR4MhUsCAQMSEQoTAQEuCQEPAgEIQgICAjAlAgQ?= =?us-ascii?q?ODRqDAYEdTQMdAQKgCgKBOIhgcYEygnkBAQWFCBiCEwmBNIRyhm0XgUA/gRF?= =?us-ascii?q?Gghc1PoRGDIJ9MoImjFWCI4R+lnEJAoIZlCeCLYsxiiylBQIEAgQFAg4BAQW?= =?us-ascii?q?BZyGBWHAVgyeCQoNxilNygSmOPQEB?= X-IronPort-AV: E=Sophos;i="5.64,300,1559520000"; d="scan'208,217";a="601223021" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jul 2019 20:45:52 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6NKjqsf018387 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jul 2019 20:45:52 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 15:45:51 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 15:45:50 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 23 Jul 2019 15:45:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W2rbnpIDqqOdNfe2ykptkMs6qqEWFxVYriCCseE4gRjCrD5x7ixhe0/HOB5nOC5Kvr07zcZNhL9RMwWpHjvlcS91diNaaA/hSii/WIvahf+vByrbqJ1008u+Vo0EdxdbOEy+al6xWJf/yhyw+ypFLbIYZfo8IOszhhF4hqEMDWZAKFI8lvn4kLBh3phiKuBjUHIMDisP1N9Z86sdQe+PfJqHfDMDPzi/3HmFVO3CQ4lfNCkmawIOvmZgg+HwHlFpcJOYj+Z+H4m4MJHY3N67ELLs8OprlAIbxoA4t+r//WxSQw6sqt2X+lVYgC3YMLW23Ra1HkFCXPOucU/of0i1jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sH+YRD2gTbENKxhB+p3VXvqvoTJsP4/s5KMCE8iB0gw=; b=MPXfG4Vb/36AcmiemVqW52zz4VF+XSsd8PlqgMl3ygvGihrtDvWuRx9EHB180ptTi6pMtCoVPJ5V2iLrOis43ysbEVM61vhpFuLjtUs35m1bjpjwhNZLIBXdLDL+kWc0hSXxFUGk3yaFFZJRCjj1P13BDyhGStMwJ4nHiYHOQazVpRYnfD2iSERI7RZB1kI35BY/aTsHo5JAu3/6PjOxN1RTpfduiPxbHv7Q7RF+Jvw/rLVpBdyFkBbBradl/MV6zhtmIlJB5seByZizsx3cy0Z6rn+hUhwt4+skwUtWWnPjyKVYZzGeZ+O6WPRVgsT98L1pME1aTQ4SPnebKgiKZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sH+YRD2gTbENKxhB+p3VXvqvoTJsP4/s5KMCE8iB0gw=; b=Xm3vP3D0MhyQOieZ29UAEmvrLp4X+jpXm+QvQ3mTwvLftDrvQXVXrXhKYZeVtHgiAzcdXGRWPZeUtYbL14+644mgIACctQctJooOLmSpTxvsgHc44Z9VXGVVFEyQt6Z1JlKUDWzWAORRFDI2iuzikrz8TL7R9KimhNNZta4VVV0= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3711.namprd11.prod.outlook.com (20.178.254.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Tue, 23 Jul 2019 20:45:50 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2094.013; Tue, 23 Jul 2019 20:45:49 +0000 From: "Pascal Thubert (pthubert)" To: Lorenzo Colitti CC: David Lamparter , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Thread-Topic: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft Thread-Index: AQHVQTDJQIJu4w3G6EWWHtrdc581RKbYFBSAgAAGiwCAABEDgIAAA6lRgAAIB4CAAFPv0A== Date: Tue, 23 Jul 2019 20:45:38 +0000 Deferred-Delivery: Tue, 23 Jul 2019 19:52:20 +0000 Message-ID: References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <20190723130323.GK34551@eidolon.nox.tf> <4F9991E5-AB39-464E-BBF8-87D3B6A6B677@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1008::e3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a59c862-2963-43be-42cc-08d70faebf06 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3711; x-ms-traffictypediagnostic: MN2PR11MB3711: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(366004)(39860400002)(376002)(396003)(199004)(189003)(14444005)(64756008)(66476007)(66446008)(6506007)(53936002)(6436002)(66556008)(71190400001)(71200400001)(66574012)(8936002)(6306002)(54896002)(102836004)(66946007)(76116006)(9686003)(86362001)(5660300002)(99286004)(76176011)(229853002)(6916009)(55016002)(25786009)(14454004)(2906002)(6246003)(68736007)(7736002)(6116002)(316002)(74316002)(256004)(476003)(7696005)(446003)(478600001)(52536014)(790700001)(6666004)(8676002)(46003)(11346002)(81156014)(81166006)(54906003)(4326008)(33656002)(186003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3711; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3DXqwwRAK3ZLAmNt6BLTFJJX9uN23o2MjkOspILT9IBu9QANYCzBE6yMvfeNtCFvSpxvdVy9Z1mHZlCaHkKWa90HbB5LbD2DYBUEjAaQxMSUPqycu2XuQMu6a1afuY2UIC8MRGEJQIgbw9IdEvXy5q1qlYF7G8LGjz+w3fITdE4W4DGgjjuPTEHnRV9KmsjTFi0tPo6Ylec9l0flWVxKsRmmn4c12mdn2u2+OU7WcsrZKsmcOeokfDNMX2C4UBwii4zFZI5OwRezAoNSgGVU46iZqqOU9wL5XTMUbJckyd5R8ZCRMg64b6fL4ZXw6gm/QaYRwtXb0RqnL6OenhpKUMWuHXVrZbliP3lZ1YRHBetQxj7BMpC7WT64HTeb1ZaBmDduzotCbU+heXUUdqJ3v+UFsWgE1hhMh8EKm/Y9K1U= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565F18D397423F11C54CD2CD8C70MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a59c862-2963-43be-42cc-08d70faebf06 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 20:45:49.7710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3711 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:45:56 -0000 --_000_MN2PR11MB3565F18D397423F11C54CD2CD8C70MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTG9yZW56bw0KDQpGb3IgdGhlIHJlY29yZCwgYWN0dWFsbHkgbm8sIHRoYXQgaXMgbm90 IG15IHBvc2l0aW9uLiBQcm90b2NvbCBjaGFuZ2VzIGRvIGJlbG9uZyBpbiA2bWFuLiBCdXQgYXMg QnJpYW4gc2F5cywgd2UgbWF5IG5vdCBuZWVkIHByb3RvY29sIGNoYW5nZXMuIEEgQkNQIHNlZW1z IGxpa2UgYSBmaW5lIHBsYWNlIHRvIHNheSAiaGVyZSdzIGEgZ29vZCByZWFzb24gbm90IHRvIGlt cGxlbWVudCB0aGlzIFNIT1VMRCBpbiBhIHJvdXRlciIuDQoNCjxQYXNjYWw+DQoNCiAgKiAgIFNv cnJ5IGZvciBwbGFjaW5nIHdvcmRzIGluIHlvdXIgbW91dGgsIHRoYXQgd2FzIG15IHVuZGVyc3Rh bmRpbmcgb2YgeW91ciBsYXN0IHNlbnRlbmNlLiBJIGhvcGUgdjZvcHMgZmluZHMgdHJpY2tzIHdp dGggdGhlIGN1cnJlbnQgbWV0aG9kcyB0aGF0IGhlbHAgdGhlIHNpdHVhdGlvbi4gSmVu4oCZcyBk cmFmdCBpcyB1c2VmdWwgYW5kIHVuY292ZXJzIG9uZSBvZiBtb3JlIHRoYW4gYSBoYWxmIGRvemVu IG9mIGlzc3VlcyB0aGF0IGFyZSByZWxhdGVkIHRvIHRoZSByZWFjdGl2ZSBuYXR1cmUgb2YgTkQu DQogICogICBBbmQgSSByZWFkIHRoYXQgdGhlIHByb3Bvc2VkIGFwcHJvYWNoIHRvIHNvbHZlIHRo YXQgaXMgdG8gcG9wdWxhdGUgdGhlIE5EIGNhY2hlIGluIGFkdmFuY2UuIFdoaWNoIGlzIHdoYXQg aW4gbXkgYm9vayBpcyBjYWxsZWQgcHJvYWN0aXZlLCByZWdhcmRsZXNzIG9mIHRoZSBtZXRob2Qg dXNlZCB0byBnZXQgdGhlcmUuIFRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIGRvIGl0IHdlbGwg b3IganVzdCBzY3JhdGNoIHRoZSBzdXJmYWNlLg0KICAqICAgSeKAmWQgbGlrZSB0aGUgZHJhZnQg dG8gaW5jbHVkZSBvdGhlciBwcm9ibGVtcyB0aGF0IHJlbGF0ZSB0byB0aGUgc2FtZSBjYXVzZS4g VGhpcyBpbmNsdWRlczoNCg0KDQogICogICBQVU5UaW5nIHBhY2tldHMgdG8gc29mdHdhcmUgZm9y IHJlc29sdXRpb24sIGFuIGFyY2hhaWMgb3BlcmF0aW9uLiBLaWxscyB0aGUgYmVuZWZpdHMgb2Yg ODAyLjExYWkuIE1ha2VzIElQdjYgbG9va3MgZXZlbiB3b3JzZSB0aGFuIElQdjQgYmVjYXVzZSBv ZiBtb3JlIGFkZHJlc3Nlcy4NCiAgKiAgIFNjYW5uaW5nIGF0dGFja3MgdG8gRG9TIHRoZSByb3V0 ZXIsIHRyeWluZyB0byBlaXRoZXIgZmlsbCB0aGUgTkQgY2FjaGUsIHNhdHVyYXRlIHRoZSBDUFUs IG9yIGRlbnkgYWNjZXNzIHRvIGxlZ2l0aW1hdGUgaG9zdHMgd2hlbiB0aGUgcm91dGVyIHByb3Rl Y3RzIGl0c2VsZi4NCiAgKiAgIEJyb2FkY2FzdCBpbmVmZmljaWVuY2llcywgaW4gcGFydGljdWxh ciBpbiB3aXJlbGVzcyBhbmQgZGlzdHJpYnV0ZWQgTDIgZG9tYWlucw0KICAqICAgU2lsZW50IGhv c3QNCiAgKiAgIE5lZWQgZm9yIGEgZ2xvYmFsIGJyb2FkY2FzdCBkb21haW4gYW5kIGFsd2F5cyBv biBkZXZpY2VzIChmb3IgREFEIGFuZCBBUikgPSBBIGJhZCBtYXRjaCB3aXRoIHByZXR0eSBtdWNo IGFsbCBtb2Rlcm4gbmV0d29ya3MgaW5jbHVkaW5nIG92ZXJsYXlzLCBJT1QsIHZlaGljdWxhciBv ciB3aXJlbGVzcw0KICAqICAgTkQgYWJ1c2UgLyBTZU5EIHRvbyBjb21wbGV4DQoNCldlIGFyZSBu b3cgZmluZGluZyB0aGF0IHdlIG5lZWQgdG8gcmVjb25zaWRlciB0aGUgcmVhY3RpdmUgYmVoYXZp b3Igb2YgTkQgQVIuIFRyaWNraW5nIHRoZSBjdXJyZW50IG1vZGVsIGNhbiBpbXByb3ZlIHRoaW5n cyBidXQgb25seSBzbyBmYXIuDQoNCkZvciB0aGUgcmVjb3JkLCBJIGRvbid0IGFncmVlIHdpdGgg dGhpcy4gQ2hhbmdpbmcgdGhlIHJlYWN0aXZlIGJlaGF2aW91ciBoYXMgZmFyLXJlYWNoaW5nIGlt cGxpY2F0aW9ucyBhbmQgYSBudW1iZXIgb2YgZGlmZmljdWx0IHRyYWRlLW9mZnMgd2l0aCByZWdh cmQgdG8gc2NhbGFiaWxpdHksIGNyYXNoIHJlY292ZXJ5LCBhdmFpbGFiaWxpdHkgb2YgYWRkcmVz c2VzIHRvIG5ldHdvcmsgbm9kZXMsIGFuZCBzbyBvbi4NCg0KDQo8UGFzY2FsPg0KDQoNCsOYICAg IEFpbuKAmXQgdGhhdCBGVUQ/IFdlIGFsbCBoYXZlIGJlZW4gdXNpbmcgV2ktRmkgRVNTIGZvciBh IGxvbmcgdGltZSBhbmQgdGhlIHByby1hY3RpdmUgbW9kZWwgaGFzIGJlZW4gZGVsaXZlcmluZyBx dWl0ZSBzYXRpc2ZhY3RvcmlseSBBRkFJSy4gSXQgaXMgYWN0dWFsbHkgYSBsb3QgbW9yZSBzY2Fs YWJsZSB0aGFuIHRyYW5zcGFyZW50IGJyaWRnaW5nLCB3aGljaCBpcyB0aGUgYW5hbG9nb3VzIHRv IEFSIHJlbGllIGF0IHRoZSBNQUMtbGV2ZWwuIEl0IHdhcyBkZXNpZ25lZCB0byBwcm90ZWN0IHRo ZSB3aXJlbGVzcyBtZWRpdW0uIFRoZSBFQVJPIG1vZGVsIGlzIGEgcGxhaW4gYWRhcHRhdGlvbiBv ZiB0aGUgbW9kZWwgYXQgTGF5ZXItMy4gSXQgd2FzIGRvYWJsZSBhdCBMMiBmb3IgYSB3aGlsZSwg aXQgaXMgcHJvYmFibHkgZG9hYmxlIGF0IEwzIHRvZGF5LiBBY3R1YWxseSB3ZeKAmXZlIGRvbmUg aXQuIFdlIGhhdmUgZGVwbG95ZWQgTUxTTnMgb24gdGhvdXNhbmRzIG9mIG5vZGVzIG9wZXJhdGlu ZyB0aGF0IHdheS4NCg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCg== --_000_MN2PR11MB3565F18D397423F11C54CD2CD8C70MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjIzMDcwMTk2OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTM1NzExNTg4NDt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MjkxODMyNDEyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjg4ODgwNDM0O30NCkBsaXN0IGwx OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo5OTM5OTAz ODE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjA3 MTgwODA0IDEwMzU3ODA3NTIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs Mw0KCXttc28tbGlzdC1pZDoxMTE3MjE2MzY0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTY2MjYxMjExNiAtNzM3NzcxMTU2IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO30NCkBsaXN0IGwz OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIExvcmVuem88bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZvciB0aGUgcmVjb3JkLCBhY3R1YWxseSBubywgdGhhdCBpcyBub3Qg bXkgcG9zaXRpb24uIFByb3RvY29sIGNoYW5nZXMgZG8gYmVsb25nIGluIDZtYW4uIEJ1dCBhcyBC cmlhbiBzYXlzLCB3ZSBtYXkgbm90IG5lZWQgcHJvdG9jb2wgY2hhbmdlcy4gQSBCQ1Agc2VlbXMg bGlrZSBhIGZpbmUgcGxhY2UgdG8gc2F5ICZxdW90O2hlcmUncyBhIGdvb2QgcmVhc29uIG5vdCB0 byBpbXBsZW1lbnQgdGhpcyBTSE9VTEQgaW4gYQ0KIHJvdXRlciZxdW90Oy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O1Bhc2NhbCZndDs8bzpwPjwvbzpwPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwzIGxldmVsMSBs Zm8zIj5Tb3JyeSBmb3IgcGxhY2luZyB3b3JkcyBpbiB5b3VyIG1vdXRoLCB0aGF0IHdhcyBteSB1 bmRlcnN0YW5kaW5nIG9mIHlvdXIgbGFzdCBzZW50ZW5jZS4gSSBob3BlIHY2b3BzIGZpbmRzIHRy aWNrcyB3aXRoIHRoZSBjdXJyZW50IG1ldGhvZHMgdGhhdCBoZWxwIHRoZSBzaXR1YXRpb24uIEpl buKAmXMgZHJhZnQgaXMgdXNlZnVsDQogYW5kIHVuY292ZXJzIG9uZSBvZiBtb3JlIHRoYW4gYSBo YWxmIGRvemVuIG9mIGlzc3VlcyB0aGF0IGFyZSByZWxhdGVkIHRvIHRoZSByZWFjdGl2ZSBuYXR1 cmUgb2YgTkQuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj5BbmQgSSByZWFk IHRoYXQgdGhlIHByb3Bvc2VkIGFwcHJvYWNoIHRvIHNvbHZlIHRoYXQgaXMgdG8gcG9wdWxhdGUg dGhlIE5EIGNhY2hlIGluIGFkdmFuY2UuIFdoaWNoIGlzIHdoYXQgaW4gbXkgYm9vayBpcyBjYWxs ZWQgcHJvYWN0aXZlLCByZWdhcmRsZXNzIG9mIHRoZSBtZXRob2QgdXNlZCB0byBnZXQgdGhlcmUu DQogVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2UgZG8gaXQgd2VsbCBvciBqdXN0IHNjcmF0Y2gg dGhlIHN1cmZhY2UuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+SeKAmWQgbGlr ZSB0aGUgZHJhZnQgdG8gaW5jbHVkZSBvdGhlciBwcm9ibGVtcyB0aGF0IHJlbGF0ZSB0byB0aGUg c2FtZSBjYXVzZS4gVGhpcyBpbmNsdWRlczo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzYiPlBVTlRpbmcgcGFja2V0cyB0 byBzb2Z0d2FyZSBmb3IgcmVzb2x1dGlvbiwgYW4gYXJjaGFpYyBvcGVyYXRpb24uIEtpbGxzIHRo ZSBiZW5lZml0cyBvZiA4MDIuMTFhaS4gTWFrZXMgSVB2NiBsb29rcyBldmVuIHdvcnNlIHRoYW4g SVB2NCBiZWNhdXNlIG9mIG1vcmUgYWRkcmVzc2VzLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzYiPlNjYW5uaW5nIGF0dGFja3MgdG8gRG9TIHRoZSByb3V0ZXIsIHRyeWluZyB0byBl aXRoZXIgZmlsbCB0aGUgTkQgY2FjaGUsIHNhdHVyYXRlIHRoZSBDUFUsIG9yIGRlbnkgYWNjZXNz IHRvIGxlZ2l0aW1hdGUgaG9zdHMgd2hlbiB0aGUgcm91dGVyIHByb3RlY3RzIGl0c2VsZi48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGNtO21zby1saXN0OmwyIGxldmVsMSBsZm82Ij5Ccm9hZGNhc3QgaW5lZmZpY2llbmNpZXMs IGluIHBhcnRpY3VsYXIgaW4gd2lyZWxlc3MgYW5kIGRpc3RyaWJ1dGVkIEwyIGRvbWFpbnM8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGNtO21zby1saXN0OmwyIGxldmVsMSBsZm82Ij5TaWxlbnQgaG9zdA0KPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTtt c28tbGlzdDpsMiBsZXZlbDEgbGZvNiI+TmVlZCBmb3IgYSBnbG9iYWwgYnJvYWRjYXN0IGRvbWFp biBhbmQgYWx3YXlzIG9uIGRldmljZXMgKGZvciBEQUQgYW5kIEFSKSA9IEEgYmFkIG1hdGNoIHdp dGggcHJldHR5IG11Y2ggYWxsIG1vZGVybiBuZXR3b3JrcyBpbmNsdWRpbmcgb3ZlcmxheXMsIElP VCwgdmVoaWN1bGFyIG9yIHdpcmVsZXNzDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwyIGxldmVsMSBs Zm82Ij5ORCBhYnVzZSAvIFNlTkQgdG9vIGNvbXBsZXg8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldlIGFyZSBub3cgZmluZGluZyB0aGF0IHdlIG5lZWQgdG8gcmVjb25zaWRlciB0aGUg cmVhY3RpdmUgYmVoYXZpb3Igb2YgTkQgQVIuIFRyaWNraW5nIHRoZSBjdXJyZW50IG1vZGVsIGNh biBpbXByb3ZlIHRoaW5ncyBidXQgb25seSBzbyBmYXIuDQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciB0aGUgcmVjb3JkLCBJ IGRvbid0IGFncmVlIHdpdGggdGhpcy4gQ2hhbmdpbmcgdGhlIHJlYWN0aXZlJm5ic3A7YmVoYXZp b3VyIGhhcyBmYXItcmVhY2hpbmcgaW1wbGljYXRpb25zIGFuZCBhIG51bWJlciBvZiBkaWZmaWN1 bHQgdHJhZGUtb2ZmcyB3aXRoIHJlZ2FyZCB0byBzY2FsYWJpbGl0eSwgY3Jhc2ggcmVjb3Zlcnks IGF2YWlsYWJpbGl0eSBvZiBhZGRyZXNzZXMgdG8gbmV0d29yayBub2RlcywgYW5kIHNvIG9uLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZsdDtQYXNjYWwmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGNtO3RleHQtaW5kZW50OjBjbTttc28tbGlzdDpsMyBsZXZlbDEg bGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2lu Z2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWlu4oCZdCB0aGF0IEZVRD8gV2UgYWxsIGhh dmUgYmVlbiB1c2luZyBXaS1GaSBFU1MgZm9yIGEgbG9uZyB0aW1lIGFuZCB0aGUgcHJvLWFjdGl2 ZSBtb2RlbCBoYXMgYmVlbiBkZWxpdmVyaW5nIHF1aXRlIHNhdGlzZmFjdG9yaWx5IEFGQUlLLiBJ dCBpcyBhY3R1YWxseSBhIGxvdCBtb3JlIHNjYWxhYmxlIHRoYW4gdHJhbnNwYXJlbnQgYnJpZGdp bmcsIHdoaWNoIGlzIHRoZSBhbmFsb2dvdXMgdG8NCiBBUiByZWxpZSBhdCB0aGUgTUFDLWxldmVs LiBJdCB3YXMgZGVzaWduZWQgdG8gcHJvdGVjdCB0aGUgd2lyZWxlc3MgbWVkaXVtLiBUaGUgRUFS TyBtb2RlbCBpcyBhIHBsYWluIGFkYXB0YXRpb24gb2YgdGhlIG1vZGVsIGF0IExheWVyLTMuIEl0 IHdhcyBkb2FibGUgYXQgTDIgZm9yIGEgd2hpbGUsIGl0IGlzIHByb2JhYmx5IGRvYWJsZSBhdCBM MyB0b2RheS4gQWN0dWFsbHkgd2XigJl2ZSBkb25lIGl0LiBXZSBoYXZlIGRlcGxveWVkIE1MU05z IG9uIHRob3VzYW5kcw0KIG9mIG5vZGVzIG9wZXJhdGluZyB0aGF0IHdheS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D aGVlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhc2NhbDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB3565F18D397423F11C54CD2CD8C70MN2PR11MB3565namp_-- From nobody Tue Jul 23 13:56:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3012097F; Tue, 23 Jul 2019 13:55:58 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqtUH7m5ldtD; Tue, 23 Jul 2019 13:55:56 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 6FFBF1209CF; Tue, 23 Jul 2019 13:55:56 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from ) id 1hq1p7-000c5y-Af; Tue, 23 Jul 2019 22:55:49 +0200 Date: Tue, 23 Jul 2019 22:55:49 +0200 From: David Lamparter To: Ole Troan Cc: Jen Linkova , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Message-ID: <20190723205549.GG258193@eidolon.nox.tf> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:56:09 -0000 On Tue, Jul 23, 2019 at 03:08:23PM -0400, Ole Troan wrote: > > wrote: > >> 3) I'm not convinced it needs to update 4861. If what it does is explain the conditions in which an RFC2119 "SHOULD" should be ignored, that is *not* an update to the standard. To me it sounds exactly like a Best Current Practice. > > > > That's was my impression as well, glad to see I'm not alone ;) > > > > "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > > there may exist valid reasons in particular circumstances when the > > particular behavior is acceptable or even useful, but the full > > implications should be understood and the case carefully weighed > > before implementing any behavior described with this label." > > > > So I guess as long as we document the case and implications, > > recommending routers to have a configuration knob to ignore "SHOULD" > > is not violating RFC4861. > > Probably getting the document reviewed by 6man WG would make sense as > > well to ensure that implications are understood. > > We have decades of experience with gratuitous ARP in IPv4. Updating > IPv6 ND to also support (and make it recommended practice) gratuious > ND seems sensible. I think we're jumping the gun here, let's enumerate solutions first. > I believe this requires an update to RFC4861. And I don't see any > reason why that work shouldn't happen in 6man. Ack. However, "gratuitous ND" is only one possible fix here, and a costly one at that since it needs updates on both the host to send this new "gratuitous ND" as well as the router to understand and process it. This discussion about the meta of "SHOULD" is based on the router-only change in behaviour to listen to all DAD that hosts send already - and one vendor seems to already be doing it. What's your opinion on where that would go? -David From nobody Tue Jul 23 18:14:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6BB1209B4 for ; Tue, 23 Jul 2019 18:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 TE8U3a5Jat6Y for ; Tue, 23 Jul 2019 18:14:09 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503A412034B for ; Tue, 23 Jul 2019 18:14:09 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id m206so33795475oib.12 for ; Tue, 23 Jul 2019 18:14:09 -0700 (PDT) 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=1UFZ1HAl4obkiKglKjv1dmDOtV+GmL+fHgAUYB069dQ=; b=GEoyPmK3Geeo1blZamFg0BqmhXSiZqdh6+WO1MZKIN0YuMvV1bnU/+5FXm9oLNbUjD xX4TKIorgdCTmgHPUk9DwJ2dF0h3xkvwu61cevkiXaN6ro9wmPD17oRoYMVLpVIwBFzS d2PPzOJPcpdlZwg9/jAUEPOlUDJDBuhECP5DLUOw8CuPSz5nsZAGhaF9rMP7LMjpzdHw HlqxLnjXB1DeJoIBFr2ds64RY3TVkQ4bBrOp6tLmDfAN2Iq2bX/lXtmgM1TXPYdkCuEd z1sB25v4t3p5Qp3J4lVjHqsOY7zlyAiVb8wwjvi+VOCgIdkR9SoutKWg9zaTSxRnAupI Fheg== 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=1UFZ1HAl4obkiKglKjv1dmDOtV+GmL+fHgAUYB069dQ=; b=VS4Nb19z/i7zCAcRg5U0M4PA/wntgNnXDJzn8ung253ollcYfBN+jEywMDni7i5Se2 frt5rOoGrqN/1dOv+V70V0Owfl35LMbrtMsiBbeBe++kxU82/sSzGslXLFbqjj3qiW6/ sfz5WZtubN6y8Agr306496+MaIhM37si2FmAIE8Ys9oBWYe2ZnODLyAaWaJLusY85ukz gEeHnHlOa27OlihFbOajkvMNA3hvhVRly0S+OR43l39Y/2LXbUva708N3uu91ORfTwpO MtAFydy6TMD1fQWRotAy/FceAHMrTrfHZxMWfqQrdXKgtwLDXKxpB+PStwOkLQQLcpg9 QHPw== X-Gm-Message-State: APjAAAX1636Ngpl9IPeyMwNzn3ajjqS+U3XPvsNBG5Je93waTbyiy40v SbNvgatK1YT1WG3gblaYQ6tsdBW0aePsylMqiiyaJAJi X-Google-Smtp-Source: APXvYqye9Nqf717LlZ6Vi5Bve8NL4+MRNoaXmkqSX644q5fS1C+LUWcO0bZ18DXr6nrfSrBLfKPAt2vLp+AbwJrwRw8= X-Received: by 2002:aca:c584:: with SMTP id v126mr39861814oif.60.1563930848505; Tue, 23 Jul 2019 18:14:08 -0700 (PDT) MIME-Version: 1.0 References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> <9740316D-61DE-4BF4-87C2-5BCA5575BC27@steffann.nl> In-Reply-To: <9740316D-61DE-4BF4-87C2-5BCA5575BC27@steffann.nl> From: Mark Smith Date: Wed, 24 Jul 2019 11:13:42 +1000 Message-ID: To: Sander Steffann Cc: Gert Doering , v6ops list Content-Type: multipart/alternative; boundary="000000000000adb515058e630696" Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 01:14:11 -0000 --000000000000adb515058e630696 Content-Type: text/plain; charset="UTF-8" On Tue., 23 Jul. 2019, 23:33 Sander Steffann, wrote: > Hi, > > > The general idea that on-link multicast is a positive aspect of IPv6 > > is nice, but wrong. > > Well, a little bit :) > > There is still the advantage that the NIC can apply its MAC address > filter. L2 destination FF:FF:FF:FF:FF:FF can't be filtered there, but > 33:33:* can :) It's no surprise that Steve Deering also wrote RFC 1112, "Host Extensions for IP Multicasting", which says, "7.4. Extensions to an Ethernet Local Network Module ... It is highly desirable to take advantage of any address filtering capabilities that the Ethernet hardware interface may have, so that the host receives only those packets that are destined to it." ... IPv4 and IPX uses/used link-layer broadcasts. Appletalk used link-layer multicasts, however, from memory, it used the same or a few multicast address for everything. IPv6 improves Appletalk by using much more specific link-layer multicast addresses for different purposes, which allows NIC filtering to be much more fine grained. If a host is only running protocols that use link-layer multicasts, then it could switch off broadcast reception in its NIC (IFF_BROADCAST interface flag). For example, an IPv6 only host attached to a link that also has IPv4 hosts would be able to drop in its NIC hardware IPv4 ARPs and DHCPv4 DISCOVERS, rather than processing and then dropping them at higher layers in the stack. Regards, Mark. > Cheers, > Sander > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000adb515058e630696 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue., 23 Jul. 2019, 23:33 Sander S= teffann, <sander= @steffann.nl> wrote:
Hi,

> The general idea that on-link multicast is a positive aspect of IPv6 > is nice, but wrong.

Well, a little bit :)

There is still the advantage that the NIC can apply its MAC address filter.= L2 destination FF:FF:FF:FF:FF:FF can't be filtered there, but 33:33:* = can :)


It's no surprise that Steve Deering also wrote RFC 111= 2, "Host Extensi= ons for IP Multicasting", which says,

"7.4. Ext= ensions to an Ethernet Local Network Module
...
It is highly desi= rable to take advantage of any address
=C2=A0 =C2=A0filtering capabiliti= es that the Ethernet hardware interface may have,
=C2=A0 =C2=A0so that t= he host receives only those packets that are destined to it."
...

IPv4 and IPX uses/used link-layer broadcasts. Apple= talk used link-layer multicasts, however, from memory, it used the same or = a few multicast address for everything.

IPv6 impro= ves Appletalk by using much more specific link-layer multicast addresses fo= r different purposes, which allows NIC filtering to be much more fine grain= ed.

If a host is only running protocols that use l= ink-layer multicasts, then it could switch off broadcast reception in its N= IC (IFF_BROADCAST interface flag).

For example, an= IPv6 only host attached to a link that also has IPv4 hosts would be able t= o drop in its NIC hardware IPv4 ARPs and DHCPv4 DISCOVERS, rather than proc= essing and then dropping them at higher layers in the stack.

=

Regards,
Mark.




Cheers,
Sander

_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000adb515058e630696-- From nobody Tue Jul 23 18:52:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4291209C3; Tue, 23 Jul 2019 18:52:32 -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_HELO_NONE=0.001, 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 s7YNrmPwAHjx; Tue, 23 Jul 2019 18:52:31 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 CC27E1209C1; Tue, 23 Jul 2019 18:52:30 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id r6so32684693qkc.0; Tue, 23 Jul 2019 18:52:30 -0700 (PDT) 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=xr/9otFrPll0eK8fhCoing/qlZTlDFeKIPRnTwj05/Y=; b=lbXoyLysWkb/9nMT5DQpqn0p5SBIaAfrW5NlcvPo/tUBUh4vKcoJ4mqSGYp/GUyJPm HDzGqUlCfwrxv+EGywYPB+CTyy5F6Wq+wutae6UCSBFzY1/S/Y3r5is3vCwRpJCNwLpK uchFGJxeSr0Q112vM8QOgtLsFkIVDDPrz8GQ2BuMZPNfNlnbo1l2WV8YnXv88HbMIl/o h2YZ30jxhqHTu4uf3Wl3rD2sWFA+YALOxOZCp2/feJjl+/1NSrBJwNUFVlsV8Qara75t vgQnHBK8nla07ju3Ok4cC/wSb5tV7kvEi5MOeTTnmNdHKEgsUxavv0p3+FCkeyZSZY1g 43gQ== 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=xr/9otFrPll0eK8fhCoing/qlZTlDFeKIPRnTwj05/Y=; b=lRtQXGwmffovi6nhKPTxWhhnve6n+S9zIVQfkHN0Pt2rozJ9m2Gyz1rinain+T8W57 WaWXbb+2n4qgO4KnhPXiePPc/3EMw2qrmtDJZNYwx3oDOJmifaGVA7GSm4zTouMxljq2 AF/ZdVWseLfSYB9AUslt1+tZZLvUsx52vXO2nx3A9ajJNl10VaFem4Lprp+0EVQBbsAD VKZzZ9Pk1LcQh3g8GH3NOAjb0StRnooRWduGSNmxRdNCitQM4EfawwT/QCLn6013bs99 JaZ8CDBn8cxhbEXMDovEg1zDvga1EMuaZKJTZbPnkYJq24z12+qubgUHyVVhQymGPxtN nvLQ== X-Gm-Message-State: APjAAAXITFr3LEwzXeSW3gLOwUAvEBU8LqTVvIY4mI/uukolW0h/YCrj o+Krwt5Y7jwLGQ1D4koIVMb7TCN7 X-Google-Smtp-Source: APXvYqwj6n/TETZNWynyktIvg8rKyDy4XCD2gVXnlx37CZPAJw4zqPYbgOxqtf+wcvkWFQkU1KmQ4Q== X-Received: by 2002:a05:620a:1537:: with SMTP id n23mr49074927qkk.441.1563933149712; Tue, 23 Jul 2019 18:52:29 -0700 (PDT) Received: from [31.133.129.140] (dhcp-818c.meeting.ietf.org. [31.133.129.140]) by smtp.gmail.com with ESMTPSA id i5sm18163838qtp.20.2019.07.23.18.52.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 18:52:28 -0700 (PDT) To: David Lamparter , Fernando Gont Cc: Fred Baker , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> From: Brian E Carpenter Message-ID: <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> Date: Wed, 24 Jul 2019 13:52:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190723191925.GF258193@eidolon.nox.tf> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 01:52:33 -0000 As has been extensively discussed on another thread, we sadly lack a method of getting operational notes with *rough* consensus out quickly, because our process for BCP, or worse for standards track, can take years instead of weeks. Y'all can prove me wrong by sending this draft to the IESG in a month or so, and then worry about updating RFC4861 at normal IETF speed. (After writing that, I am a bit embarassed that RFC6343 took six months.) Regards Brian On 24-Jul-19 07:19, David Lamparter wrote: > On Tue, Jul 23, 2019 at 06:59:23PM +0100, Fernando Gont wrote: >> On 23/7/19 12:39, Brian E Carpenter wrote: >>> 1) Yes, we should *obviously* do this. >>> 2) If the charter prevents that, fix the charter. >> >> I'm all for fixing problems and getting stuff done. And, if there's no >> other way than fixing the charter, so be it. >> >> However, it would seem to me that, the "bug" here is that we're >> defaulting to "6man wouldn't get this done, so let's do it elsewhere". > > The discussion I see here is that we've located an operational issue > with the IPv6 neighbor cache on routers, we have several candidates for > fixing it, and each of these may or may not need a protocol change to go > through 6man. > > Discussing whether any particular working group "gets things done" seems > tangential to the question at hand. > >> IMO, should be willing to maintain its protocols, improve them, and fix >> problems where necessary. >> >> If a BCP is to go against the protocol spec recommendation for the >> general case, that's an indication that the protocol should be updated. > > Although I don't write the neighbour management code, I do write code > that operates routers and I have absolutely no concerns in understanding > that a particular "SHOULD" statement has turned out to be a bad choice > for the specific situation of first-hop routers. > > Whether this is a specification change, to me, is decided by the intent. > The intent under consideration here is: > > When a valid Neighbor Advertisement is received (either solicited or > unsolicited), the Neighbor Cache is searched for the target's entry. > If no entry exists, the advertisement SHOULD be silently discarded. > There is no need to create an entry if none exists, since the > recipient has apparently not initiated any communication with the > target. > > The intent I see is that in most cases there's no point in having > devices consume memory, and the "SHOULD" is correct behaviour for hosts. > Routers *DO* "need to create an entry if none exists". I don't see a > conflict with 4861's intent, which I take as "don't open yourself to DoS > attacks". The router /will have the neighbor cache entry anyway/, just > with a delay, later, and the resulting annoyance. > > 4861 just failed to invoke the magic 8-ball correctly to make the > authors omniscient and recognize the specific circumstances under which > this SHOULD is maybe not the best idea. This is implementation guidance > based on operational experience. Just write it down and get it out > there. > > > -David > . > From nobody Wed Jul 24 04:05:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF9D120176; Wed, 24 Jul 2019 04:05:44 -0700 (PDT) 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, 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 header.b=HIZLBpdF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GxfpaTNH 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 kNd3eWfOcmH9; Wed, 24 Jul 2019 04:05:42 -0700 (PDT) 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 B367112016A; Wed, 24 Jul 2019 04:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6360; q=dns/txt; s=iport; t=1563966341; x=1565175941; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UniFUZgG5ZnVquzBIlYgTTP2HmGxJi22uuOSU7KihbM=; b=HIZLBpdF8xDnhdzzWngSK0CFZKBPFgZQWW5JhRUsqnCXGVSjN1e7IpJo 82KQced7c7xepFve3asX4YGprrENpBnIMByCm8++OvjNKfk4fBKKC7I1r Rgx4B10brhiEznFako+/dHEVeJPmZ4o49pqrY3SzV5UrHphpBoyFH4NC4 w=; IronPort-PHdr: =?us-ascii?q?9a23=3A5ho+JBQKj3pDlGp389dMAmX89Npsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAACtOjhd/5FdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBgUMkLANtVSAECyoKhBODRwONQIJbfoh?= =?us-ascii?q?WjXyBQoEQA1QJAQEBDAEBGAsKAgEBhEACF4I/IzcGDgEDAQEEAQECAQZthR4?= =?us-ascii?q?MhUoBAQEDAQEBEBERDAEBLAsBBAsCAQgYAgImAgICHwYLFRACBA4FIoMAAYF?= =?us-ascii?q?qAw4PAQIMoUECgTiIYHGBMoJ5AQEFgTIBg1INC4ITAwaBDCgBhHGGbReBQD+?= =?us-ascii?q?BEScfgU5JNT6CGkcBAYElg0cygiaMHIJchyuUB0AJAoIZkBiDdxuYCpZ1jhQ?= =?us-ascii?q?CBAIEBQIOAQEFgWYigVhwFTsqAYJBgkKDcYUUhT9yAYEoi1EBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.64,302,1559520000"; d="scan'208";a="603347389" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2019 11:05:40 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x6OB5enF026732 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2019 11:05:40 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 06:05:40 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 06:05:39 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Jul 2019 06:05:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XGELiDeHBMsfRnxwZMylXWiMLbm92leDPg4h78W7vFC4sHnH842FuZ8k8T+XIOTz1fbgeDmDI0w3nv19JKIVmYdO7nO3ao4jv5C/SV74DcAl+1Tx5iHE59/zT9kwd0x0N9Exkc70lqx3whKjDcC/uAdzhTMROhJjQjrZc+Ywq4B/dRTyJ+FcolO1te8FnjUR1fdW817tVz+9VUSERtNgxHiy6kUfKMW3U2IkpJaiMo8huOfMSmQmMu++boNZpMPNkBUUxcfSG/ewtzT9S6sEhgSvvmqYETiD12/LSvX6Iozpq2RSpRHGmjo31P9NwQjbMmprR/tzj6Kfb77yNeWmVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UniFUZgG5ZnVquzBIlYgTTP2HmGxJi22uuOSU7KihbM=; b=SyNUsizbrY06k03LFwtxRiiIgwnF2Nqr02mDmcLVW9nrvRLPM7xsG+suPQcLUhQfF97gXbo5ZN6akPYUGxi56tIAaFpGRkLMqPJaFdmIkzDij8SPNEn1pSVWikOLX3EF898ql2MO7LTBxIn9Z0DBNfgfTJed8LJA3jhxMF/SQHJqwlcbzcECNkuBCOa1c8Yab8lnDHrIVAQ/AhsYJbpxy33ZICKIdbZbmv9d8lgd7jtnl08u9+momOYuo9KCPMfSjiK3xG/yZX5bYWrebPqRNW2rbjOfMit7YeF1V/4pqa0ZKDD16zhVU/CqkGQ+VdmtQJYi/MJiuxpi+hHTQYUzag== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UniFUZgG5ZnVquzBIlYgTTP2HmGxJi22uuOSU7KihbM=; b=GxfpaTNHqstDDaFk/Ci3CZiK1MUB6iFnuXJArArg1sFA7Z5BeHFF35x699fbY5F0qGSqT/CMnJCWjakhcTGUiWxxu+++P2Ltfj8YNoy7QAxqiz9Do7vNRiLEWrDTi2o0ilsCzOZCITs0MvKZQPaM0nAJP+IS8g6zlnAA5r3BStI= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3885.namprd11.prod.outlook.com (20.179.150.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Wed, 24 Jul 2019 11:05:38 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2094.013; Wed, 24 Jul 2019 11:05:38 +0000 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter CC: David Lamparter , Fernando Gont , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Thread-Topic: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft Thread-Index: AQHVQTDJQIJu4w3G6EWWHtrdc581RKbYFBSAgABqQoCAABZcgIAAbdEAgACajYA= Date: Wed, 24 Jul 2019 11:05:38 +0000 Message-ID: <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> In-Reply-To: <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [207.115.96.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3adc07e9-828a-4540-bea4-08d71026dc21 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3885; x-ms-traffictypediagnostic: MN2PR11MB3885: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(396003)(366004)(136003)(199004)(189003)(966005)(25786009)(446003)(76116006)(66476007)(76176011)(54906003)(11346002)(91956017)(7736002)(2616005)(256004)(476003)(99286004)(66446008)(186003)(316002)(64756008)(53546011)(8676002)(66556008)(66946007)(305945005)(486006)(478600001)(6506007)(6916009)(102836004)(26005)(81156014)(6116002)(6306002)(2906002)(36756003)(81166006)(33656002)(6436002)(6246003)(66066001)(6512007)(86362001)(6486002)(66574012)(71190400001)(14454004)(5660300002)(68736007)(229853002)(8936002)(3846002)(71200400001)(53936002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3885; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OsCXsCLo73ABblP6vndmxFaYk6SC0q7SlK3Ab8PZ+bEzw23a/cdTyWpN0cth0gpq/CyuwHc/27p5ZZLa/36eGzkxlFB8ctQidqIGpXoep0UBSfPwu5WgIVmwHPWm5z+4LyBZVG2Bac6OW16/izG6XPRXnTYPpok77TfjG3fwColk0daOaHwfBmczuSRqlWcafGoKCfohdwy8i5bCvK9f7s+KPPM1b0yoD6A/YMmjH9OW5fmg9yPXxW5LcmltZQbyhUFGp51/Ky/viuALbNcHV97zUynahBgt30AmaPiTFMlYPYy53sVbtK/K2YwIKwprsRSzMf5nUoEFsD+E2CPT+cHWluSZtM7n1DtkBNnfeEiAZn3bqKP3+Q2j/2oecrIalV840b8iVunsng0jyJgqw+nado65DNOtIFWDQV9XiXY= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3adc07e9-828a-4540-bea4-08d71026dc21 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 11:05:38.2546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3885 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 11:05:45 -0000 SGVsbG8gQnJpYW4NCg0KSeKAmXZlIHBhcnRpY2lwYXRlZCB0byBtdWx0aXBsZSBjb3JyaWRvciBk aXNjdXNzaW9ucyBvbiB0aGF0IHRvcGljIGFuZCBzZWVuIGFncmVlbWVudCB0aGF0IE5BKE8pIHRv IGZmMDI6OjIgdGhhdCBwcm9hY3RpdmVseSBzZXRzIHRoZSBjYWNoZSBpbiB0aGUgcm91dGVycyBp cyBiZXR0ZXIgdGhhbiB0aGUgY3VycmVudCBzdGF0ZSBvZiBhZmZhaXJzIHdoaWNoIGlzIGEgTlMg ZnJvbSB0aGUgcm91dGVyIHRoYXQgaXMgYnJvYWRjYXN0ZWQgdG8gYWxsIGhvc3RzIGF0IEwyLiAN Cg0KRm9yIG9uZSB0aGluZyBpdCBpcyBhIGxvdCBlYXNpZXIgZm9yIHRoZSBwcm94eSBpbmZyYSB0 byBjYW5jZWwgb24gd2lyZWxlc3MgaW50ZXJmYWNlcyB3aGVyZSB0aGVyZSBpcyBubyByb3V0ZXIg dGhhbiBhIE5TIGZvciB3aGljaCB0aGUgdGFyZ2V0IGlzIHVua25vd24uDQoNCkFub3RoZXIgdGhp bmcgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIGRvIGltaG8gaXMgYSBtb3JlIGNvbXByZWhlbnNpdmUg cmV2aWV3IG9mIHRoZSBwcm9ibGVtcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggcmVhY3RpdmUu IENvbWluZyBmcm9tIHRoZSByb3V0ZXIgc2lkZSBJ4oCZbSBwcm9iYWJseSBtb3JlIHNlbnNpdGl2 ZSB0byB0aGF0IHRoYW4gb3RoZXJzIGFuZCBJ4oCZZCBkZSBoYXBweSB0byBjb250cmlidXRlLg0K DQpBbGwgdGhhdCBjYW4gYmUgZG9uZSBpbiBhIHJvdW5kIG9yIDIsIHRoZXJlIGlzIG5vIGJsYWNr IG1hZ2ljLiBJIHdpc2ggdG8gcHJvdmUgeW91IHJpZ2h0IHRoYXQgaXQgY2FuIGJlIGRvbmUgaW4g YSBtYXR0ZXIgb2YgbW9udGhzLg0KDQpOb3RlIHRoYXQgaXQgd2lsbCBwcm92aWRlIGxpdHRsZSBk aWZmZXJlbmNlIHRvIHdoYXQgd2UgY3VycmVudGx5IGRvIHdpdGggTkQgc25vb3BpbmcsIGp1c3Qg d2lsbCBpbXByb3ZlIHRoZSBjaGFuY2VzIHRvIGNyZWF0ZSB0aGUgc3RhdGUgaW4gY2FzZSB0aGUg ZGFkIHdhcyBsb3N0LiBPdXIgYmlnZ2VzdCBwcm9ibGVtcyB3aXRoIHNub29waW5nIGFyZSBlbHNl d2hlcmUgYW5kIHRoZSBuZWVkIGZvciB0aGUgNmxvIC10eXBlIHJlZ2lzdHJhdGlvbiBhbmQgdGhl IHVuaWNhc3QgbG9va3VwIGRvZXMgbm90IGNoYW5nZSBhIGJpdC4gDQoNCkFsbCB0aGUgYmVzdCwN Cg0KUGFzY2FsDQoNCj4gTGUgMjMganVpbC4gMjAxOSDDoCAyMTo1MywgQnJpYW4gRSBDYXJwZW50 ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gYSDDqWNyaXQgOg0KPiANCj4gQXMgaGFz IGJlZW4gZXh0ZW5zaXZlbHkgZGlzY3Vzc2VkIG9uIGFub3RoZXIgdGhyZWFkLCB3ZSBzYWRseSBs YWNrIGEgbWV0aG9kDQo+IG9mIGdldHRpbmcgb3BlcmF0aW9uYWwgbm90ZXMgd2l0aCAqcm91Z2gq IGNvbnNlbnN1cyBvdXQgcXVpY2tseSwgYmVjYXVzZQ0KPiBvdXIgcHJvY2VzcyBmb3IgQkNQLCBv ciB3b3JzZSBmb3Igc3RhbmRhcmRzIHRyYWNrLCBjYW4gdGFrZSB5ZWFycyBpbnN0ZWFkDQo+IG9m IHdlZWtzLg0KPiANCj4gWSdhbGwgY2FuIHByb3ZlIG1lIHdyb25nIGJ5IHNlbmRpbmcgdGhpcyBk cmFmdCB0byB0aGUgSUVTRyBpbiBhIG1vbnRoDQo+IG9yIHNvLCBhbmQgdGhlbiB3b3JyeSBhYm91 dCB1cGRhdGluZyBSRkM0ODYxIGF0IG5vcm1hbCBJRVRGIHNwZWVkLg0KPiANCj4gKEFmdGVyIHdy aXRpbmcgdGhhdCwgSSBhbSBhIGJpdCBlbWJhcmFzc2VkIHRoYXQgUkZDNjM0MyB0b29rIHNpeCBt b250aHMuKQ0KPiANCj4gUmVnYXJkcw0KPiAgIEJyaWFuDQo+IA0KPj4gT24gMjQtSnVsLTE5IDA3 OjE5LCBEYXZpZCBMYW1wYXJ0ZXIgd3JvdGU6DQo+Pj4gT24gVHVlLCBKdWwgMjMsIDIwMTkgYXQg MDY6NTk6MjNQTSArMDEwMCwgRmVybmFuZG8gR29udCB3cm90ZToNCj4+Pj4gT24gMjMvNy8xOSAx MjozOSwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+Pj4+IDEpIFllcywgd2Ugc2hvdWxkICpv YnZpb3VzbHkqIGRvIHRoaXMuDQo+Pj4+IDIpIElmIHRoZSBjaGFydGVyIHByZXZlbnRzIHRoYXQs IGZpeCB0aGUgY2hhcnRlci4NCj4+PiANCj4+PiBJJ20gYWxsIGZvciBmaXhpbmcgcHJvYmxlbXMg YW5kIGdldHRpbmcgc3R1ZmYgZG9uZS4gQW5kLCBpZiB0aGVyZSdzIG5vDQo+Pj4gb3RoZXIgd2F5 IHRoYW4gZml4aW5nIHRoZSBjaGFydGVyLCBzbyBiZSBpdC4NCj4+PiANCj4+PiBIb3dldmVyLCBp dCB3b3VsZCBzZWVtIHRvIG1lIHRoYXQsIHRoZSAiYnVnIiBoZXJlIGlzIHRoYXQgd2UncmUNCj4+ PiBkZWZhdWx0aW5nIHRvICI2bWFuIHdvdWxkbid0IGdldCB0aGlzIGRvbmUsIHNvIGxldCdzIGRv IGl0IGVsc2V3aGVyZSIuDQo+PiANCj4+IFRoZSBkaXNjdXNzaW9uIEkgc2VlIGhlcmUgaXMgdGhh dCB3ZSd2ZSBsb2NhdGVkIGFuIG9wZXJhdGlvbmFsIGlzc3VlDQo+PiB3aXRoIHRoZSBJUHY2IG5l aWdoYm9yIGNhY2hlIG9uIHJvdXRlcnMsIHdlIGhhdmUgc2V2ZXJhbCBjYW5kaWRhdGVzIGZvcg0K Pj4gZml4aW5nIGl0LCBhbmQgZWFjaCBvZiB0aGVzZSBtYXkgb3IgbWF5IG5vdCBuZWVkIGEgcHJv dG9jb2wgY2hhbmdlIHRvIGdvDQo+PiB0aHJvdWdoIDZtYW4uDQo+PiANCj4+IERpc2N1c3Npbmcg d2hldGhlciBhbnkgcGFydGljdWxhciB3b3JraW5nIGdyb3VwICJnZXRzIHRoaW5ncyBkb25lIiBz ZWVtcw0KPj4gdGFuZ2VudGlhbCB0byB0aGUgcXVlc3Rpb24gYXQgaGFuZC4NCj4+IA0KPj4+IElN Tywgc2hvdWxkIGJlIHdpbGxpbmcgdG8gbWFpbnRhaW4gaXRzIHByb3RvY29scywgaW1wcm92ZSB0 aGVtLCBhbmQgZml4DQo+Pj4gcHJvYmxlbXMgd2hlcmUgbmVjZXNzYXJ5Lg0KPj4+IA0KPj4+IElm IGEgQkNQIGlzIHRvIGdvIGFnYWluc3QgdGhlIHByb3RvY29sIHNwZWMgcmVjb21tZW5kYXRpb24g Zm9yIHRoZQ0KPj4+IGdlbmVyYWwgY2FzZSwgdGhhdCdzIGFuIGluZGljYXRpb24gdGhhdCB0aGUg cHJvdG9jb2wgc2hvdWxkIGJlIHVwZGF0ZWQuDQo+PiANCj4+IEFsdGhvdWdoIEkgZG9uJ3Qgd3Jp dGUgdGhlIG5laWdoYm91ciBtYW5hZ2VtZW50IGNvZGUsIEkgZG8gd3JpdGUgY29kZQ0KPj4gdGhh dCBvcGVyYXRlcyByb3V0ZXJzIGFuZCBJIGhhdmUgYWJzb2x1dGVseSBubyBjb25jZXJucyBpbiB1 bmRlcnN0YW5kaW5nDQo+PiB0aGF0IGEgcGFydGljdWxhciAiU0hPVUxEIiBzdGF0ZW1lbnQgaGFz IHR1cm5lZCBvdXQgdG8gYmUgYSBiYWQgY2hvaWNlDQo+PiBmb3IgdGhlIHNwZWNpZmljIHNpdHVh dGlvbiBvZiBmaXJzdC1ob3Agcm91dGVycy4NCj4+IA0KPj4gV2hldGhlciB0aGlzIGlzIGEgc3Bl Y2lmaWNhdGlvbiBjaGFuZ2UsIHRvIG1lLCBpcyBkZWNpZGVkIGJ5IHRoZSBpbnRlbnQuDQo+PiBU aGUgaW50ZW50IHVuZGVyIGNvbnNpZGVyYXRpb24gaGVyZSBpczoNCj4+IA0KPj4gICBXaGVuIGEg dmFsaWQgTmVpZ2hib3IgQWR2ZXJ0aXNlbWVudCBpcyByZWNlaXZlZCAoZWl0aGVyIHNvbGljaXRl ZCBvcg0KPj4gICB1bnNvbGljaXRlZCksIHRoZSBOZWlnaGJvciBDYWNoZSBpcyBzZWFyY2hlZCBm b3IgdGhlIHRhcmdldCdzIGVudHJ5Lg0KPj4gICBJZiBubyBlbnRyeSBleGlzdHMsIHRoZSBhZHZl cnRpc2VtZW50IFNIT1VMRCBiZSBzaWxlbnRseSBkaXNjYXJkZWQuDQo+PiAgIFRoZXJlIGlzIG5v IG5lZWQgdG8gY3JlYXRlIGFuIGVudHJ5IGlmIG5vbmUgZXhpc3RzLCBzaW5jZSB0aGUNCj4+ICAg cmVjaXBpZW50IGhhcyBhcHBhcmVudGx5IG5vdCBpbml0aWF0ZWQgYW55IGNvbW11bmljYXRpb24g d2l0aCB0aGUNCj4+ICAgdGFyZ2V0Lg0KPj4gDQo+PiBUaGUgaW50ZW50IEkgc2VlIGlzIHRoYXQg aW4gbW9zdCBjYXNlcyB0aGVyZSdzIG5vIHBvaW50IGluIGhhdmluZw0KPj4gZGV2aWNlcyBjb25z dW1lIG1lbW9yeSwgYW5kIHRoZSAiU0hPVUxEIiBpcyBjb3JyZWN0IGJlaGF2aW91ciBmb3IgaG9z dHMuDQo+PiBSb3V0ZXJzICpETyogIm5lZWQgdG8gY3JlYXRlIGFuIGVudHJ5IGlmIG5vbmUgZXhp c3RzIi4gIEkgZG9uJ3Qgc2VlIGENCj4+IGNvbmZsaWN0IHdpdGggNDg2MSdzIGludGVudCwgd2hp Y2ggSSB0YWtlIGFzICJkb24ndCBvcGVuIHlvdXJzZWxmIHRvIERvUw0KPj4gYXR0YWNrcyIuICBU aGUgcm91dGVyIC93aWxsIGhhdmUgdGhlIG5laWdoYm9yIGNhY2hlIGVudHJ5IGFueXdheS8sIGp1 c3QNCj4+IHdpdGggYSBkZWxheSwgbGF0ZXIsIGFuZCB0aGUgcmVzdWx0aW5nIGFubm95YW5jZS4N Cj4+IA0KPj4gNDg2MSBqdXN0IGZhaWxlZCB0byBpbnZva2UgdGhlIG1hZ2ljIDgtYmFsbCBjb3Jy ZWN0bHkgdG8gbWFrZSB0aGUNCj4+IGF1dGhvcnMgb21uaXNjaWVudCBhbmQgcmVjb2duaXplIHRo ZSBzcGVjaWZpYyBjaXJjdW1zdGFuY2VzIHVuZGVyIHdoaWNoDQo+PiB0aGlzIFNIT1VMRCBpcyBt YXliZSBub3QgdGhlIGJlc3QgaWRlYS4gIFRoaXMgaXMgaW1wbGVtZW50YXRpb24gZ3VpZGFuY2UN Cj4+IGJhc2VkIG9uIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuICBKdXN0IHdyaXRlIGl0IGRvd24g YW5kIGdldCBpdCBvdXQNCj4+IHRoZXJlLg0KPj4gDQo+PiANCj4+IC1EYXZpZA0KPj4gLg0KPj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Wed Jul 24 05:26:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE571200C4 for ; Wed, 24 Jul 2019 05:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 2T_D2PjeJZfU for ; Wed, 24 Jul 2019 05:26:01 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 B3164120150 for ; Wed, 24 Jul 2019 05:26:01 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id d23so45268212qto.2 for ; Wed, 24 Jul 2019 05:26:01 -0700 (PDT) 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=GuwdEaCODpw2YqPL3tmItN8JDdLNy4XD53hEUd7pnS8=; b=Thn/hIHx4XnsWDPu/vzg1GalZI3A3NLeR7irB3OHd6mPB0or/R+jEqMZOWFTRSuISf eG8Gut1mwlaEY5MIttJfhUmxEOjqxXGPD2ZQbOv0gl5OjuRugxlmjp2JPfJoDxnVbvY8 Z3i9Hipy9ItRGhyLqBgLgAYRht8AWHMFQdA7WUsxMVXJPTdbqmRJJxEKxWwNHXOqUDT1 lHFO3EuZZltIGz5hnP4GOnCTy1xSf0prpqqs2rsRR6O+7qTkQ5/n0H56lqKTzpxLsuWL Jhvy7NeEVCBeVvaMfhnWobswgzyvicMwWCpnGmJNtwproQHVTayHu3BFJghqp22y2OB+ 9xIQ== 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=GuwdEaCODpw2YqPL3tmItN8JDdLNy4XD53hEUd7pnS8=; b=HKcMFfDurxih+cNFL4kMwj45nvGNLYkvauz96FfGV+RiQPNskYRIr9gBYiFVY9aBCO tOaIRFT9PHo1Ca0n5+nrUX0H/YjCugpodXEL7YgxU981KrlIuSQYfTpcy7a0rxmYFDvP 18hjMKHuEPhTJP6c3kkIaYsScFBCjWd4Zb1GdQJKdPuW5SgMs0mLidXWUi6i12tsn1VN gnbhzLMK5dqEvtyX6d1CYAnwQQ3hLOqv2Q37QYC64l8kh4X548hhdcrcfmX6BFVnaNr2 jg5BloH7sZ/SUagVGI9wFyd8ZUBOdX0LEUbzgVH46Z1pl0t9M9cdEFcz6LNp/mmwnVdo cOtQ== X-Gm-Message-State: APjAAAU8c+dQruyJraVhlM8RqZE7IBB6ai7fuH+qitUGxaVFwJnMC9J3 BajNiZgoRxjJYY+jVQ1wRZSVnRiYyM4nOUGNwAM= X-Google-Smtp-Source: APXvYqxbEPcKsAKAmTvOlQQJTKm8kiopDzNrnfCOke/pPiN9PV7/r8dEVvOWd2V5oMnPvjl3SeP44t7od9s4ZTnYCv8= X-Received: by 2002:ac8:7104:: with SMTP id z4mr56923804qto.52.1563971160687; Wed, 24 Jul 2019 05:26:00 -0700 (PDT) MIME-Version: 1.0 References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> In-Reply-To: <20190723070141.GG60824@Space.Net> From: Jen Linkova Date: Wed, 24 Jul 2019 22:25:49 +1000 Message-ID: To: Gert Doering Cc: David Lamparter , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 12:26:03 -0000 On Tue, Jul 23, 2019 at 5:02 PM Gert Doering wrote: > > 2. is whoever configured multicast competent? > > The general assumption for on-link multicast should be "it's broadcast > or it is getting lost". I'd disagree with that statement but your experience may vary indeed. I'll add more text describing different scenarios but off top of my head using NA has one advantage over DAD: it reduces probability of disruption in case of address conflicts (again, for the rare scenario when the rightful owner does not have a cache entry for some reason). Ah, as I've said, my experience is that DAD packets have less chances to get through 'smart' WiFi infrastructure. > The general idea that on-link multicast is a positive aspect of IPv6 > is nice, but wrong. I see a subtle difference between 'wrong' and 'not true for every network'. -- SY, Jen Linkova aka Furry From nobody Wed Jul 24 05:48:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84FB1200C4 for ; Wed, 24 Jul 2019 05:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 GTxB7rpLnvjg for ; Wed, 24 Jul 2019 05:48:22 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD2112000F for ; Wed, 24 Jul 2019 05:48:21 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 355AC421A1 for ; Wed, 24 Jul 2019 14:48:19 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1E2CD41B58; Wed, 24 Jul 2019 14:48:19 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 0F9D5263F9; Wed, 24 Jul 2019 14:48:19 +0200 (CEST) Date: Wed, 24 Jul 2019 14:48:18 +0200 From: Gert Doering To: Jen Linkova Cc: Gert Doering , David Lamparter , v6ops list Message-ID: <20190724124818.GN60824@Space.Net> References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sEhs5GQW+P4Mb8ab" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 12:48:24 -0000 --sEhs5GQW+P4Mb8ab Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 24, 2019 at 10:25:49PM +1000, Jen Linkova wrote: > > The general idea that on-link multicast is a positive aspect of IPv6 > > is nice, but wrong. > I see a subtle difference between 'wrong' and 'not true for every network= '. Ideas are not bound to a particular network. If the benefits are small to zero, but it adds complexity that (inevitably) causes more breakage than "no added complexity", the overall aspect can no longer be called "positive= ". Kudos on your vendors if you never had any IPv6 issue that was related to multicast. I've had plenty (... incidentially, the first ever IPv6 related explosion I saw was a Linux E100 driver that misprogrammed=20 something regarding multicast filtering in the NIC, causing it to send=20 out multicast packets at wire speed... around 2002 or so). 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 --sEhs5GQW+P4Mb8ab Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl04U5IACgkQ31bAZeTO f8U+DA/+KdLLQHLwfAT/lcS4Bql7Z4pCTYqO3VkK0jgChRYctCrRZm3vbKzizPX0 oqRszXkTrH2/fMnOHcAeek945Sr6caUxAvtgOh9ZVr6S3hqeDSeDU+VNL/rpAWIL t/7ndj7oNv15eh0HIAsRb8dZgcnNBq3MCH6r0AxuH7PueB3jrNAH5DjYSpgc8ukV lcYmEE1ZWI5KZ2FudGLRj3cMk9cnNuFL/SBx7JOMQbh6bzQeaoeCy+QLOmw+sSem uDgl+Esosgm4rJnE21tbf3SBiFdEfeNI/V9hLFr/GOKNhxbexMag6ZLIjrGE//QQ 70YS/Ld7dIpNXpRlzdYKuVhtrBr5PQfF5mteNzkoGO+plIUeSvOaWBvyFOuSxjwa qOz17ft+FEx+mlbowVmf9qyIohSg9kR8AAaO0z+gufKAWhaSbcH3EIwLKv66DVWK nu2nkkRp3UvLUCV3MpcdvRuG48Da6f/G0EjKlwMR0Mdi5Eot6h8Xgerj4JDWMshf JLOe2lklZugn9CinSOeTsouHSXMfRA4kdWwgHkc9SuGyJ0s7ef4FUqDxptcfcXQx R1IfOJwpJ3b/Zpr77zM3VG2jlseSw5DGfo/K2buPivZfukhMKQh77s39N6GqNugt US3dwpmL2RWCzjpfnX/O1Og0goq1uBkKKO8swlhR9qg67rDc15Y= =1N9V -----END PGP SIGNATURE----- --sEhs5GQW+P4Mb8ab-- From nobody Wed Jul 24 06:03:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54895120125 for ; Wed, 24 Jul 2019 06:03:10 -0700 (PDT) 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, 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 header.b=ObUCxEXq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oBGCbPC0 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 OY8P6Y318PSJ for ; Wed, 24 Jul 2019 06:03:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C141200EC for ; Wed, 24 Jul 2019 06:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2969; q=dns/txt; s=iport; t=1563973387; x=1565182987; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7L4znVOfcLR5EL7Rr4RNjkmBCzOFXFQPsjzV3JA/mOk=; b=ObUCxEXqiwu8lCxMN3d8P0h6c+uGXxvkqEjl1IIsRLPnO6YV1N91R4kY x4iUaFyXrAxxuvCQoWRSHnAYrQsakSm8PrgMUfDQoe9uLKmQwb2IabA27 lLTcgB0pVUQ7bj38IbFzgafKkGbKgGuiq+KqBR/wrRnXBxq8/Ir3irBqw o=; IronPort-PHdr: =?us-ascii?q?9a23=3Ap1khMx3phFq68pHismDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAAAjVjhd/5ldJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGBQyQsA21VIAQLKodkA40RgluXUIEugSQDVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGEQAKCWCM1CA4BAwEBBAEBAgEGbYUeDIVKAQEBBAEBECg?= =?us-ascii?q?GAQEsCwELBAIBCA4DBAEBAR4QJwsdCAIEAQ0FCBqDAYFqAx0BAgyhUgKBOIh?= =?us-ascii?q?ggiOCeQEBBYEyAYNaGIITAwaBNAGEcYZtF4FAP4FXgU5+PoJhAQEDgWCDO4I?= =?us-ascii?q?mjFieEgkCghmGWI1Sgi2VXY03gTGGGJAJAgQCBAUCDgEBBYFSAjSBWHAVO4J?= =?us-ascii?q?sgkIMF4NOhRSFP3KBKYxyAQE?= X-IronPort-AV: E=Sophos;i="5.64,303,1559520000"; d="scan'208";a="601695508" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2019 13:03:03 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x6OD32CK020580 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2019 13:03:02 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 08:03:01 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 08:03:01 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Jul 2019 09:03:01 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FmOasxokIJR6bBTvjMqVvAy70PuQHB/jn0VSJgrGfKWXMP3HfuptTKfwtB2eU66WThEz+U/Hsd2GTPQHSu4+BDAuT1U6MpEGmkRHTkpcxVuWxMQSx6GCbcUZ4BxzvLm/MXzNKuY3VmjavaAB6AVYbQKMnbFzSkrYECet4YenyIKdiZpTWJOSVKSMSxj4uAD0Tl8iSIXnIJlcIxbLwl5KxV1ygACqj24YEwi9QJOW35ZpzsS2PBgANBuk3xLoOKXAtAjIiCCHLcuuO+hzh9JNRpZRfsld/V6oygixZJZV5KBD6j6uCJ9J+XwaQ0IrauUwXgA5wTBJw0FXBZolQ1fQBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7L4znVOfcLR5EL7Rr4RNjkmBCzOFXFQPsjzV3JA/mOk=; b=Am+6bQUAFkxqBPbEQbdhcuDY/7LabX4dT/QGgblUVwRmIBGvFkNDr0U9JaGPrmhxGPJSwROSHNFF9qoPSJ2DqHTr0FA3DlEfAwiX7FpxvDIq8/QBKISVeJfiMbZa6II/5lv9VuBJ95nSpk7ClXNFClNqLbQy52A6Jen2X3f7mrvKpb0WIL9sp/3ErDS5p2m6GVHxcTmMHA+y+1Rm5X5vNdUlFW/LbdW0i5fPrQhL6i/NReJIBE68G85cfiqxLBekbMaVGGPO8AhKqkEU0XsQtoC6krEyvQ1B3cI6qDQBKLrzkpo1gZJiVXR7dYP/PbK4zpCAlmb3FGOv/BXQyUUCHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7L4znVOfcLR5EL7Rr4RNjkmBCzOFXFQPsjzV3JA/mOk=; b=oBGCbPC0Wn/9VzrL8Yj8dkdXMLoBXEAi9ZPgPOi2/Oz2EJMciecMTDUEeebX5FOdKVr/aD+ny4qauWvKPI4ysaj21BKW0nMdV7pumuJl7ez5qOed4Vfw6lpdK+FVkqAXdS1+Sy2i31QEvKgYyVMeHltnr+PqxBVEUe5OlJ+iECQ= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4464.namprd11.prod.outlook.com (52.135.36.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Wed, 24 Jul 2019 13:02:59 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2094.013; Wed, 24 Jul 2019 13:02:59 +0000 From: "Pascal Thubert (pthubert)" To: Jen Linkova , Gert Doering CC: v6ops list Thread-Topic: [v6ops] privacy point re. unsolicited NA / router neighbor cache Thread-Index: AQHVQNXCsb8+ynbCQEKDQaXsO0WHxabXRG2AgAANRoCAAHWWgIAB7OWAgAABheA= Date: Wed, 24 Jul 2019 13:02:32 +0000 Deferred-Delivery: Wed, 24 Jul 2019 13:02:27 +0000 Message-ID: References: <20190722213727.GI34551@eidolon.nox.tf> <20190723000049.GJ34551@eidolon.nox.tf> <20190723070141.GG60824@Space.Net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1002::2c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 75284ec4-d09d-468b-4e50-08d7103740ed x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4464; x-ms-traffictypediagnostic: MN2PR11MB4464: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(366004)(136003)(346002)(199004)(189003)(13464003)(14454004)(99286004)(33656002)(6116002)(6436002)(110136005)(55016002)(6306002)(4326008)(86362001)(53936002)(81156014)(478600001)(81166006)(486006)(6246003)(966005)(8676002)(9686003)(11346002)(68736007)(2906002)(66556008)(66574012)(64756008)(256004)(76176011)(8936002)(476003)(46003)(229853002)(446003)(52536014)(76116006)(5660300002)(7696005)(66476007)(14444005)(66946007)(66446008)(71190400001)(186003)(71200400001)(102836004)(6506007)(6666004)(7736002)(305945005)(74316002)(316002)(25786009)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4464; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HUnfxe1vJiYtKrAinJb8MvtyGSC2WjSDfl0764uvXzbS7vSVuIrV8wy+bHIlNAUVfciDkLNiFwATsd2S2l4qkDqaPS4OdzAMQo9nrYVDWp+68bnk2nym4D4/6Tw+qV31Qe+lQzhaLi0GbdXubnMPZyEwub3fW/Eos3a316roUCm0aq1so78F0hnSCk5x3pQwvpf9EeBe3V2Ojo4Zl9ktSuQODuDwr6dFJ2Ma3DCpS9iK7+f7cEkKFTHnSOAqXnyqnmxtjYB1UZ3Ac7MIifWc9vzaTp/RNADmZihz/Zbb/3x8h6zwMGgefd5mCS19y3gwarUr6NtL51GDs338buExGm9P+UlHWt+AJ4Y4Kt6gUjQkXR1d4DmFrgP4AKQCIKw130iwT6BjL0UmAaCmM0j8Kvw73SXT5BVuYUnHernUqGk= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 75284ec4-d09d-468b-4e50-08d7103740ed X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 13:02:59.2205 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4464 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 13:03:10 -0000 Hello Jen Though I made a good living of a 'smart' infrastructure, I just hate the co= ncept of playing with the expectations of the protocols by dropping or chan= ging packets in intermediate boxes.=20 In a fashion doing that we're no better than NAT. We are 'obliged' to do it= because the way the archaic protocols uses the modern media would kill us.= =20 But one cannot be 'smart' enough. Things 'mostly' work, and there's a word = too many in that sentence. Like NAT, the consequence is that we are making it much harder for the next= generation to update the protocols because now they are afraid of all the = possible variations for vendor secret sauce.=20 Note: I tried to document some of that secret sauce in the past, e.g., http= s://tools.ietf.org/html/draft-thubert-savi-ra-throttler but did not raise m= uch interest/echo. Most of it is vendor specific and undocumented. In that = regards it is actually worse than NAT. Some 'smart' APs just drop RS on wir= eless interface. What if in the future I want to have a router there? And by hiding most of the problem under the snooping carpet, we are removin= g the incentive to update the archaic protocol. Doing so we are impairing t= he evolution of that protocol and condemning it to deprecation.=20 I want the upper layer protocols to get what they expect from the lower lay= ers end-to-end and to do that I want the upper layers to use the lower laye= r services wisely. This way we can make the infrastructure stupid again. All the best, Pascal > -----Original Message----- > From: v6ops On Behalf Of Jen Linkova > Sent: mercredi 24 juillet 2019 05:26 > To: Gert Doering > Cc: v6ops list > Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor c= ache >=20 > On Tue, Jul 23, 2019 at 5:02 PM Gert Doering wrote: > > > 2. is whoever configured multicast competent? > > > > The general assumption for on-link multicast should be "it's broadcast > > or it is getting lost". >=20 > I'd disagree with that statement but your experience may vary indeed. > I'll add more text describing different scenarios but off top of my head = using > NA has one advantage over DAD: > it reduces probability of disruption in case of address conflicts (again,= for the > rare scenario when the rightful owner does not have a cache entry for som= e > reason). >=20 > Ah, as I've said, my experience is that DAD packets have less chances to = get > through 'smart' WiFi infrastructure. >=20 > > The general idea that on-link multicast is a positive aspect of IPv6 > > is nice, but wrong. >=20 > I see a subtle difference between 'wrong' and 'not true for every network= '. >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 24 06:23:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100541201E0; Wed, 24 Jul 2019 06:23:56 -0700 (PDT) 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, 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 header.b=b5M/zg7m; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jZxAZ/a5 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 EW_QAmNS3oaR; Wed, 24 Jul 2019 06:23:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331B0120118; Wed, 24 Jul 2019 06:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=428; q=dns/txt; s=iport; t=1563974634; x=1565184234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MVKOwK3QH7RM+hfIaz7/7zG8bBRoOxSbV5x5PRmwMmA=; b=b5M/zg7mRAdEdd6wKZCRQqdylB+9Ys2s0CfytuWnEYbzNxcJWGPmKVKz OK7/XdO1ixaq1iZJ+69bw+FAySr6HceP4B5UUBjeOMOlAQSdUSaF74Vs6 UdLDMlYJhL9J3BTBJCEMO5vajRMqyCwo41v3M2yuH5B+IWBpHOl9VHB8P k=; IronPort-PHdr: =?us-ascii?q?9a23=3Adcm/vxdb7JLnsncQLanRsQktlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YjIrGs9BWXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAADCWjhd/5BdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGBQ1ADgUIgBAsqhB2DRwOMeowvhWyIEIEugSQ?= =?us-ascii?q?DVAkBAQEMAQEtAgEBhEACF4JCIzYHDgEDAQEEAQECAQZthR4MhUsCBBIREQw?= =?us-ascii?q?BATcBDwIBCBoCJgICAh8RFRACBAENBSKDAIFrAx0BAqFXAoE4iGBxgTKCeQE?= =?us-ascii?q?BBYJHgkYNC4ITCYEMKAGLXheBQD+BOB+CTD6CGoIqF4J0MoImjnibMkAJAoI?= =?us-ascii?q?ZkBiDdxuCHQGVbI03iT6OFAIEAgQFAg4BAQWBVwIvgVhwFWUBgkGCQoNxilN?= =?us-ascii?q?ygSmMcgEB?= X-IronPort-AV: E=Sophos;i="5.64,303,1559520000"; d="scan'208";a="601710146" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2019 13:23:53 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x6ODNr5i004534 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2019 13:23:53 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 08:23:52 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 09:23:51 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Jul 2019 09:23:51 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OQFKQYsvo10QxKnWWEC0RtCPLmIArcEw+w+bQhWL1VYo4h0bdAghJ+G753nCdCQwKOddZURYJtTLMwPTUrxS0oA0KHG9kUTYsma2sV+IrACcO8XIB6PhvK4relbL8QhWqizF9Elr64YalpqnzzREUbXzgw4uD4JZHYnWREnr1yklX5/Tt4Poq4oP2HVShOAwuhcpTN3fHG+b4jy+8NkNdVKKNGYjSzL39rRV5yoODvnwILMHmiAaGoLDNLBbannEJyDElq0EiXQV+Ges6I3ixvK6lV+a54U410/DR9WBqc0Lz8PoIO8koePRFupFGJ+zeLqBBh1Bn6tCD4I+mdO91g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MVKOwK3QH7RM+hfIaz7/7zG8bBRoOxSbV5x5PRmwMmA=; b=ZMv1FUgPKupB1IVWKNKf/YCWB3Un9K+1/FZix2zmirMQxoCkl2PVD4cg/4OJ8PfPGNqkHABqq9tc750I1CMPhr/h07XtiBv7Ioqd+crHwHssnoyrqWgySdmOxp/hpmWrQH/+GYUYizYB40FIHh+2LxiySn7SviTvYEoGdUztn2e4d2/ikCHdEPnUmKNqy7My3xYoK76IT7g23uNANHv2keJL6+41HBDKXwfs6pDHUH+W2PbO6xYQtOjH4dacuoMAsE1FRl9GEC0nmH9GUFQFKK3ywv1DeYJ4IDUuoutdZjiLKNx9vCo0lhWYU3z95LQLqY20pmuWzNZt70GdmexbgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MVKOwK3QH7RM+hfIaz7/7zG8bBRoOxSbV5x5PRmwMmA=; b=jZxAZ/a5/FApptCHLbdGjxcxbJVCjli2toULSRxJshBrGoDG1Cghde+SnVDbaLxiMZ7g6/yLf4BSu+e4y8q5dWh+QLhkZQrKl/XlfffcMfiNtGfuwDf6OZRECzSl4Wpy8MRsvkJAXSZJtryU/V3lT22Z2sKY803oIs+yNRm3SVE= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4334.namprd11.prod.outlook.com (52.135.38.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Wed, 24 Jul 2019 13:23:50 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c%7]) with mapi id 15.20.2094.017; Wed, 24 Jul 2019 13:23:50 +0000 From: "Eric Vyncke (evyncke)" To: Fred Baker , IPv6 Operations CC: 6man Chairs <6man-chairs@ietf.org> Thread-Topic: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft Thread-Index: AQHVQTDJH9zjQ3d62Em5tXg4fR1CYqbZgJyA Date: Wed, 24 Jul 2019 13:23:50 +0000 Message-ID: References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> In-Reply-To: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c8:1004::279] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d32e66c2-d48d-46f6-dfff-08d7103a2a8b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4334; x-ms-traffictypediagnostic: MN2PR11MB4334: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(39860400002)(346002)(396003)(199004)(189003)(186003)(25786009)(2906002)(102836004)(6512007)(8936002)(6116002)(316002)(66556008)(64756008)(66446008)(66476007)(91956017)(76116006)(110136005)(33656002)(58126008)(66946007)(46003)(99286004)(76176011)(558084003)(476003)(6506007)(256004)(2616005)(486006)(14454004)(81156014)(446003)(11346002)(81166006)(36756003)(8676002)(71200400001)(71190400001)(229853002)(4326008)(7736002)(6436002)(478600001)(53936002)(6246003)(5660300002)(68736007)(305945005)(6486002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4334; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lgfji2zVd4OjOE38Wxo1EbXwAKA3+2zqZjDBFwgmbYiuS9Wx1fd3V+NHBE5TlZ1Syn2ck/z2TMfYUpaxODXsXdiW70YBhx03+WamTPmWtKoAI80PwmtBfViPgdgWCFI2bLSXm28N6Mo3Dh6Ubm0maLk0MEQIiB9A+s+Y3Oqg+Qgk6GOrcUsT62RXlN6AlC6C16ksBx9Vj7NDGeW9PH+GEcKeXKFXfM/8e5Ug2K47bzyDW6apgJ1lx/CXyrneQanZoV/VrfbZNpp3X/EUcELLPKlHPa3bfVtis6Ucy01QqosDLd6T/L0R8iKc+dK0HB/rQDspc0EKOGNYsJ9XUnbhUS2pvX+K5Vs38W9a5oqMy6UeDARsxtfBmHXLydpjeQ8nooBN4jvSodAa8f1gWtk4Sy+hniS/VwEZIJLW1NLPnpA= Content-Type: text/plain; charset="utf-8" Content-ID: <9C46D3B8CFAAB44BA4450F07600B2884@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d32e66c2-d48d-46f6-dfff-08d7103a2a8b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 13:23:50.2502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4334 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 13:23:56 -0000 QXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvciwgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0 aGlzIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQuDQoNCu+7v09uIDIzLzA3LzIwMTksIDA0OjI5 LCAidjZvcHMgb24gYmVoYWxmIG9mIEZyZWQgQmFrZXIiIDx2Nm9wcy1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQogICAgRG8g d2UgYWdyZWUgdG8gdGFrZSBkcmFmdC1saW5rb3ZhLXY2b3BzLW5kLWNhY2hlLWluaXQgYXMgYSB3 b3JraW5nIGdyb3VwIGRyYWZ0Pw0KIA0KDQo= From nobody Wed Jul 24 07:44:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3DF1202C4; Wed, 24 Jul 2019 07:44:46 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_OZPPjilAco; Wed, 24 Jul 2019 07:44:43 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 94B77120284; Wed, 24 Jul 2019 07:44:43 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from ) id 1hqIVJ-000mqU-Ii; Wed, 24 Jul 2019 16:44:29 +0200 Date: Wed, 24 Jul 2019 16:44:29 +0200 From: David Lamparter To: "Pascal Thubert (pthubert)" Cc: Brian E Carpenter , David Lamparter , Fernando Gont , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Message-ID: <20190724144429.GL258193@eidolon.nox.tf> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 14:44:46 -0000 On Wed, Jul 24, 2019 at 11:05:38AM +0000, Pascal Thubert (pthubert) wrote: > I’ve participated to multiple corridor discussions on that topic and > seen agreement that NA(O) to ff02::2 that proactively sets the cache > in the routers is better than the current state of affairs which is a > NS from the router that is broadcasted to all hosts at L2. I would like to argue that our approach to this issue should be "additive", and if we can easily run fixes from multiple angles it might be worth doing so. In particular: - DAD gleaning is a router-only fix for this issue that requires no host changes - sending any kind of unicast probe that triggers a response is a host-only fix for this issue that requires no router changes - sending NA(O) to ff02::2 is a router and host change The fact that any of these may not work in some particular setup (e.g. wifi controller crapping on ND, shitty multicast snooping) is all the more reason to do more than one. >From a privacy perspective I'm fine with sending NA(O) to ff02::2 since that is theoretically "only routers" in a network that were to limit multicast propagation. It's not ff02::1, which is all I ask. I'm also happy if we document NA(O) to ff02::2 as the "long-term" fix while doing DAD gleaning and/or unicast probes as "short-term" fixes. Lastly, NA(O) to ff02::2 should go through 6man IMHO. Whether either of the other 2 options I listed above needs that I don't know. Cheers, -David From nobody Wed Jul 24 07:51:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18708120272 for ; Wed, 24 Jul 2019 07:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, 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 7GBnCpulZXrB for ; Wed, 24 Jul 2019 07:51:03 -0700 (PDT) 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 2BF0512006F for ; Wed, 24 Jul 2019 07:51:03 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id f17so41888865wme.2 for ; Wed, 24 Jul 2019 07:51:03 -0700 (PDT) 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=VlIHFrbncTvNTMWfGeLAUsInPJRlYxKXkhFLnrr+i2Y=; b=lUNgI9v76jpMFHDqXIe36pBpoc0RL3XuEc9DGb5gc4WAOjp8AUOg/IeuJ9gPmJA1M9 ZDuS33KZ+3k7wD68rLFqiHH6ULfJazYS7wX5uXl2rS5c7eskU1icAvfph6wGwDcevuA7 QtNN00hSU4wT47SEvuN0KDJa5MVddE8BQKHLv54aoiFAPvIvZvglGiX6TiMmnGn48f2j oRPKAOAJknK9am8JnR5CUaiVCmowcMLKW3oxavYrof0Wf6xlMZT8OwmSZTT5z7JotRcL MLML8Czg1dCNYWeRMYotYKNbMvBIjbR5Ueua32J4Z9Hl6dk6cLj+KjG7iD+Z2567gK6K lAbA== 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=VlIHFrbncTvNTMWfGeLAUsInPJRlYxKXkhFLnrr+i2Y=; b=MNv11NyIJjIxXkRYirmDYviHH1vE5y0A49DR71svsgzNYH68xKgnbZbbCHlUIv9Nar AWvKZ0EB9pb1DKPzS0dKMa4BfyHDT4rw7XS/2xmStrecfszcl/SKkw2yXrUbbuNaSjij VGsy0AYbaAZJ3nVX/JIKR2KPha3BzMcMs0O/xEhf9XC+iXhCgbFKdWGawKUhvkwpxRCN /NDStA//CIA4h2gzPhMGmynpG4QsazUfkkUiUILVCRtjnlqE/2+5WOxzNbAMg+ylns6m PnBRbA7tME9tcCx3daNs1sa52S3y9aJGbBD80fbfCSOFvEnA8ty9nd8LhkPhgcHCUX2v 4fCQ== X-Gm-Message-State: APjAAAV5Mh8IgKsSMkrAyQZxXmgVJVHoTxuGXylXrG9TDZTFOD4d14DV Em8oNiIh+BFYlTSALkhkF+aFAUuzF7sFoDVav7U6tw== X-Google-Smtp-Source: APXvYqxNYfQ0VUOwZVSprC4zqdNdWKcGjfBtz5ciUPVBu97UhuDDbgXH5B8hChABSOge204lnRfcnMZBvwzKpSwowZ0= X-Received: by 2002:a1c:ac81:: with SMTP id v123mr76925006wme.145.1563979861390; Wed, 24 Jul 2019 07:51:01 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> In-Reply-To: <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> From: Lorenzo Colitti Date: Wed, 24 Jul 2019 10:50:46 -0400 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Brian E Carpenter , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org>, Fernando Gont Content-Type: multipart/alternative; boundary="000000000000136c1a058e6e7073" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 14:51:09 -0000 --000000000000136c1a058e6e7073 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2019 at 7:06 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Another thing that the draft should do imho is a more comprehensive revie= w > of the problems that are associated with reactive. Coming from the router > side I=E2=80=99m probably more sensitive to that than others and I=E2=80= =99d de happy to > contribute. > I don't think that belongs in this draft though. That's more of a design question and 6man seems like the right place for it. This draft is operationally focused on a specific problem and examines operational solutions within the current standards. It can, and does, mention that switching to a registration model might fix this problem, and I don't think it should go deeper than that. --000000000000136c1a058e6e7073 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another thing that the draft= should do imho is a more comprehensive review of the problems that are ass= ociated with reactive. Coming from the router side I=E2=80=99m probably mor= e sensitive to that than others and I=E2=80=99d de happy to contribute.
=

I don't think that belongs in this dra= ft though. That's more of a design question and 6man seems like the rig= ht place for it. This draft is operationally focused on a specific problem = and examines operational solutions within the current standards. It can, an= d does, mention that switching to a registration model might fix this probl= em, and I don't think it should go deeper than that.
--000000000000136c1a058e6e7073-- From nobody Wed Jul 24 07:58:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574E61200E3; Wed, 24 Jul 2019 07:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 dy2yCRvLxwJV; Wed, 24 Jul 2019 07:58:19 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 2F0DA12006F; Wed, 24 Jul 2019 07:58:19 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from ) id 1hqIib-000tUq-Pp; Wed, 24 Jul 2019 16:58:14 +0200 Date: Wed, 24 Jul 2019 16:58:13 +0200 From: David Lamparter To: Lorenzo Colitti Cc: "Pascal Thubert (pthubert)" , IPv6 Operations , Fernando Gont , 6man Chairs <6man-chairs@ietf.org> Message-ID: <20190724145813.GM258193@eidolon.nox.tf> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 14:58:21 -0000 On Wed, Jul 24, 2019 at 10:50:46AM -0400, Lorenzo Colitti wrote: > On Wed, Jul 24, 2019 at 7:06 AM Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > > > Another thing that the draft should do imho is a more comprehensive review > > of the problems that are associated with reactive. Coming from the router > > side I’m probably more sensitive to that than others and I’d de happy to > > contribute. > > > > I don't think that belongs in this draft though. That's more of a design > question and 6man seems like the right place for it. This draft is > operationally focused on a specific problem and examines operational > solutions within the current standards. It can, and does, mention that > switching to a registration model might fix this problem, and I don't think > it should go deeper than that. Oh yes, we've completely run off far into solution space here. I agree that we should get this draft out to document the problem; pointing out possible solutions - nonexhaustively, without detail, and without actually suggesting - is as far as I think we can take it. Maybe stop even shorter than that. From nobody Wed Jul 24 10:05:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5024012028E; Wed, 24 Jul 2019 10:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-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 s0GVnkqWiB4O; Wed, 24 Jul 2019 10:05:49 -0700 (PDT) Received: from clarinet.employees.org (unknown [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B5412027B; Wed, 24 Jul 2019 10:05:49 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2001:67c:370:128:9051:e242:9b2f:b85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 486BF4E11AAD; Wed, 24 Jul 2019 17:05:48 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B8FA81954EF1; Wed, 24 Jul 2019 13:05:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Ole Troan In-Reply-To: <20190723205549.GG258193@eidolon.nox.tf> Date: Wed, 24 Jul 2019 13:05:46 -0400 Cc: Jen Linkova , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <0316D891-6DAC-45CB-9B8B-41B1664072E9@employees.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org> <20190723205549.GG258193@eidolon.nox.tf> To: David Lamparter X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 17:05:51 -0000 David, >>=20 >> I believe this requires an update to RFC4861. And I don't see any >> reason why that work shouldn't happen in 6man. >=20 > Ack. However, "gratuitous ND" is only one possible fix here, and a > costly one at that since it needs updates on both the host to send = this > new "gratuitous ND" as well as the router to understand and process = it. As a matter of clarification. By "gratuitous ND" I was referring to the solution where a host would = send an NA, and the router would if having no NC entry for it, would = create one, as opposed to ignore the ND. Cheers, Ole= From nobody Wed Jul 24 10:25:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6131205FF; Wed, 24 Jul 2019 10:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=SE+AV9QI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ieG9bFgI 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 D0fieO_p4pNp; Wed, 24 Jul 2019 10:25:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F03C1205DD; Wed, 24 Jul 2019 10:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8728; q=dns/txt; s=iport; t=1563989107; x=1565198707; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AefeoG594dsCC/Z0cZb7CmSmetbhHlfn2I5L4B70iGM=; b=SE+AV9QIN29wt8NEchsKMPpFaOvg6grwr1KEQj9I4aNr9bLSlgM31ogn KdEoDV0D6LJFUdBMXCRQeQbIcEV5RPLjx5R9O19+n/TdqZqkGfOGJVmpQ g6OFq3/wYoWsp+laj31Zdt4N4T2+fZo7fKfV3MGNEOWm2uCEhXzHWrOo1 s=; IronPort-PHdr: =?us-ascii?q?9a23=3AtIDV8xMZteLFOMBTCKsl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAAB2kzhd/49dJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAUBAQELAYEUL1ADbVUgBAsqhB2DRwOMe4JbiVSJJ4RVgS6BJAN?= =?us-ascii?q?UCQEBAQwBAS0CAQGEQAIXgkIjNQgOAQMBAQQBAQIBBm2FHgyFSgEBAQEDEhE?= =?us-ascii?q?KEwEBNwEPAgEIEQQBASgDAgICHxEUCQgCBA4FCBMHgwGBHU0DHQECoWYCgTi?= =?us-ascii?q?IYHGBMoJ5AQEFhQwNC4ITCYE0AYtfF4FAP4FXgkw+ghqCLDSCVTKCJo58hH+?= =?us-ascii?q?WNEAJAoIZkBmEEpgKlnaOFQIEAgQFAg4BAQWBUQE2N4EhcBWDJ4JCg3GKU3I?= =?us-ascii?q?BgSiOAAEB?= X-IronPort-AV: E=Sophos;i="5.64,303,1559520000"; d="scan'208,217";a="601467558" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2019 17:25:05 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x6OHP4e0029823 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2019 17:25:04 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 12:25:04 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 12:25:03 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Jul 2019 12:25:03 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WuxYwS8hEmnEqPmc6I3QbuTw26+C9rRey3hYKGae+AkQBxAkrvGepFeVY7SfF4Zzr6O/7BKE2CWVRMvedH9iPvDjkdzD18oc5wEGuUpMqu0jFufXuDW8Vjx2qpMq+RQqKtEF2aUC5ZZZc5gI8gBRRUwOQK6dWZ8Jt+8K8/UxFQbna9ovB1H0wY8rri70YjU/mblAb8jBXcPxKp6D5skk/x4WE4foIjyVbL0X8nyQdzeDLPcEx1YA0AG7OXPnCvAcffrPXfRI89sudzKO4y75R0lBsLijHyCilYh9JQ3j9AyXD5TyOvHkE5M/dp5irtZaGhSfGSY8oMNEacSLoWSrhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AefeoG594dsCC/Z0cZb7CmSmetbhHlfn2I5L4B70iGM=; b=LYGckJpkUKKdAb4T4r9S5c/9ANmvDmIHd3+GAg9mNuQvhK7RQy2DiPyFfqLTQVAhYhQVAQw5MnxK3Wgtt1TXkZynpcYFE96Wmp7DE1+6vr0dNEdGBjmrt28lDAy0pHAmzGzsdS/RK7+R8b8fxLWjVZzro9IVFwg1A78CQd+r0Ay4EL4fQV9xqN8bCVXUCnaYmoN+N0dl8vHObg0gHRwCfzYFSScKX7IUEkWBfI1eV3HVStxB4mUDIcN9Qky3ZUSb8hrlsxvyJSX9u2BKurLNTKWXCj7cVkKLxZgitAfYkOGD/lUMRriHqzAeDgCoczxejcmoJVrJ+jZgmWnZkf+OHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AefeoG594dsCC/Z0cZb7CmSmetbhHlfn2I5L4B70iGM=; b=ieG9bFgIbmqztws91mIm3OfmjInPaSK5wt1+sGKbk2+oP49r0Gcdsuy+4koi+eXAOxHVHZSENI9j+y1EABCYIIU5kvg1M+Pfw1JBZzvQECg6hP/ok2TMWGCB4HPTeTYzy1EywJ7stiYYuEg4cTfS4fGBP0c8ntrdUryJ59erYm8= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Wed, 24 Jul 2019 17:25:02 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2094.013; Wed, 24 Jul 2019 17:25:02 +0000 From: "Pascal Thubert (pthubert)" To: Lorenzo Colitti CC: Brian E Carpenter , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org>, Fernando Gont Thread-Topic: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft Thread-Index: AQHVQTDJQIJu4w3G6EWWHtrdc581RKbYFBSAgABqQoCAABZcgIAAbdEAgACajYCAAD7oAIAAKQ2w Date: Wed, 24 Jul 2019 17:24:35 +0000 Deferred-Delivery: Wed, 24 Jul 2019 17:24:13 +0000 Message-ID: References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1002::2c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3ca3383c-46ea-4275-59e2-08d7105bdc7a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3565; x-ms-traffictypediagnostic: MN2PR11MB3565: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(346002)(376002)(366004)(189003)(199004)(476003)(9686003)(66556008)(81166006)(66946007)(5660300002)(76116006)(81156014)(66446008)(8676002)(14454004)(52536014)(4326008)(66476007)(55016002)(8936002)(68736007)(64756008)(6246003)(6306002)(236005)(53936002)(54896002)(71200400001)(86362001)(229853002)(256004)(74316002)(7736002)(2906002)(54906003)(71190400001)(6436002)(102836004)(66574012)(446003)(6116002)(486006)(25786009)(790700001)(478600001)(186003)(53546011)(11346002)(7696005)(316002)(46003)(76176011)(6506007)(6916009)(99286004)(33656002)(6666004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3565; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wq8FKLK9Fvlj+gnQk1m23gdjv8bFaAgOJdi1QkSFReUlHrHTJPCEvdYG26PcY77RVCUQNEl/5w6vwzyBjsd772+guoa5Wv1nB8Ao6oJIkoVzr9sNC35kwCvY+ag885G3rKfU1warlaYwqc8T2Ndk6gjLdCdTUObTaIysXLT/lXxXbiPzgmxMTGs7q57MeyptRZzRhmvr2rPhYT6Tz15tz3wJ5siQfdpUcbyK1LfJJlM6rM1nvJ9SpELUQDVekPp12hzLysfHSf0kHDaaQ3axTXttoFl+4mwqbxh+KkbCg0Z/pDKKe1g6SrcThar3r54O3t4Xlv0sIncRReFKGB1c8/25KFFnQfijjRva2uSOzDhU05PygOl7dWtrHO/ZRSLXkPahgxSGDWaJ9w8QcueItErxlyibeRQ0T1yUbaf1OxI= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565D0296C566032E6C2967CD8C60MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3ca3383c-46ea-4275-59e2-08d7105bdc7a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 17:25:02.1929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3565 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 17:25:14 -0000 --_000_MN2PR11MB3565D0296C566032E6C2967CD8C60MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pz8/DQoNClNvcnJ5IHRoZSByZXNwb25zZSBkb2VzIG5vdCBtYXRjaCB0aGUgcXVlc3Rpb24uIERv IEkgbmVlZCB0byByZXdvcmQ/DQoNClRoZXJlIGFyZSBhIG51bWJlciBvZiBvcGVyYXRpb25hbCBw cm9ibGVtcyBhcm91bmQgdGhlIHNhbWUgcm9vdCBjYXVzZSBhbmQgdGhhdCBwcm9ibGVtIHNwYWNl IG5lZWRzIHRvIGJlIGNvdmVyZWQgaW4gYSBiaXQgbW9yZSBzeXN0ZW1pYyB3YXkuDQpUaGlzIHdh eSB3ZSBjYW4gYXNzZXNzIGNvdmVyYWdlIG9mIHRoZSB2YXJpb3VzIHJlc3BvbnNlcywgdGFjdGlj YWwgYW5kIHN0cmF0ZWdpYywgaW1wYWN0aW5nIGhvc3Qgcm91dGVycyBvciBib3RoLCBhbmQgSeKA mW0gaGFwcHkgdG8gdGFsayBzb2x1dGlvbiBsYXRlciBhbmQgd2hlcmV2ZXIuDQoNCkFsbCB0aGUg YmVzdCwNCg0KUGFzY2FsDQoNCkZyb206IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUu Y29tPg0KU2VudDogbWVyY3JlZGkgMjQganVpbGxldCAyMDE5IDA3OjUxDQpUbzogUGFzY2FsIFRo dWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPg0KQ2M6IEJyaWFuIEUgQ2FycGVu dGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+OyBJUHY2IE9wZXJhdGlvbnMgPHY2b3Bz QGlldGYub3JnPjsgNm1hbiBDaGFpcnMgPDZtYW4tY2hhaXJzQGlldGYub3JnPjsgRmVybmFuZG8g R29udCA8ZmVybmFuZG9AZ29udC5jb20uYXI+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1s aW5rb3ZhLXY2b3BzLW5kLWNhY2hlLWluaXQgdG8gd29ya2luZyBncm91cCBkcmFmdA0KDQpPbiBX ZWQsIEp1bCAyNCwgMjAxOSBhdCA3OjA2IEFNIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0 aHViZXJ0QGNpc2NvLmNvbTxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPj4gd3JvdGU6DQpBbm90 aGVyIHRoaW5nIHRoYXQgdGhlIGRyYWZ0IHNob3VsZCBkbyBpbWhvIGlzIGEgbW9yZSBjb21wcmVo ZW5zaXZlIHJldmlldyBvZiB0aGUgcHJvYmxlbXMgdGhhdCBhcmUgYXNzb2NpYXRlZCB3aXRoIHJl YWN0aXZlLiBDb21pbmcgZnJvbSB0aGUgcm91dGVyIHNpZGUgSeKAmW0gcHJvYmFibHkgbW9yZSBz ZW5zaXRpdmUgdG8gdGhhdCB0aGFuIG90aGVycyBhbmQgSeKAmWQgZGUgaGFwcHkgdG8gY29udHJp YnV0ZS4NCg0KSSBkb24ndCB0aGluayB0aGF0IGJlbG9uZ3MgaW4gdGhpcyBkcmFmdCB0aG91Z2gu IFRoYXQncyBtb3JlIG9mIGEgZGVzaWduIHF1ZXN0aW9uIGFuZCA2bWFuIHNlZW1zIGxpa2UgdGhl IHJpZ2h0IHBsYWNlIGZvciBpdC4gVGhpcyBkcmFmdCBpcyBvcGVyYXRpb25hbGx5IGZvY3VzZWQg b24gYSBzcGVjaWZpYyBwcm9ibGVtIGFuZCBleGFtaW5lcyBvcGVyYXRpb25hbCBzb2x1dGlvbnMg d2l0aGluIHRoZSBjdXJyZW50IHN0YW5kYXJkcy4gSXQgY2FuLCBhbmQgZG9lcywgbWVudGlvbiB0 aGF0IHN3aXRjaGluZyB0byBhIHJlZ2lzdHJhdGlvbiBtb2RlbCBtaWdodCBmaXggdGhpcyBwcm9i bGVtLCBhbmQgSSBkb24ndCB0aGluayBpdCBzaG91bGQgZ28gZGVlcGVyIHRoYW4gdGhhdC4NCg== --_000_MN2PR11MB3565D0296C566032E6C2967CD8C60MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPj8/PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSB0aGUgcmVzcG9uc2Ug ZG9lcyBub3QgbWF0Y2ggdGhlIHF1ZXN0aW9uLiBEbyBJIG5lZWQgdG8gcmV3b3JkPw0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBhIG51bWJlciBvZiBvcGVyYXRpb25hbCBwcm9i bGVtcyBhcm91bmQgdGhlIHNhbWUgcm9vdCBjYXVzZSBhbmQgdGhhdCBwcm9ibGVtIHNwYWNlIG5l ZWRzIHRvIGJlIGNvdmVyZWQgaW4gYSBiaXQgbW9yZSBzeXN0ZW1pYyB3YXkuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd2F5IHdlIGNhbiBhc3Nlc3MgY292ZXJh Z2Ugb2YgdGhlIHZhcmlvdXMgcmVzcG9uc2VzLCB0YWN0aWNhbCBhbmQgc3RyYXRlZ2ljLCBpbXBh Y3RpbmcgaG9zdCByb3V0ZXJzIG9yIGJvdGgsIGFuZCBJ4oCZbSBoYXBweSB0byB0YWxrIHNvbHV0 aW9uIGxhdGVyIGFuZCB3aGVyZXZlci4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgdGhl IGJlc3QsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhc2NhbDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPiBMb3JlbnpvIENvbGl0dGkgJmx0O2xvcmVuem9AZ29vZ2xlLmNv bSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IG1lcmNyZWRpIDI0IGp1aWxsZXQgMjAxOSAwNzo1MTxi cj4NCjxiPlRvOjwvYj4gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7cHRodWJlcnRAY2lz Y28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQnJpYW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFuLmUu Y2FycGVudGVyQGdtYWlsLmNvbSZndDs7IElQdjYgT3BlcmF0aW9ucyAmbHQ7djZvcHNAaWV0Zi5v cmcmZ3Q7OyA2bWFuIENoYWlycyAmbHQ7Nm1hbi1jaGFpcnNAaWV0Zi5vcmcmZ3Q7OyBGZXJuYW5k byBHb250ICZsdDtmZXJuYW5kb0Bnb250LmNvbS5hciZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFt2Nm9wc10gZHJhZnQtbGlua292YS12Nm9wcy1uZC1jYWNoZS1pbml0IHRvIHdvcmtpbmcg Z3JvdXAgZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gV2VkLCBKdWwgMjQsIDIwMTkgYXQgNzowNiBBTSBQYXNjYWwgVGh1YmVydCAo cHRodWJlcnQpICZsdDs8YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+cHRodWJlcnRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhl ciB0aGluZyB0aGF0IHRoZSBkcmFmdCBzaG91bGQgZG8gaW1obyBpcyBhIG1vcmUgY29tcHJlaGVu c2l2ZSByZXZpZXcgb2YgdGhlIHByb2JsZW1zIHRoYXQgYXJlIGFzc29jaWF0ZWQgd2l0aCByZWFj dGl2ZS4gQ29taW5nIGZyb20gdGhlIHJvdXRlciBzaWRlIEnigJltIHByb2JhYmx5IG1vcmUgc2Vu c2l0aXZlIHRvIHRoYXQgdGhhbiBvdGhlcnMgYW5kIEnigJlkIGRlIGhhcHB5IHRvIGNvbnRyaWJ1 dGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRvbid0IHRoaW5rIHRoYXQgYmVsb25ncyBpbiB0aGlzIGRyYWZ0IHRob3VnaC4g VGhhdCdzIG1vcmUgb2YgYSBkZXNpZ24gcXVlc3Rpb24gYW5kIDZtYW4gc2VlbXMgbGlrZSB0aGUg cmlnaHQgcGxhY2UgZm9yIGl0LiBUaGlzIGRyYWZ0IGlzIG9wZXJhdGlvbmFsbHkgZm9jdXNlZCBv biBhIHNwZWNpZmljIHByb2JsZW0gYW5kIGV4YW1pbmVzIG9wZXJhdGlvbmFsIHNvbHV0aW9ucyB3 aXRoaW4gdGhlIGN1cnJlbnQNCiBzdGFuZGFyZHMuIEl0IGNhbiwgYW5kIGRvZXMsIG1lbnRpb24g dGhhdCBzd2l0Y2hpbmcgdG8gYSByZWdpc3RyYXRpb24gbW9kZWwgbWlnaHQgZml4IHRoaXMgcHJv YmxlbSwgYW5kIEkgZG9uJ3QgdGhpbmsgaXQgc2hvdWxkIGdvIGRlZXBlciB0aGFuIHRoYXQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB3565D0296C566032E6C2967CD8C60MN2PR11MB3565namp_-- From nobody Wed Jul 24 13:27:19 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE5D120663 for ; Wed, 24 Jul 2019 13:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, 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 NK78HwOEt1PF for ; Wed, 24 Jul 2019 13:27:11 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 CFE08120654 for ; Wed, 24 Jul 2019 13:27:10 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id 207so42959848wma.1 for ; Wed, 24 Jul 2019 13:27:10 -0700 (PDT) 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=mlbhZ/fwkoTQ6AKWSZqn1t3ZecWlEiUz0h4f2DoQOqk=; b=NrYf5zoB0GbD5di3V7pJN8ElnoMyrb1naSj3OxB3X6AwFPqxL9zXaz7MCWMOHqzQKp Uhp8pqz9WPu/xg1ZYIzSM5d7ct3IugTSO8sFMu7B510i0Mx2/M3ziUnMNArwB2LiVn7a J32L0Ar6Djqnq0jtnqrrSzOb16QjnlV1LDsPORZ3i44EoRVF6Gxi+dgkAznZpH/KYUhO UIDf+ZPOOb4vGWTx7/dx2LbcHDyJ5y9wwN7RYBRc2LUO+XljuEP/pgw2cV25vNSdHPRD GzjpfN968Ny0CsXuIilFuwzCBxLCEJaJpopOx6MopALc37TKEfOSQTtgPAQUHajsrtc4 zlqg== 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=mlbhZ/fwkoTQ6AKWSZqn1t3ZecWlEiUz0h4f2DoQOqk=; b=nzw1ZdwLr+0ZbRE34jyGNGXZXh6k/4Ir4iyI4O+g7XaDZ6wdS/hsOtaXw9RacrQHA8 VwC7sKGrtszt5BgXl2eCY/pqcw/BTiuCh4E+UHgnxjL+SnPE9g0CQOV+yyfWXND/xBYr OdTLrLfDeujRXdYDYT/CG2MJYgNL/TR09yqdeESSAR6uYpVELPUkuwhCcHNED4cEjSBE Z9AzQU/PLR0QSm5ITkhpe/nKq0QKuNnL2T1AXeDKV9uB7zaQFHHQfq0ZYioEglxgRuWg 7VvtTi5c7wVazt1N4wexZIGKYtJ6P7M5/LeRK6xwcg0zqmY6f85UJNfHdXdtL8ijcoPE YlGQ== X-Gm-Message-State: APjAAAVUyCZFbUjc0V2m65wTuueZ+mTmfp/JxJjLGLmDNQzCCsj1wONi MfJV9VQBlkzeAeg0U87gsy8lrnQmYvepaqJiUoQ21w== X-Google-Smtp-Source: APXvYqwqVoF/Ig69aH8R03AAe/WO7Uw9VJf6QyXITZ2/gRsEQZ4XZG8dFz6+ipqxqKnAcC99XoQf6hivPVHxfDmCbgw= X-Received: by 2002:a1c:35c2:: with SMTP id c185mr74570903wma.58.1564000028736; Wed, 24 Jul 2019 13:27:08 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> In-Reply-To: From: Lorenzo Colitti Date: Wed, 24 Jul 2019 16:26:54 -0400 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Brian E Carpenter , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org>, Fernando Gont Content-Type: multipart/alternative; boundary="0000000000002496e0058e7322fd" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 20:27:18 -0000 --0000000000002496e0058e7322fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2019 at 1:25 PM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Sorry the response does not match the question. Do I need to reword? > > > > There are a number of operational problems around the same root cause and > that problem space needs to be covered in a bit more systemic way. > > This way we can assess coverage of the various responses, tactical and > strategic, impacting host routers or both, and I=E2=80=99m happy to talk = solution > later and wherever. > I fear that if we have a discussion about this it will quickly turn into a discussion of what is and isn't an "operational problem" as opposed to "a good trade-off". It seems simpler to focus on this specific problem given that we already have a draft for it. --0000000000002496e0058e7322fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 24, 2019 at 1:25 PM Pascal Th= ubert (pthubert) <pthubert@cisco.c= om> wrote:

Sorry the response does not match the question. Do I= need to reword?

=C2=A0

There are a number of operational problems around th= e same root cause and that problem space needs to be covered in a bit more = systemic way.

This way we can assess coverage of the various respo= nses, tactical and strategic, impacting host routers or both, and I=E2=80= =99m happy to talk solution later and wherever.


I fear that if we have a discussion about this it will= quickly turn into a discussion=C2=A0of what is and isn't an=C2=A0"= ;operational problem" as opposed to "a good trade-off". It s= eems simpler to focus on this specific problem given that we already have a= draft for it.
--0000000000002496e0058e7322fd-- From nobody Wed Jul 24 14:48:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B161206A6; Wed, 24 Jul 2019 14:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7PUXA6UrQKwI; Wed, 24 Jul 2019 14:48:39 -0700 (PDT) Received: from clarinet.employees.org (unknown [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6028F12063C; Wed, 24 Jul 2019 14:48:39 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2001:67c:370:128:a458:6d04:5f3e:464d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 6CA114E11B7F; Wed, 24 Jul 2019 21:48:38 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id A8CB61957FC0; Wed, 24 Jul 2019 17:48:36 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Ole Troan In-Reply-To: Date: Wed, 24 Jul 2019 17:48:36 -0400 Cc: "Pascal Thubert (pthubert)" , IPv6 Operations , Fernando Gont , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <10332310-81CE-4267-B677-ABAD063BFB85@employees.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 21:48:46 -0000 > On 24 Jul 2019, at 16:26, Lorenzo Colitti = wrote: >=20 > On Wed, Jul 24, 2019 at 1:25 PM Pascal Thubert (pthubert) = wrote: > Sorry the response does not match the question. Do I need to reword? >=20 > =20 >=20 > There are a number of operational problems around the same root cause = and that problem space needs to be covered in a bit more systemic way. >=20 > This way we can assess coverage of the various responses, tactical and = strategic, impacting host routers or both, and I=E2=80=99m happy to talk = solution later and wherever. >=20 >=20 > I fear that if we have a discussion about this it will quickly turn = into a discussion of what is and isn't an "operational problem" as = opposed to "a good trade-off". It seems simpler to focus on this = specific problem given that we already have a draft for it. Right. I would be happy to see a separate discussion in 6man about what from = the work in 6lo et al we could benefit from integrating into the IPv6 = core protocol suite. It might have been in Pascal's draft's, but I think = we as a group would benefit from a summary using our (6man) terms for = things. Ole= From nobody Thu Jul 25 03:22:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686DA12012E; Thu, 25 Jul 2019 03:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 S0eWnpOIYXkr; Thu, 25 Jul 2019 03:22:28 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858361200E7; Thu, 25 Jul 2019 03:22:28 -0700 (PDT) Received: from [192.168.0.107] (unknown [196.94.149.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 754AC851CE; Thu, 25 Jul 2019 12:22:15 +0200 (CEST) To: Jen Linkova , Fernando Gont Cc: IPv6 Operations , 6man Chairs <6man-chairs@ietf.org> References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <6421eae0-1d77-0bba-1b11-58248916f8a7@si6networks.com> Date: Wed, 24 Jul 2019 13:00:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 10:22:30 -0000 On 23/7/19 20:51, Jen Linkova wrote: > On Wed, Jul 24, 2019 at 4:39 AM Fernando Gont wrote: >> On 23/7/19 12:39, Brian E Carpenter wrote: >>> 1) Yes, we should *obviously* do this. >>> 2) If the charter prevents that, fix the charter. >> >> I'm all for fixing problems and getting stuff done. And, if there's no >> other way than fixing the charter, so be it. >> >> However, it would seem to me that, the "bug" here is that we're >> defaulting to "6man wouldn't get this done, so let's do it elsewhere". > > I'm confused. I'm not sure I understand how you came to the conclusion > that we are trying fix the protocol in v6ops because 6man wouldn't do > this. This part of section 3, o Hosts SHOULD send at least one unsolicited NA packet to all- routers multicast address (ff02::2) as soon as one of the following events happens: * (if Optimistic DAD is used): a new Optimistic GUA is assigned to the host interface. * (if Optimistic DAD is not used): a GUA changes the state from tentative to preferred. seems to me a protocol update. In any case, my comment was meant to say "if there's a problem to be solved, don't be shy..there's nothing scary about updating the protocol spec" > First of all, main goal of the draft in question is to describe an > operational problem and discuss potential ways to deal with it. That's certainly perfectly fine and valuable, per-se. > Based on the analysis the draft currently suggests that there are > "valid reasons in particular circumstances when the particular > behavior (violate SHOULD NOT and create a STALE entry upon receiving > an unsolicited NA) is acceptable or even useful". It would seem to me that when a spec says "SHOULD/SHOULD NOT", there's leeway for implementations to don't follow that. However, if there is a case where the default advice actually is the opposite, one should update the original advice/requirement. > It does not change > ND as a protocol because RFC4861 does allow such behaviour (otherwise > it would have said 'MUST NOT') so I'm inclined to say that it's not a > protocol change.. If one were to pursue this way of solving the problem, wouldn't we want the default advice to contradict (SHOULD vs SHOULD NOT) what's in RFC4861 > However I see why it might be seen as a protocol change and I'm > willing to either: > - write an additional 1-page draft for 6man updating 4861 based on > analysis provided in this draft; > - get this draft adopted and/or reviewed by 6man > - whatever other ways to make sure all appropriate reviews are done, " full > implications should be understood and the case carefully weighed" etc ;) I'd say describe the problem and evaluate possible solutions in 6man. If v6ops sees that the change in RFC4861 is warranted, then the operational advice from v6ops should make it happen in 6man. > Anyway, as I've said, I have no problem go to 6man with it - but I > guess we need to look at all proposed solutions, decide which way we > want to go and, if RFC4861 needs to be updated - well, I guess it > SHOULD be easy ;) Indeed! ;-) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 25 04:40:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D920120020; Thu, 25 Jul 2019 04:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_HELO_NONE=0.001, 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=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 B_VRcp0ZQAxJ; Thu, 25 Jul 2019 04:39:57 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 E892A120019; Thu, 25 Jul 2019 04:39:56 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id r6so36161632qkc.0; Thu, 25 Jul 2019 04:39:56 -0700 (PDT) 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:content-transfer-encoding; bh=xLYNUamu/v+0Ig6v6jbd+XScNWjbvHYhKEz8crvKFlQ=; b=dKb12UH/mrua7osn4PfoGoSxXu7GGG82TbPdYUtzpClHne5QGuyKC+8MS9/lpOzHcf HGZpKK3kyClK/8KkNAKgOolarRoWdCBt1DCGz3UFz28HDQ2WkXlGZU545puq6XrHkLoS ZVxO7gG1csh2tXnCjRY/dA6x9HluQmMrnRwbPNCFcVBOrRT1kma4TSqMBSJWmRQydmEO hI5cCpnhMDWWse/FEp9xJ1KyzMCschDYLtQp7Km4DX4pLm9l+IDGFyXr/jksi1RvUoQf wpUVs92lyJyUdU21vCHZPqAXqkrHyx5IUJexp+VoOkEBWICqXJAMjYlpw6h+36eGOFj9 h5yw== 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=xLYNUamu/v+0Ig6v6jbd+XScNWjbvHYhKEz8crvKFlQ=; b=ZdkfS/mAuWP4otuz/3qs4EP6/jahd6mXVkbfijEu9kGKgn8Ukbag+YoHSQr3dizfRm dXASZVIlHcBL/3VymbBSmMLY4L/B6V1haY3M6LGSL9UXRabTRDazDxwX/16AewS/cdWw HniMDctKdcVg5v6r9NxGZ53ANmqzOQ077hRZcWJrxCIDsh+8zPEt/H4hKEzPBchD1bXt Nah2gilHBQlH3DGdGAy7ZwsFu9fTeV15Mms4i0hCriC0Yy4HuJRRFEeNZyCPzQns7JY9 CIhY71mWcFny74vvqQYg0GydqhvxKE7YTcEDgWx7mE4i91vJr9o8Pfyhj6hE5RowSekR ArCA== X-Gm-Message-State: APjAAAWBNXpjO/e5KAqjUtujhI80PymFY/Mqc3kllUJ3ccqhrMBUofHj 8lNh4Sic0fDOvUMHi6FAX176fzZY7HiUowwV7bw= X-Google-Smtp-Source: APXvYqz/UcRtD/gQmcDSMyNbJPN3sf5vFardOR2tPcghgokynKDlXzaTZ7KK+DWzQI1H8LZ/e2Advwz1c7QhSV1uXVw= X-Received: by 2002:a37:aa10:: with SMTP id t16mr58087625qke.332.1564054795806; Thu, 25 Jul 2019 04:39:55 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <8f1c6206-6057-5ab0-c16c-ad8ff67c9457@gont.com.ar> <20190723191925.GF258193@eidolon.nox.tf> <1b6ce7f8-07d1-bb1e-7533-637cfd4ae85b@gmail.com> <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> In-Reply-To: <3074B072-EA8C-427C-8ED1-55C5D5BE9448@cisco.com> From: Jen Linkova Date: Thu, 25 Jul 2019 21:39:43 +1000 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Brian E Carpenter , IPv6 Operations , 6man Chairs <6man-chairs@ietf.org>, Fernando Gont Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 11:39:59 -0000 On Wed, Jul 24, 2019 at 9:06 PM Pascal Thubert (pthubert) wrote: > Another thing that the draft should do imho is a more comprehensive revie= w of the problems that are associated with reactive. Coming from the router= side I=E2=80=99m probably more sensitive to that than others and I=E2=80= =99d de happy to contribute. Thanks for offering your help, Pascal! However I have some reservations about turning this particular document into 'reactive behaviour of ND problem statement'. First of all it does sound a bit biased towards a particular solution which makes me think that such analysis should belong to 6man@. I'm not saying such document shouldn't exist, I'm just not sure such analysis belongs to this draft. > > Le 23 juil. 2019 =C3=A0 21:53, Brian E Carpenter a =C3=A9crit : > > > > As has been extensively discussed on another thread, we sadly lack a me= thod > > of getting operational notes with *rough* consensus out quickly, becaus= e > > our process for BCP, or worse for standards track, can take years inste= ad > > of weeks. > > > > Y'all can prove me wrong by sending this draft to the IESG in a month > > or so, and then worry about updating RFC4861 at normal IETF speed. > > > > (After writing that, I am a bit embarassed that RFC6343 took six months= .) > > > > Regards > > Brian > > > >> On 24-Jul-19 07:19, David Lamparter wrote: > >>> On Tue, Jul 23, 2019 at 06:59:23PM +0100, Fernando Gont wrote: > >>>> On 23/7/19 12:39, Brian E Carpenter wrote: > >>>> 1) Yes, we should *obviously* do this. > >>>> 2) If the charter prevents that, fix the charter. > >>> > >>> I'm all for fixing problems and getting stuff done. And, if there's n= o > >>> other way than fixing the charter, so be it. > >>> > >>> However, it would seem to me that, the "bug" here is that we're > >>> defaulting to "6man wouldn't get this done, so let's do it elsewhere"= . > >> > >> The discussion I see here is that we've located an operational issue > >> with the IPv6 neighbor cache on routers, we have several candidates fo= r > >> fixing it, and each of these may or may not need a protocol change to = go > >> through 6man. > >> > >> Discussing whether any particular working group "gets things done" see= ms > >> tangential to the question at hand. > >> > >>> IMO, should be willing to maintain its protocols, improve them, and f= ix > >>> problems where necessary. > >>> > >>> If a BCP is to go against the protocol spec recommendation for the > >>> general case, that's an indication that the protocol should be update= d. > >> > >> Although I don't write the neighbour management code, I do write code > >> that operates routers and I have absolutely no concerns in understandi= ng > >> that a particular "SHOULD" statement has turned out to be a bad choice > >> for the specific situation of first-hop routers. > >> > >> Whether this is a specification change, to me, is decided by the inten= t. > >> The intent under consideration here is: > >> > >> When a valid Neighbor Advertisement is received (either solicited or > >> unsolicited), the Neighbor Cache is searched for the target's entry. > >> If no entry exists, the advertisement SHOULD be silently discarded. > >> There is no need to create an entry if none exists, since the > >> recipient has apparently not initiated any communication with the > >> target. > >> > >> The intent I see is that in most cases there's no point in having > >> devices consume memory, and the "SHOULD" is correct behaviour for host= s. > >> Routers *DO* "need to create an entry if none exists". I don't see a > >> conflict with 4861's intent, which I take as "don't open yourself to D= oS > >> attacks". The router /will have the neighbor cache entry anyway/, jus= t > >> with a delay, later, and the resulting annoyance. > >> > >> 4861 just failed to invoke the magic 8-ball correctly to make the > >> authors omniscient and recognize the specific circumstances under whic= h > >> this SHOULD is maybe not the best idea. This is implementation guidan= ce > >> based on operational experience. Just write it down and get it out > >> there. > >> > >> > >> -David > >> . > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Thu Jul 25 11:07:46 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD9C1201F8; Thu, 25 Jul 2019 11:07:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156407806411.12609.5928758361575020000.idtracker@ietfa.amsl.com> Date: Thu, 25 Jul 2019 11:07:44 -0700 Archived-At: Subject: [v6ops] The V6OPS WG has placed draft-linkova-v6ops-nd-cache-init in state "Candidate for WG Adoption" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 18:07:44 -0000 The V6OPS WG has placed draft-linkova-v6ops-nd-cache-init in state Candidate for WG Adoption (entered by Fred Baker) The document is available at https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/ From nobody Fri Jul 26 02:38:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C471A1202F9 for ; Fri, 26 Jul 2019 02:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMheXqFgb7c7 for ; Fri, 26 Jul 2019 02:38:05 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAC41202F8 for ; Fri, 26 Jul 2019 02:38:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D4CD3B1; Fri, 26 Jul 2019 11:38:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1564133880; bh=zhj49B5emI1IP/GbrSPOtS2OTa1EkIZex//twe31j+c=; h=Date:From:To:Subject:In-Reply-To:References:From; b=Et8+wQazh1OvkddbiPatL/pMdp2mR3XT72vIXJpiw4RVFws2ixOVPmtJAQE+CEw2t BuFOZ6dJO6AkqMWQW7UdujJICIHCnS8AjpEmL/uajbYdx7SInKQwSBTaIRjZJ2rKYQ dDPl+dTyStacejcsA4ybh3FJcxfhNs4yjNxmM8Gk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D2C60B0 for ; Fri, 26 Jul 2019 11:38:00 +0200 (CEST) Date: Fri, 26 Jul 2019 11:38:00 +0200 (CEST) From: Mikael Abrahamsson To: IPv6 Operations In-Reply-To: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> Message-ID: References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 09:38:08 -0000 On Tue, 23 Jul 2019, Fred Baker wrote: > In yesterday's meeting, the sense of the room and a discussion of charters at the mike suggested that draft-linkova-v6ops-nd-cache-init should become a working group draft. Doing so will require 6man to agree to let v6ops suggest specific changes to RFC 4861 under the rubric of "operational solutions", as discussed in the draft and https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00; the argument for not kicking those out to 6man is that the authors of RFC 4861 are no longer in a position to approve errata to it, which would be the other obvious approach (I'm not sure that's true of Erik Nordmark, but whatever). It would also need to be considered to update RFC 4861. > > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group draft? I support making this a working group draft, this is a problem we should solve. I'd just like to check, have the authors checked the proposed solution list against https://datatracker.ietf.org/wg/savi/documents/ to make sure the solutions we're proposing are not in conflict with behavior SAVI prescribes? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Jul 30 06:56:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046DB12018C for ; Tue, 30 Jul 2019 06:56:19 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 uznHpa7zNv9D for ; Tue, 30 Jul 2019 06:56:16 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB4C12019C for ; Tue, 30 Jul 2019 06:56:03 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6UDldZs007460 for ; Tue, 30 Jul 2019 09:56:03 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2u2p0p9ryj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 30 Jul 2019 09:56:02 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6UDu15e010292 for ; Tue, 30 Jul 2019 09:56:01 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6UDtvSS010178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 30 Jul 2019 09:55:57 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id A47524009E86 for ; Tue, 30 Jul 2019 13:55:57 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30486.vci.att.com (Service) with ESMTPS id 928214009E7C for ; Tue, 30 Jul 2019 13:55:57 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0439.000; Tue, 30 Jul 2019 09:55:57 -0400 From: "STARK, BARBARA H" To: "'IPv6 Operations'" Thread-Topic: CTA-2048 Host and Router Profiles for IPv6 Thread-Index: AdVG1BIlj865ccflT16SWEQZHCyFUw== Date: Tue, 30 Jul 2019 13:55:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E249CF6@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.219.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-30_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=583 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907300145 Archived-At: Subject: [v6ops] CTA-2048 Host and Router Profiles for IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 13:56:19 -0000 The people at CTA asked me to see if there might be anyone interested in pa= rticipating in CTA to create an updated revision to its CTA-2048 Host and R= outer Profiles for IPv6.=20 You can download a copy (after getting a login to the CTA site -- if you do= n't already have one) from https://www.cta.tech/Research-Standards/Standard= s.aspx?search=3DCTA-2048 The download and getting a login are free, and only moderately painful. There are only 5 pages of actual profile specification in this doc, and it = does primarily reference IETF RFCs (including RFC 7084). But the document i= s 5 years old, and it might be good to reference a few more or updated RFCs= ? All work is done by conference call and email list. If you aren't familia= r with CTA -- they are one of the main standards orgs in the US and have th= e ability to create ANSI standards. This particular document is an ANSI sta= ndard. They are also the organization that does the CES trade show every Ja= nuary in Las Vegas. Please unicast me if you're interested. Thx, Barbara