From nobody Wed Jan 2 19:30:00 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 66A5113104B; Wed, 2 Jan 2019 19:29:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154648618337.32563.8004719155986024146@ietfa.amsl.com> Date: Wed, 02 Jan 2019 19:29:43 -0800 Archived-At: Subject: [v6ops] Genart last call review of draft-ietf-v6ops-transition-ipv4aas-12 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, 03 Jan 2019 03:29:44 -0000 Reviewer: Matthew Miller Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-v6ops-transition-ipv4aas-12 Reviewer: Matthew A. Miller Review Date: 2019-01-02 IETF LC End Date: 2018-12-14 IESG Telechat date: 2019-01-10 Summary: This document is ready to be published as Informational, but has some nits that should be addressed before publication. Major issues: N/A Minor issue: There are some instances within the main content that RFC 2119 keywords are present as lower case. If these are intentional, then RFC 8174 needs to be applied. Nits/editorial comments: * In section 1. "Introduction" (and its subsections), the term "IPv6 Transition CE Router" is not preceded with a definite or indefinite article, although it is throughout the rest of this document. * In section 1. "Introduction", the phrase "prohibitive expense" ought to be "prohibitively expensive". * In section 7. "Code Considerations", the word "neither" might be better as "nor" in the phrase "in terms of RAM memory, neither other hardware requirements". * In section 7. "Code Considerations", there seems to be a misplaced coma; "cost of NAT44 code so, existing hardware supports them with minimal impact" reads better as "cost of NAT44 code, so existing hardware supports them with minimal impact". * In section 11. "Annex A: Usage Scenarios", the comma seems unneeded in the phrase "another CE behind it, takes care of that". * In section 12. "Annex B: End-User Network Architecture", the term "end-user" should be used consistently, it is sometimes "end user". From nobody Fri Jan 4 04:45: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 8462812870E for ; Fri, 4 Jan 2019 04:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-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 B_ovEeEnzVue for ; Fri, 4 Jan 2019 04:45:05 -0800 (PST) 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 862D112867A for ; Fri, 4 Jan 2019 04:45:05 -0800 (PST) Received: from [192.168.1.119] (host-79-121-44-22.kabelnet.hu [79.121.44.22]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x04CisA0037666 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 4 Jan 2019 13:45:00 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-44-22.kabelnet.hu [79.121.44.22] claimed to be [192.168.1.119] To: v6ops@ietf.org References: From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <25aef1de-291a-5a83-8f86-750c8ad75997@hit.bme.hu> Date: Fri, 4 Jan 2019 13:44:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.0 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=79.121.44.22; helo=[192.168.1.119]; 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: Re: [v6ops] draft-bp-v6ops-ipv6-ready-dns-dnssec 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, 04 Jan 2019 12:45:09 -0000 Happy New Year for Everyone! I have found a paper, which proposes a solution for the combination of DNS64 and DNSSEC. It is titled: "DNSSEC in the networks with a NAT64/DNS64" You can access full text at: https://www.researchgate.net/publication/328460624_DNSSEC_in_the_networks_with_a_NAT64DNS64 Best regards, Gábor 12/3/2018 5:56 PM keltezéssel, Ron Bonica írta: > Folks, > > Each week between now and IETF 104, we will review and discuss one draft with an eye towards progressing it. > > This week, please review and comment on draft-bp-v6ops-ipv6-ready-dns-dnssec. > > Fred and Ron > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Jan 6 22:27:38 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 55F71130DE5; Sun, 6 Jan 2019 22:27:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154684244329.17044.2866311660755291596@ietfa.amsl.com> Date: Sun, 06 Jan 2019 22:27:23 -0800 Archived-At: Subject: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 07 Jan 2019 06:27:24 -0000 Reviewer: Christian Huitema Review result: Ready I already reviewed the version 11 of this draft. From a security point of view, the main change between the two versions is the addition of a paragraph acknowledging the potential risks of relying on DHCP for configuration. To quote: "As described in [RFC8026] and [RFC8026] Security Consideration sections, there are generic DHCP security issues, which in the case of this document means that malicious nodes may alter the priority of the transition mechanisms." Well, on the one hand, this does directly address the point I raised in the previous review. On the other hand, it is a bit sad to have a dry acknowledgement like that, without any hint at mitigations. If I was writing an April's fool RFC, I would qualify that as one of those security sections that seem written primarily for appeasing the security reviewer. But then, do we want to give some advice to implementers? For example, do we want to tell them that it is OK to deploy compliant devices in a basic home network? Probably. In the branch office of a financial institution? Most probably not. Do we have a way to convey that in simple terms? I would add something like: "As stated in the introduction, this document addresses deployment of IPv4 as a service in a residential or small-office network. Deployment in more challenging environments would require additional security analysis." From nobody Mon Jan 7 02:16: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 412AE130DE7; Mon, 7 Jan 2019 02:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 ZXQsd49MkI5g; Mon, 7 Jan 2019 02:16:37 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FE8130DE3; Mon, 7 Jan 2019 02:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546856194; x=1547460994; 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=bfAIMBKwhh4VLBVSyNDelIAJmfwQeZEScWgL0/CJg7A=; b=XK4/K+BTPwe2e NzCqOTB2qWptbMZ86iEu9DgWsk6gxArUhDsUG0GPkvHa2i9HyzhvyfAYq/ta4tQe vt2nKsDrMGU4ClqTpyiD5L8JDUXzRxSlZVcRoBPuSPzLAuUqtbBxwOhLe2+vvmCF 5boCSgAC/cOQTAz2Eq5YJsr1ephjAw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:16:34 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:16:34 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006100193.msg; Mon, 07 Jan 2019 11:16:33 +0100 X-MDRemoteIP: 2001:470:1f09:495:b467:f4bf:e908:d5fd X-MDHelo: [10.10.10.140] X-MDArrival-Date: Mon, 07 Jan 2019 11:16:33 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19105d24b1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 07 Jan 2019 11:16:32 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , CC: , Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> In-Reply-To: <154684244329.17044.2866311660755291596@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 07 Jan 2019 10:16:40 -0000 Hi Christian, Thanks for your review. There is a typo there, wrong copy and paste. It should be RFC8415 and RFC80= 26, as we discussed after your review. My point, as discussed in the previous email exchange, is that this is a ge= neric issue of DHCP. DHCP is used by both residential and non-residential s= ervice provisioning, and I don't see how we can solve that problem unless w= e implement some new DHCP "extension" that apply end-to-end encryption betw= een, in this case, the CEs and the servers. I can have a security section with basically replicates the text available = in RFC8415 Security Section, including considerations of using IEEE-802.1X,= DHCP snooping/guard/access control mechanisms, use of TR-069 access contro= l mechanisms, etc. I'm also happy to add your suggested paragraph regarding additional securit= y analysis in more challenging environments. Or maybe the correction of the RFC8415 references is sufficient in your opi= nion or you will prefer some additional text to summarize the RFC8415 secur= ity considerations/mitigations? I'm going to wait a couple of days, in case there are further inputs, befor= e uploading a new version correcting the mistake and also take in considera= tions the suggestions from the Gen-ART review a couple of days ago. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Christian Huitema Fecha: lunes, 7 de enero de 2019, 7:28 Para: CC: , , Asunto: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4a= as-12 Reviewer: Christian Huitema Review result: Ready =20 I already reviewed the version 11 of this draft. From a security point = of view, the main change between the two versions is the addition of a paragraph acknowledging the potential risks of relying on DHCP for configuration.= To quote: "As described in [RFC8026] and [RFC8026] Security Consideration sections, there are generic DHCP security issues, which in the case of = this document means that malicious nodes may alter the priority of the trans= ition mechanisms." =20 Well, on the one hand, this does directly address the point I raised in= the previous review. On the other hand, it is a bit sad to have a dry acknowledgement like that, without any hint at mitigations. If I was wr= iting an April's fool RFC, I would qualify that as one of those security section= s that seem written primarily for appeasing the security reviewer. But then, d= o we want to give some advice to implementers? For example, do we want to te= ll them that it is OK to deploy compliant devices in a basic home network? Prob= ably. In the branch office of a financial institution? Most probably not. Do we = have a way to convey that in simple terms? I would add something like: =20 "As stated in the introduction, this document addresses deployment of I= Pv4 as a service in a residential or small-office network. Deployment in more challenging environments would require additional security analysis." =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 Mon Jan 7 02:38:50 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 7C41F12D4F1; Mon, 7 Jan 2019 02:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 fmaDl5Uh37VH; Mon, 7 Jan 2019 02:38:40 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BA8129AA0; Mon, 7 Jan 2019 02:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546857515; x=1547462315; 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=qdf+atTfShMJ7kXOJy+MpCTDAZ2kI1uh++fEGfcc9mw=; b=GG0Y2SAufIeSD cPYFGchc5iZu4gtuCMQnnddy1zJqFEVn+840yp2k5uFxqvBF/z+pCIL4+HsGNiJN 7WZKDCu80fdMItBO1jcntXGIfQUiTMah9s4GEVFRGjgoLIe5c4Ns8WisUq0pc3Ot 5ns/xsJGMWNu5YZ1w2ZmWdnaw1xBMk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:38:35 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:38:35 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006100209.msg; Mon, 07 Jan 2019 11:38:33 +0100 X-MDRemoteIP: 2001:470:1f09:495:b467:f4bf:e908:d5fd X-MDHelo: [10.10.10.140] X-MDArrival-Date: Mon, 07 Jan 2019 11:38:33 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19105d24b1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 07 Jan 2019 11:38:33 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , CC: , Message-ID: <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.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] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 07 Jan 2019 10:38:43 -0000 Hi Christian, I've drafted this at the moment. Let me know if you think now this is bette= r and if you think anything else is needed. 8. Security Considerations The IPv6 Transition CE Router must comply with the Security Considerations as stated in [RFC7084], as well as those stated by each transition mechanism implemented by the IPv6 Transition CE Router. As described in [RFC8026] and [RFC8415] Security Consideration sections, there are generic DHCP security issues, which in the case of this document means that malicious nodes may alter the priority of the transition mechanisms. Considering that, networks using DHCPv6, depending on their specific topologies, should consider using authentication mechanisms such as those based on IEEE-802.1X or access control mechanisms such as DHCP snooping, DHCP guard, or TR-069, among other possible choices. As stated in the introduction, this document addresses deployment of IPv4aaS in residential, SOHO and SME networks. Deployment in more challenging environments would require additional security analysis. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de JORDI PALET MARTINEZ Fecha: lunes, 7 de enero de 2019, 11:17 Para: Christian Huitema , CC: , Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 Hi Christian, =20 Thanks for your review. =20 There is a typo there, wrong copy and paste. It should be RFC8415 and R= FC8026, as we discussed after your review. =20 My point, as discussed in the previous email exchange, is that this is = a generic issue of DHCP. DHCP is used by both residential and non-residenti= al service provisioning, and I don't see how we can solve that problem unle= ss we implement some new DHCP "extension" that apply end-to-end encryption = between, in this case, the CEs and the servers. =20 I can have a security section with basically replicates the text availa= ble in RFC8415 Security Section, including considerations of using IEEE-802= .1X, DHCP snooping/guard/access control mechanisms, use of TR-069 access co= ntrol mechanisms, etc. =20 I'm also happy to add your suggested paragraph regarding additional sec= urity analysis in more challenging environments. =20 Or maybe the correction of the RFC8415 references is sufficient in your= opinion or you will prefer some additional text to summarize the RFC8415 s= ecurity considerations/mitigations? =20 I'm going to wait a couple of days, in case there are further inputs, b= efore uploading a new version correcting the mistake and also take in consi= derations the suggestions from the Gen-ART review a couple of days ago. =20 Regards, Jordi =20 =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Christian Huitema Fecha: lunes, 7 de enero de 2019, 7:28 Para: CC: , , Asunto: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 =20 Reviewer: Christian Huitema Review result: Ready =20 I already reviewed the version 11 of this draft. From a security po= int of view, the main change between the two versions is the addition of a parag= raph acknowledging the potential risks of relying on DHCP for configurat= ion. To quote: "As described in [RFC8026] and [RFC8026] Security Considerat= ion sections, there are generic DHCP security issues, which in the case= of this document means that malicious nodes may alter the priority of the t= ransition mechanisms." =20 Well, on the one hand, this does directly address the point I raise= d in the previous review. On the other hand, it is a bit sad to have a dry acknowledgement like that, without any hint at mitigations. If I wa= s writing an April's fool RFC, I would qualify that as one of those security sec= tions that seem written primarily for appeasing the security reviewer. But the= n, do we want to give some advice to implementers? For example, do we want t= o tell them that it is OK to deploy compliant devices in a basic home network? = Probably. In the branch office of a financial institution? Most probably not. Do= we have a way to convey that in simple terms? I would add something like: =20 "As stated in the introduction, this document addresses deployment = of IPv4 as a service in a residential or small-office network. Deployment in mor= e challenging environments would require additional security analysis= ." =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 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 =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 Jan 7 03:15: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 2818C130DE7; Mon, 7 Jan 2019 03:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 P12bLPirYiMZ; Mon, 7 Jan 2019 03:15:19 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D127130E9F; Mon, 7 Jan 2019 03:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546859715; x=1547464515; 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=nmQT0TYSomHU1rDLvP3zWBwoNnzyeqI6CyH9hnRL1WA=; b=L4GzLN+ctHFLh BUphFgTOjdEPkag1fGcjTm2SZG2K0Gcwtj6BcjqcwlnGyiXXC+JkQJGvtxaYvGdl 0mvIUErvhs02HHrdsQiJf//m2PjrUPYYJzg6eKPnJd8m8wNe+SfTAss3Ovbuc4ml KcXL8sBxroEYC5pD12UUjSlbdBb2/M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 07 Jan 2019 12:15:15 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 07 Jan 2019 12:15:14 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006100233.msg; Mon, 07 Jan 2019 12:15:14 +0100 X-MDRemoteIP: 2001:470:1f09:495:b467:f4bf:e908:d5fd X-MDHelo: [10.10.10.140] X-MDArrival-Date: Mon, 07 Jan 2019 12:15:14 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19105d24b1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 07 Jan 2019 12:15:13 +0100 From: JORDI PALET MARTINEZ To: Matthew Miller , CC: , , Message-ID: <57D1461D-20F8-414E-8B67-9B540CD21688@consulintel.es> Thread-Topic: [v6ops] Genart last call review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154648618337.32563.8004719155986024146@ietfa.amsl.com> In-Reply-To: <154648618337.32563.8004719155986024146@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Genart last call review of draft-ietf-v6ops-transition-ipv4aas-12 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, 07 Jan 2019 11:15:21 -0000 Hi Matthew, Thanks for your review! We are using a special language, not RFC2119 (used in RFC7084). Anyway, I w= ill make a note to reflect your input. I will also correct the other nits you mention. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Matthew Miller Fecha: jueves, 3 de enero de 2019, 4:31 Para: CC: , , Asunto: [v6ops] Genart last call review of draft-ietf-v6ops-transition-ipv4= aas-12 Reviewer: Matthew Miller Review result: Ready with Nits =20 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. =20 For more information, please see the FAQ at =20 . =20 Document: draft-ietf-v6ops-transition-ipv4aas-12 Reviewer: Matthew A. Miller Review Date: 2019-01-02 IETF LC End Date: 2018-12-14 IESG Telechat date: 2019-01-10 =20 Summary: This document is ready to be published as Informational, but has some nits that should be addressed before publication. =20 Major issues: N/A =20 Minor issue: =20 There are some instances within the main content that RFC 2119 keywords are present as lower case. If these are intentional, then RFC 8174 needs to be applied. =20 Nits/editorial comments:=20 =20 * In section 1. "Introduction" (and its subsections), the term "IPv6 Transition CE Router" is not preceded with a definite or indefinite article, although it is throughout the rest of this document. * In section 1. "Introduction", the phrase "prohibitive expense" ought to be "prohibitively expensive". * In section 7. "Code Considerations", the word "neither" might be better as "nor" in the phrase "in terms of RAM memory, neither other hardware requirements". * In section 7. "Code Considerations", there seems to be a misplaced coma; "cost of NAT44 code so, existing hardware supports them with minimal impact" reads better as "cost of NAT44 code, so existing hardware supports them with minimal impact". * In section 11. "Annex A: Usage Scenarios", the comma seems unneeded in the phrase "another CE behind it, takes care of that". * In section 12. "Annex B: End-User Network Architecture", the term "end-user" should be used consistently, it is sometimes "end user". =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 Mon Jan 7 05:52:03 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 2FE9C130E9E for ; Mon, 7 Jan 2019 05:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpREADeXvpja for ; Mon, 7 Jan 2019 05:51:59 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.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 D60D9130E9F for ; Mon, 7 Jan 2019 05:51:58 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x07DpwDl031467 for ; Mon, 7 Jan 2019 05:51:58 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=RScJs8AYo4gpFcXrTMcQwA6fMY9mmjiG2o1IggKalzw=; b=mbaKc09YawILpCDbbJBjjEWQHSmagHP9Yv6BFEsBJ2QPtEfiW9WHoSaezAZbORHrVJ9M AS30rDSGAGxdmsIpmrTp7UasHuFrHqtt/GBSbpGzj84o9CMz8LvlghdrQ0w8gVlMlJMF b3lut66YMNFVjTCam/QTdEeXBw+FIqFO9Rrknzu9HOu+L5oq6FGTsGiShP5HpFk0AHtM CGrQTJT6vYEmV0o9b3u5GkKzylttwg7TNCzVdpTLnmMb9l9B234bwydbCHiLCuWEUMTl IoyC3iOvktN62Frllo+BO9GGAa5MAtmW3CNBIYBnTZFp2ClEJA63fzus5D2bB4VooXGQ vQ== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2052.outbound.protection.outlook.com [104.47.37.52]) by mx0a-00273201.pphosted.com with ESMTP id 2pv4png99s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 07 Jan 2019 05:51:58 -0800 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4583.namprd05.prod.outlook.com (52.135.204.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.10; Mon, 7 Jan 2019 13:51:56 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::7598:d648:d84f:9304]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::7598:d648:d84f:9304%3]) with mapi id 15.20.1516.010; Mon, 7 Jan 2019 13:51:55 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-palet-v6ops-rfc6177-bis Thread-Index: AdSmkBedgp2q3YF5TTabCDi5pHxCPw== Date: Mon, 7 Jan 2019 13:51:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.0.61 dlp-reaction: no-action x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4583; 6:9e/LSp1nMoHDHXnLpjoiOc3ZzHlsI7jG7Ppw/v6wxJjorwpozmo6ZMiNzuMiZJhcPjEK1cUygYpMTqVd6ejeVXSTGrPnLFTcFJpGWGljUytBuMxdYXQJSyJZIbAgbGfi8KcdI5GjEa/VaAi78d2Uh6CWJb4SNlwMaK+xulp34dg/f8UKADocfwzN4ArhpmjdXjq8BPmTUfclJQCgONUOZt9h/+JCKS9l12EYszl3Mkw8XYUrsC980+XXpG1VO9fWOnQSc77cVi/cGMYvXZW0qam4z3/fS4xnm9IHGqyTF27+XFdC7QaNQxReDfLElCc91gd+U0vmvenf9/Rl6/cPGYcG5lsLu0vAdsURdLkaviAdfAby9kdfwOkcE39haKuPbFka1PbD9H2yTP97048bx/ExZL85cKh09X7e7VWVchZs+BP2T6slXlgKPyxUY0rKb5+eQulOiE5l3Gv3QSFWHQ==; 5:z6Puw3ez2n+Cv+jeYdRxE9iO9KIiIao8OxZnz/3FP5gXJO3HYAktQxBGVJdSg85ugEWVQTxhv1ss4Q83+TtN1LX1xRUkOrbTPlYZmiimvZbeW4YFUfiNP0qJ68vlAdiTk3ei9x3/JXAjsaA0xEqQvOti6FRN+PQE+xfYYXQxo2aXNJupRSi5Na++7BBxjEwV7Cuv+M1IZjsnY0/4GWPTCQ==; 7:BRTskZxBDVYXyqtqVuSwdH21G6KdY/Zazysb/dQnqffdmZBpexSb2eA3OxqzeD5MW+pA2kvlIjPV401mGtv7ZbAhqbhbobm//6hjPcjOIyqJFFIbeR2Mn+gK5GnoNYryV4yI2Kz+5xKDJmfCITrJYQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a88d85f5-0134-4b1b-e90f-08d674a74940 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4583; x-ms-traffictypediagnostic: BYAPR05MB4583: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3002001)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB4583; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4583; x-forefront-prvs: 0910AAF391 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(346002)(136003)(366004)(189003)(199004)(2351001)(33656002)(316002)(105586002)(106356001)(256004)(5660300001)(14454004)(99286004)(74316002)(478600001)(8676002)(81156014)(81166006)(2906002)(6116002)(476003)(3846002)(6346003)(9686003)(8936002)(53936002)(2501003)(86362001)(26005)(102836004)(97736004)(186003)(7736002)(305945005)(25786009)(7696005)(486006)(71190400001)(71200400001)(5640700003)(6436002)(558084003)(55016002)(6506007)(68736007)(6916009)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4583; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hOyFJWQmRI3eTcbWeBFEGzC4OWoLDdM4G7CC3C72DBW1zMVCo4MhB1Ia/xF00JCFO95l3zFcsdHBvYCzRgsnh8kL+JBKpai8o9sbEQ9R99MT45e5OQ1XAraPY9Zp5mJtyfT3Qaqe9Ew8ctY/+0HGjqhOBFHY5ESfYnBEECd8v9m+kFxbImHzvaB0RWg8X57BbRxLde+pC/9kefEi4P2RiVqSQ5z66CU71JiGG6bPqDI161w2rdo+l8DhXEV0xzfBu2zmXpY22TzleCU/0p7BPm93wKPb96IG2mzyQ0BUP8i1zie7OjBpqdQAZUndhANB spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: a88d85f5-0134-4b1b-e90f-08d674a74940 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2019 13:51:55.0120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4583 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=443 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070123 Archived-At: Subject: [v6ops] draft-palet-v6ops-rfc6177-bis 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, 07 Jan 2019 13:52:02 -0000 Folks, Each week between now and IETF 104, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-palet-v6ops-rfc6177-bis. Fred and Ron From nobody Mon Jan 7 10:24: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 153261277BB for ; Mon, 7 Jan 2019 10:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 uCca6n42XXhQ for ; Mon, 7 Jan 2019 10:24:49 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 835A11200B3 for ; Mon, 7 Jan 2019 10:24:49 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ggZEn-0008My-Il for v6ops@ietf.org; Mon, 07 Jan 2019 19:03:00 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ggZEf-0000xz-TM for v6ops@ietf.org; Mon, 07 Jan 2019 13:02:53 -0500 Received: (qmail 6632 invoked from network); 7 Jan 2019 18:02:21 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Jan 2019 18:02:21 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16C101) In-Reply-To: <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> Date: Mon, 7 Jan 2019 10:02:19 -0800 Cc: secdir@ietf.org, v6ops@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> To: JORDI PALET MARTINEZ X-Originating-IP: 168.144.250.223 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.23) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jHkVeuB2ZXQ1iguQK3r7Pt602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9Ax5EMAwt65rnMLdMNVwY4CzFDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j56H4LNdLx5R4LmAS6U2pDgU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMRUrRLEbmN2hOWkm+jjl7mqPwUimsNGvJJilSn4u6QSZJ/h8BvPqWPS k8MXd7TU5YEs95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53tGWQiV0zRVsA5SL7kYV1JnAMgFPp7+h3kLe NmBV53UGScz865MHYfWaafyFL8fikxMFhRwAluttoKty5s2ODCBRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/IAhemhJdBSJkER04dYNqSf7G3ch6MdB0XuALpEgtIRSdxZ/cxSnpMWdGZZ8 NIOHnN40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 07 Jan 2019 18:24:52 -0000 Yes, that would work fine. If it could help convince these routers to implem= ent DHCP guard or RA guard, that would be a great result. I am not so sure about 802.1x. The routers could of course support a setting= like that of the IETF network, and that would have some advantage over WPA r= esidential, but it would not address an important threat: local device compr= omised by some virus and engaging in DHCP spoofing. DHCP guard or RA guard w= ould still be needed. -- Christian Huitema=20 > On Jan 7, 2019, at 2:38 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Christian, >=20 > I've drafted this at the moment. Let me know if you think now this is bett= er and if you think anything else is needed. >=20 > 8. Security Considerations >=20 > The IPv6 Transition CE Router must comply with the Security > Considerations as stated in [RFC7084], as well as those stated by > each transition mechanism implemented by the IPv6 Transition CE > Router. >=20 > As described in [RFC8026] and [RFC8415] Security Consideration > sections, there are generic DHCP security issues, which in the case > of this document means that malicious nodes may alter the priority of > the transition mechanisms. >=20 > Considering that, networks using DHCPv6, depending on their specific > topologies, should consider using authentication mechanisms such as > those based on IEEE-802.1X or access control mechanisms such as DHCP > snooping, DHCP guard, or TR-069, among other possible choices. >=20 > As stated in the introduction, this document addresses deployment of > IPv4aaS in residential, SOHO and SME networks. Deployment in more > challenging environments would require additional security analysis. >=20 >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: ietf en nombre de JORDI PALET MARTINEZ > Fecha: lunes, 7 de enero de 2019, 11:17 > Para: Christian Huitema , > CC: , > Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-= ipv4aas-12 >=20 > Hi Christian, >=20 > Thanks for your review. >=20 > There is a typo there, wrong copy and paste. It should be RFC8415 and R= FC8026, as we discussed after your review. >=20 > My point, as discussed in the previous email exchange, is that this is a= generic issue of DHCP. DHCP is used by both residential and non-residential= service provisioning, and I don't see how we can solve that problem unless w= e implement some new DHCP "extension" that apply end-to-end encryption betwe= en, in this case, the CEs and the servers. >=20 > I can have a security section with basically replicates the text availa= ble in RFC8415 Security Section, including considerations of using IEEE-802.= 1X, DHCP snooping/guard/access control mechanisms, use of TR-069 access cont= rol mechanisms, etc. >=20 > I'm also happy to add your suggested paragraph regarding additional sec= urity analysis in more challenging environments. >=20 > Or maybe the correction of the RFC8415 references is sufficient in your= opinion or you will prefer some additional text to summarize the RFC8415 se= curity considerations/mitigations? >=20 > I'm going to wait a couple of days, in case there are further inputs, b= efore uploading a new version correcting the mistake and also take in consid= erations the suggestions from the Gen-ART review a couple of days ago. >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Christian Huitema > Fecha: lunes, 7 de enero de 2019, 7:28 > Para: > CC: , , > Asunto: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 >=20 > Reviewer: Christian Huitema > Review result: Ready >=20 > I already reviewed the version 11 of this draft. =46rom a security p= oint of view, > the main change between the two versions is the addition of a parag= raph > acknowledging the potential risks of relying on DHCP for configurat= ion. To > quote: "As described in [RFC8026] and [RFC8026] Security Considerat= ion > sections, there are generic DHCP security issues, which in the case= of this > document means that malicious nodes may alter the priority of the t= ransition > mechanisms." >=20 > Well, on the one hand, this does directly address the point I raise= d in the > previous review. On the other hand, it is a bit sad to have a dry > acknowledgement like that, without any hint at mitigations. If I wa= s writing an > April's fool RFC, I would qualify that as one of those security sec= tions that > seem written primarily for appeasing the security reviewer. But the= n, do we > want to give some advice to implementers? For example, do we want t= o tell them > that it is OK to deploy compliant devices in a basic home network? P= robably. In > the branch office of a financial institution? Most probably not. Do= we have a > way to convey that in simple terms? I would add something like: >=20 > "As stated in the introduction, this document addresses deployment o= f IPv4 as a > service in a residential or small-office network. Deployment in mor= e > challenging environments would require additional security analysis= ." >=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 privileged or= confidential. The information is intended to be for the exclusive use of th= e individual(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 consi= dered 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 infor= mation, even if partially, including attached files, is strictly prohibited,= will be considered a criminal offense, so you must reply to the original se= nder to inform about this communication and delete it. >=20 >=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 co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 From nobody Mon Jan 7 11:17: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 7D13712D4EA; Mon, 7 Jan 2019 11:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiIskYABxodV; Mon, 7 Jan 2019 11:17:16 -0800 (PST) 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 B8EFE1310F4; Mon, 7 Jan 2019 11:17:15 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x07JFuuF029964; Mon, 7 Jan 2019 14:17:07 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2pvcm58asv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 14:17:06 -0500 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 x07JH52h001302; Mon, 7 Jan 2019 14:17:06 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07JH2hR001272; Mon, 7 Jan 2019 14:17:03 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 9DC88400579E; Mon, 7 Jan 2019 19:17:02 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30488.vci.att.com (Service) with ESMTPS id 8B9EA40002C2; Mon, 7 Jan 2019 19:17:02 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 14:17:02 -0500 From: "STARK, BARBARA H" To: "'Christian Huitema'" , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 Thread-Index: AQHUplIxzMK3YDjZl0aLw/nLjmGiN6Wj60wAgAAGJ4CAAHv9gP//vwTw Date: Mon, 7 Jan 2019 19:17:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.202.237] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_08:, , 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=602 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070161 Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 07 Jan 2019 19:17:24 -0000 PiBGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENocmlz dGlhbiBIdWl0ZW1hDQouLi4NCj4gSSBhbSBub3Qgc28gc3VyZSBhYm91dCA4MDIuMXguIFRoZSBy b3V0ZXJzIGNvdWxkIG9mIGNvdXJzZSBzdXBwb3J0IGEgc2V0dGluZw0KPiBsaWtlIHRoYXQgb2Yg dGhlIElFVEYgbmV0d29yaywgYW5kIHRoYXQgd291bGQgaGF2ZSBzb21lIGFkdmFudGFnZSBvdmVy DQo+IFdQQSByZXNpZGVudGlhbCwgYnV0IGl0IHdvdWxkIG5vdCBhZGRyZXNzIGFuIGltcG9ydGFu dCB0aHJlYXQ6IGxvY2FsIGRldmljZQ0KPiBjb21wcm9taXNlZCBieSBzb21lIHZpcnVzIGFuZCBl bmdhZ2luZyBpbiBESENQIHNwb29maW5nLiBESENQIGd1YXJkIG9yDQo+IFJBIGd1YXJkIHdvdWxk IHN0aWxsIGJlIG5lZWRlZC4NCg0KODAyLjFYIGlzIHZlcnkgd2lkZWx5IHVzZWQgaW4gR1BPTiBh bmQgRFNMIG5ldHdvcmtzIGFuZCBJIGhhdmVuJ3QgaGVhcmQgb2YgaXQgaGF2aW5nIGFueSBpc3N1 ZXMuIEknbSBub3QgdW5kZXJzdGFuZGluZyB0aGUgcmVmZXJlbmNlIHRvIFdQQSBhbmQgbG9jYWwg ZGV2aWNlcywgc2luY2UgSSB0aGluayB3ZSdyZSB0YWxraW5nIGFib3V0IHRoZSBXQU4gYW5kIG5v dCB0aGUgTEFOIGludGVyZmFjZSBoZXJlPyANCg0KLi4uLi4uLi4uLg0KPiA+IE9uIEphbiA3LCAy MDE5LCBhdCAyOjM4IEFNLCBKT1JESSBQQUxFVCBNQVJUSU5FWg0KLi4uDQo+ID4gICBDb25zaWRl cmluZyB0aGF0LCBuZXR3b3JrcyB1c2luZyBESENQdjYsIGRlcGVuZGluZyBvbiB0aGVpciBzcGVj aWZpYw0KPiA+ICAgdG9wb2xvZ2llcywgc2hvdWxkIGNvbnNpZGVyIHVzaW5nIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbXMgc3VjaCBhcw0KPiA+ICAgdGhvc2UgYmFzZWQgb24gSUVFRS04MDIuMVgg b3IgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtcyBzdWNoIGFzIERIQ1ANCj4gPiAgIHNub29waW5n LCBESENQIGd1YXJkLCBvciBUUi0wNjksIGFtb25nIG90aGVyIHBvc3NpYmxlIGNob2ljZXMuDQoN ClRSLTA2OSBpcyBhIG1hbmFnZW1lbnQgcHJvdG9jb2wgKHRoYXQgZ29lcyBvdmVyIEhUVFAsIHVz aW5nIFRMUyBmb3Igc2VjdXJpdHkpLCBhbmQgbm90IGFuIGFjY2VzcyBjb250cm9sIG1lY2hhbmlz bS4gSSBzdWdnZXN0IGl0IGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuDQoNCkJhcmJhcmENCg0K From nobody Mon Jan 7 11:58: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 7474D12008A; Mon, 7 Jan 2019 11:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 3FzzF1Dh1qEn; Mon, 7 Jan 2019 11:58:18 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6404124C04; Mon, 7 Jan 2019 11:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546891094; x=1547495894; 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=L4E9job2HdDnkFUeE2oXTo/ELS7SU5jTi299G1MwtjA=; b=QHpjO8l/AxPRi GvPmmO4ROhLZFBizW3gMrR9Zm19h4S5tDGUbacABlFhg0Ym1a+lbfs/fTzlWfX66 HcWNjStYWizFKtUV0gV/MH4GwhadnP+goY5SPytnKxmW1k8XmfelpbZr4Ag9GbpN XN70cB7AsVJLnf8x6V9eRy6XqPZppE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 07 Jan 2019 20:58:14 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 07 Jan 2019 20:58:14 +0100 Received: from [10.10.10.131] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006100772.msg; Mon, 07 Jan 2019 20:58:13 +0100 X-MDRemoteIP: 2001:470:1f09:495:707a:ed9e:3096:7905 X-MDHelo: [10.10.10.131] X-MDArrival-Date: Mon, 07 Jan 2019 20:58:13 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19105d24b1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 07 Jan 2019 20:58:10 +0100 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , 'Christian Huitema' CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 07 Jan 2019 19:58:22 -0000 Hi Barbara, I agree with your regarding the WPA, not sure to understand the point from = Christian. If a local device is compromised, that happens in the LANs and this will on= ly affect the CE, if the "virus" or "bot" or whatever is able to compromise= the CE configuration and then replace some of the settings done by the pro= visioning system. This is something that may happen regardless of using DHCP in the WAN or ot= her protocols. I recall having seen some TR-069 mechanism (maybe it was proprietary) to pr= ovide something related to access control security, but if it is not standa= rd, I will remove it. Let's see if someone in the list can provide some inf= o and I will also try to recall what was in the case I've in mind. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de "STARK, BARBARA H" Fecha: lunes, 7 de enero de 2019, 20:20 Para: 'Christian Huitema' , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "ietf@ietf.org" , "se= cdir@ietf.org" Asunto: RE: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 > From: v6ops On Behalf Of Christian Huitema ... > I am not so sure about 802.1x. The routers could of course support a = setting > like that of the IETF network, and that would have some advantage ove= r > WPA residential, but it would not address an important threat: local = device > compromised by some virus and engaging in DHCP spoofing. DHCP guard o= r > RA guard would still be needed. =20 802.1X is very widely used in GPON and DSL networks and I haven't heard= of it having any issues. I'm not understanding the reference to WPA and lo= cal devices, since I think we're talking about the WAN and not the LAN inte= rface here?=20 =20 .......... > > On Jan 7, 2019, at 2:38 AM, JORDI PALET MARTINEZ ... > > Considering that, networks using DHCPv6, depending on their speci= fic > > topologies, should consider using authentication mechanisms such = as > > those based on IEEE-802.1X or access control mechanisms such as D= HCP > > snooping, DHCP guard, or TR-069, among other possible choices. =20 TR-069 is a management protocol (that goes over HTTP, using TLS for sec= urity), and not an access control mechanism. I suggest it be removed from t= his list. =20 Barbara =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 Jan 7 20:14: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 189F312D4E7 for ; Mon, 7 Jan 2019 20:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 DHpTgCrA81rC for ; Mon, 7 Jan 2019 20:14:08 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 9E739130E4F for ; Mon, 7 Jan 2019 20:14:08 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ggimD-0006zY-2N for v6ops@ietf.org; Tue, 08 Jan 2019 05:14:06 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ggimA-0000Sq-K2 for v6ops@ietf.org; Mon, 07 Jan 2019 23:14:03 -0500 Received: (qmail 7258 invoked from network); 8 Jan 2019 04:14:00 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Jan 2019 04:14:00 -0000 To: JORDI PALET MARTINEZ , "STARK, BARBARA H" Cc: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Mon, 7 Jan 2019 20:13:58 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iiHH+MW+amS96XrHYgInOZ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9Axb+1+phYf6EcZEZqhKbxp1lDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5jmcs6wj/46gnUNWAdTw+hKXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseygOIcx4SICe6nNcjjd/M50Y6QGVSvC9ATxEYI3bPwB8a4nNnmOs4et Guw5Df31+MZqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+TvNcd3HWUjlOEFEnWeTdqCDg5/bq7ChmPMN Ycw1QSmRjiPkByQEyU730iQ8idWvLFgBWc4s3zXgmq5obVq0LPtm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhijAHO4UjZyr3s8K1Hs5JOni+NTKQHNkjJg8xvPcdYB8XgK1T2S4h8DThwS4W K6Op7v27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 08 Jan 2019 04:14:11 -0000 On 1/7/2019 11:58 AM, JORDI PALET MARTINEZ wrote: > Hi Barbara, > > I agree with your regarding the WPA, not sure to understand the point f= rom Christian. > > If a local device is compromised, that happens in the LANs and this wil= l only affect the CE, if the "virus" or "bot" or whatever is able to comp= romise the CE configuration and then replace some of the settings done by= the provisioning system. > > This is something that may happen regardless of using DHCP in the WAN o= r other protocols. > > I recall having seen some TR-069 mechanism (maybe it was proprietary) t= o provide something related to access control security, but if it is not = standard, I will remove it. Let's see if someone in the list can provide = some info and I will also try to recall what was in the case I've in mind= =2E Maybe I was not clear. I am not overly concerned with what happens on the WAN side -- I assume that the ISP deploying customer premise devices will find a way to provision them securely. I am concerned that using DHCPv6 to provision networking parameters on the local hosts exposes these hosts to generic DHCP spoofing attacks. To mount the DHCP spoofing attacks, the attacker will need to either gain connectivity to the local network, or gain controlled of a local device. Access control protocols like 802.1x will prevent unauthorized devices from connecting to the local network; they will not close the second avenue of attack, something that solutions like DHCP guard would do. The local router can filter which packets are relayed between Wi-Fi devices, and can filter out spoofed DHCP packets. That's reasonably easy to deploy in small networks, where the only authorized DHCP server is located on the router itself. Of course, the current document is not meant as a general home router requirement draft -- it just specifies the narrow problem of how these routers should facilitate deployment of IPv4 as a service. I do like Jordi's succession to refer to DHCP Guard as a potential mitigation of DHCPv6 issues, because it can be deployed simply and it would thwart a series of potential attacks. I am less enthusiastic about 802.1x, because as I said above it addresses a fraction of the problem, but not the whole problem. Standard deployment of 802.1x requires an authentication server, which currently does not come with small routers. It also requires management of this authentication server, which is a tall order in these small networks. There have been attempts to define a simpler profile of 802.1x, in which all users have the same ID and the same password -- such as what is used in the IETF Wi-Fi networks. This does improve somewhat over the residential version of WPA, in which all users share the same "Wi-Fi password", because it provides better isolation between users. But I would have a hard time recommending 802.1x deployment in residential networks "because of DHCPv6 security". While I do like the "DHCP Guard" class of solutions, I am also concerned that the DHCP Guard concept is only defined by the commercial literature of some vendors -- and the same goes for DHCP Snooping, which could have a variety of meanings. If you want to use that term, then you should add a reference to the paper where this is defined. Or you could use neutral language, like: Considering that, networks using DHCPv6, depending on their specific topologies, should consider using access control mechanisms such as those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designed to= prevent forwarding of spoofed DHCPv6 packets through the router, often referred to as "DHCP Guard." I am also skeptical of the mention of "SME" in the last paragraph, in "deployment of IPv4aaS in residential, SOHO and SME networks". The definition of what is a small or medium enterprise varies by countries. In the European Union, it is up to 250 employees. In the US, it is defined by revenues and employees limit, typically fewer than 500 employees. In other part of the world, it can be fewer than 50 employees, or maybe it is just defined by a limit on revenues. In any case, I would personally be reluctant to deploy simple devices like described in the draft in a network with 100 to 200 people, let alone 500. That would be pushing luck a bit too far. The introduction of the draft says "This document defines IPv4 service continuity features over an IPv6-only network, for a residential or small-office router..." I would suggest using exactly the same language, as in: As stated in the introduction, this document addresses deployment of IPv4aaS in residential or small-office networks. Deployment in more challenging environments would require additional security analysis. -- Christian Huitema From nobody Tue Jan 8 00:44: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 14BF51310F3; Tue, 8 Jan 2019 00:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWIcThuNzdrT; Tue, 8 Jan 2019 00:44:18 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4C3131102; Tue, 8 Jan 2019 00:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546937054; x=1547541854; 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=WpQTsSbxqLYLfXsxPD/b57tv5OkQwTE1wEfxivSAIkI=; b=jzgTh/cxbVE37 9OlpWTF9RzqivC8y2keW/jgiCaDU6Px9GtLTPT9rMmFckz6f+KKOCx9VTfpKd0fJ 22XwF3/5KwI7FzVCy1QjOODvP/ZLNJYJ4NTuJO6jRLhhQs/2gBt6AH90fy1zX+hd B+YhjfK9t6tprxSSNUFXOPNcQ12tJ4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 08 Jan 2019 09:44:14 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 08 Jan 2019 09:44:14 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006101437.msg; Tue, 08 Jan 2019 09:44:12 +0100 X-MDRemoteIP: 2001:470:1f09:495:78d5:b4a1:adaa:b67c X-MDHelo: [10.10.10.140] X-MDArrival-Date: Tue, 08 Jan 2019 09:44:12 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1911ba6fdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Tue, 08 Jan 2019 09:44:11 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , "STARK, BARBARA H" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.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] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 08 Jan 2019 08:44:21 -0000 Hi Christian, While I'm sympathetic with all what you said, this document is not adding/c= hanging anything regarding the LAN-side configuration related to DHCP, and = from that perspective, we refer to what is already required by RFC7084, whi= ch in turn calls to RFC6092. If I recall correctly, RFC6092 doesn't say anything about DHCP/RA security. I see SMEs with hundreds of employees, using this kind of routers connected= to 600 Mbps FTTH symmetric links (Spain, but I'm sure is the same case in = many other countries). However, in those cases, the router is only used a "= pure router", and there is a server(s) providing DHCP, NAT, firewall, etc.,= switches (which in many cases do DHCP-guard features as well as RA-Guard). The reason for it, is that those organizations don't have a "critical" need= to connect to internet (if it fails a few hours is not a problem, they don= 't host internal services to be accessed from Internet), or even it is much= cheaper to have 2 or 3 of those links (in Spain the cost is about 40 Euros= per month, including flat rate VoIP for national calls, any kind of failur= e needs to be fixed in a maximum of 24 hours, by law, while typically is le= ss than 8 hours) for backup/load balancing. If they choose a "corporate" link type, they will get a "business" router, = the link is the same (connecting to the same access/core infrastructure), j= ust they get a "promise" of a better SLA, but then they will need to pay 40= 0 Euros/month for the link. Anyway, I agree with the suggested changes, as it doesn't harm if we don't = explicitly say in the security section that the text is related to the LAN = or WAN side. Is up to the implementor in this case, to decide if they want = to offer a "better" CE firmware supporting those additional features. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de Christian Huitema Fecha: martes, 8 de enero de 2019, 6:04 Para: JORDI PALET MARTINEZ ,= "STARK, BARBARA H" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "se= cdir@ietf.org" Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 =20 On 1/7/2019 11:58 AM, JORDI PALET MARTINEZ wrote: > Hi Barbara, > > I agree with your regarding the WPA, not sure to understand the point= from Christian. > > If a local device is compromised, that happens in the LANs and this w= ill only affect the CE, if the "virus" or "bot" or whatever is able to comp= romise the CE configuration and then replace some of the settings done by t= he provisioning system. > > This is something that may happen regardless of using DHCP in the WAN= or other protocols. > > I recall having seen some TR-069 mechanism (maybe it was proprietary)= to provide something related to access control security, but if it is not = standard, I will remove it. Let's see if someone in the list can provide so= me info and I will also try to recall what was in the case I've in mind. =20 Maybe I was not clear. I am not overly concerned with what happens on the WAN side -- I assume that the ISP deploying customer premise device= s will find a way to provision them securely. I am concerned that using DHCPv6 to provision networking parameters on the local hosts exposes these hosts to generic DHCP spoofing attacks. To mount the DHCP spoofin= g attacks, the attacker will need to either gain connectivity to the loca= l network, or gain controlled of a local device. Access control protocols like 802.1x will prevent unauthorized devices from connecting to the local network; they will not close the second avenue of attack, something that solutions like DHCP guard would do. =20 The local router can filter which packets are relayed between Wi-Fi devices, and can filter out spoofed DHCP packets. That's reasonably eas= y to deploy in small networks, where the only authorized DHCP server is located on the router itself. Of course, the current document is not meant as a general home router requirement draft -- it just specifies the narrow problem of how these routers should facilitate deployment of IPv4 as a service. I do like Jordi's succession to refer to DHCP Guard as a potential mitigation of DHCPv6 issues, because it can be deployed simply and it would thwart a series of potential attacks. =20 I am less enthusiastic about 802.1x, because as I said above it addresses a fraction of the problem, but not the whole problem. Standar= d deployment of 802.1x requires an authentication server, which currently does not come with small routers. It also requires management of this authentication server, which is a tall order in these small networks. There have been attempts to define a simpler profile of 802.1x, in whic= h all users have the same ID and the same password -- such as what is use= d in the IETF Wi-Fi networks. This does improve somewhat over the residential version of WPA, in which all users share the same "Wi-Fi password", because it provides better isolation between users. But I would have a hard time recommending 802.1x deployment in residential networks "because of DHCPv6 security". =20 While I do like the "DHCP Guard" class of solutions, I am also concerne= d that the DHCP Guard concept is only defined by the commercial literatur= e of some vendors -- and the same goes for DHCP Snooping, which could hav= e a variety of meanings. If you want to use that term, then you should ad= d a reference to the paper where this is defined. Or you could use neutra= l language, like: =20 Considering that, networks using DHCPv6, depending on their specific topologies, should consider using access control mechanisms such as those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designed = to prevent forwarding of spoofed DHCPv6 packets through the router, ofte= n referred to as "DHCP Guard." =20 I am also skeptical of the mention of "SME" in the last paragraph, in "deployment of IPv4aaS in residential, SOHO and SME networks". The definition of what is a small or medium enterprise varies by countries. In the European Union, it is up to 250 employees. In the US, it is defined by revenues and employees limit, typically fewer than 500 employees. In other part of the world, it can be fewer than 50 employees, or maybe it is just defined by a limit on revenues. In any case, I would personally be reluctant to deploy simple devices like described in the draft in a network with 100 to 200 people, let alone 500. That would be pushing luck a bit too far. =20 The introduction of the draft says "This document defines IPv4 service continuity features over an IPv6-only network, for a residential or small-office router..." I would suggest using exactly the same language= , as in: =20 As stated in the introduction, this document addresses deployment of IPv4aaS in residential or small-office networks. Deployment in more challenging environments would require additional security analysis. =20 -- Christian Huitema =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 Tue Jan 8 09:15: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 6EE69130F0B; Tue, 8 Jan 2019 09:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 cIAmrMs33CuS; Tue, 8 Jan 2019 09:15:02 -0800 (PST) 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 540E7130F08; Tue, 8 Jan 2019 09:15:02 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x08H6vm1030116; Tue, 8 Jan 2019 12:14:56 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2pvxy9jeab-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jan 2019 12:14:56 -0500 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 x08HEswA025760; Tue, 8 Jan 2019 12:14:55 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x08HEoSR025670; Tue, 8 Jan 2019 12:14:50 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 176D040F6CE3; Tue, 8 Jan 2019 17:14:50 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30485.vci.att.com (Service) with ESMTPS id 0025340D4417; Tue, 8 Jan 2019 17:14:50 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 12:14:49 -0500 From: "STARK, BARBARA H" To: "'Christian Huitema'" , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 Thread-Index: AQHUplIxzMK3YDjZl0aLw/nLjmGiN6Wj60wAgAAGJ4CAAHv9gP//vwTwgABhWgCAAIqGAIAAVx6w Date: Tue, 8 Jan 2019 17:14:49 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.241] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-08_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=755 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901080139 Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 08 Jan 2019 17:15:04 -0000 PiBNYXliZSBJIHdhcyBub3QgY2xlYXIuIEkgYW0gbm90IG92ZXJseSBjb25jZXJuZWQgd2l0aCB3 aGF0IGhhcHBlbnMgb24gdGhlDQo+IFdBTiBzaWRlIC0tIEkgYXNzdW1lIHRoYXQgdGhlIElTUCBk ZXBsb3lpbmcgY3VzdG9tZXIgcHJlbWlzZSBkZXZpY2VzIHdpbGwNCj4gZmluZCBhIHdheSB0byBw cm92aXNpb24gdGhlbSBzZWN1cmVseS4gSSBhbSBjb25jZXJuZWQgdGhhdCB1c2luZw0KPiBESENQ djYgdG8gcHJvdmlzaW9uIG5ldHdvcmtpbmcgcGFyYW1ldGVycyBvbiB0aGUgbG9jYWwgaG9zdHMg ZXhwb3Nlcw0KPiB0aGVzZSBob3N0cyB0byBnZW5lcmljIERIQ1Agc3Bvb2ZpbmcgYXR0YWNrcy4g VG8gbW91bnQgdGhlIERIQ1Agc3Bvb2ZpbmcNCj4gYXR0YWNrcywgdGhlIGF0dGFja2VyIHdpbGwg bmVlZCB0byBlaXRoZXIgZ2FpbiBjb25uZWN0aXZpdHkgdG8gdGhlIGxvY2FsDQo+IG5ldHdvcmss IG9yIGdhaW4gY29udHJvbGxlZCBvZiBhIGxvY2FsIGRldmljZS4gQWNjZXNzIGNvbnRyb2wgcHJv dG9jb2xzIGxpa2UNCj4gODAyLjF4IHdpbGwgcHJldmVudCB1bmF1dGhvcml6ZWQgZGV2aWNlcyBm cm9tIGNvbm5lY3RpbmcgdG8gdGhlIGxvY2FsDQo+IG5ldHdvcms7IHRoZXkgd2lsbCBub3QgY2xv c2UgdGhlIHNlY29uZCBhdmVudWUgb2YgYXR0YWNrLCBzb21ldGhpbmcgdGhhdA0KPiBzb2x1dGlv bnMgbGlrZSBESENQIGd1YXJkIHdvdWxkIGRvLg0KDQpJIGFncmVlIGNvbXBsZXRlbHkgdGhhdCA4 MDIuMVggaXMgaXJyZWxldmFudCB0byB0aGUgdHlwZXMgb2YgTEFOcyB0aGUgQ0Ugcm91dGVycyBk ZXNjcmliZWQgYnkgdGhpcyBkcmFmdCBhcmUgdXNlZCBpbiwgYW5kIHNob3VsZG4ndCBiZSBtZW50 aW9uZWQgaW4gcmVmZXJlbmNlIHRvIHRoZSBMQU4gaW50ZXJmYWNlcyBvZiB0aGVzZSBDRSByb3V0 ZXJzLg0KSG93ZXZlciwgSU1PLCB0aGUgc2VjdXJpdHkgc2VjdGlvbiBzaG91bGQgYmUgZGlzY3Vz c2luZyBzZWN1cml0eSBjb25jZXJucyB0aGF0IGFyaXNlIHNwZWNpZmljYWxseSBhcyBhIHJlc3Vs dCBvZiB0aGUgcmVxdWlyZW1lbnRzIGluIHRoZSBkcmFmdC4gQ29uY2VybnMgdGhhdCBhcmUgaW5k ZXBlbmRlbnQgb2YgdGhlc2UgcmVxdWlyZW1lbnRzIGFyZSBvdXQgb2Ygc2NvcGUuIEFGQUlDVCwg bm9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIGluIHRoaXMgZHJhZnQgY3JlYXRlL2VuYWJsZSBuZXcg dGhyZWF0cyBvciBhdHRhY2sgdmVjdG9ycyByZWxhdGVkIHRvIExBTiBESENQIHNwb29maW5nIGF0 dGFja3M7IHRoZXJlZm9yZSBMQU4gREhDUCBzcG9vZmluZyBhdHRhY2tzIChkaXNjdXNzaW5nIHRo ZW0gYW5kIHByb3Bvc2luZyBob3cgdG8gYWRkcmVzcyB0aGVtKSBhcmUgb3V0IG9mIHNjb3BlLg0K IA0KPiBUaGUgbG9jYWwgcm91dGVyIGNhbiBmaWx0ZXIgd2hpY2ggcGFja2V0cyBhcmUgcmVsYXll ZCBiZXR3ZWVuIFdpLUZpIGRldmljZXMsDQo+IGFuZCBjYW4gZmlsdGVyIG91dCBzcG9vZmVkIERI Q1AgcGFja2V0cy4gVGhhdCdzIHJlYXNvbmFibHkgZWFzeSB0byBkZXBsb3kgaW4NCj4gc21hbGwg bmV0d29ya3MsIHdoZXJlIHRoZSBvbmx5IGF1dGhvcml6ZWQgREhDUCBzZXJ2ZXIgaXMgbG9jYXRl ZCBvbiB0aGUNCj4gcm91dGVyIGl0c2VsZi4gT2YgY291cnNlLCB0aGUgY3VycmVudCBkb2N1bWVu dCBpcyBub3QgbWVhbnQgYXMgYSBnZW5lcmFsDQo+IGhvbWUgcm91dGVyIHJlcXVpcmVtZW50IGRy YWZ0IC0tIGl0IGp1c3Qgc3BlY2lmaWVzIHRoZSBuYXJyb3cgcHJvYmxlbSBvZiBob3cNCj4gdGhl c2Ugcm91dGVycyBzaG91bGQgZmFjaWxpdGF0ZSBkZXBsb3ltZW50IG9mDQo+IElQdjQgYXMgYSBz ZXJ2aWNlLiBJIGRvIGxpa2UgSm9yZGkncyBzdWNjZXNzaW9uIHRvIHJlZmVyIHRvIERIQ1AgR3Vh cmQgYXMgYQ0KPiBwb3RlbnRpYWwgbWl0aWdhdGlvbiBvZiBESENQdjYgaXNzdWVzLCBiZWNhdXNl IGl0IGNhbiBiZSBkZXBsb3llZCBzaW1wbHkgYW5kDQo+IGl0IHdvdWxkIHRod2FydCBhIHNlcmll cyBvZiBwb3RlbnRpYWwgYXR0YWNrcy4NCg0KSW50cmEtTEFOIHJvdXRpbmcvYnJpZGdpbmcvc3dp dGNoaW5nL2ZpbHRlcmluZy9yZWxheWluZyBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkcmFmdC4g SW50cmEtTEFOIGJlaGF2aW9ycyBhcmUgbm90IHJlbGV2YW50IHRvIElQdjRhYVMuIFRoZXJlIGlz IG5vIG1lbnRpb24gb2YgTEFOLXNpZGUgREhDUHY2IChvciBESENQdjQpIGluIHRoZSBkcmFmdC4g QWxsIG1lbnRpb24gb2YgREhDUHY2IGlzIFdBTiBpbnRlcmZhY2UgREhDUHY2IGNsaWVudCBiZWhh dmlvci4gREhDUCh2NikgZ3VhcmQgaXNuJ3QgYSBjbGllbnQgYmVoYXZpb3IuIEkgZG9uJ3QgbGlr ZSBKb3JkaSdzIHN1Z2dlc3RlZCB0ZXh0LCBiZWNhdXNlICgxKSBhcyBhIFdBTiBiZWhhdmlvciAo d2hpY2ggaXMgaG93IG1vc3QgcGVvcGxlIHdpbGwgaW50ZXJwcmV0IGl0KSBESENQIGd1YXJkIG1h a2VzIG5vIHNlbnNlLCBhbmQgKDIpIGFzIGEgTEFOIGJlaGF2aW9yIGl0J3Mgb3V0IG9mIHNjb3Bl LiANCg0KPiBJIGFtIGxlc3MgZW50aHVzaWFzdGljIGFib3V0IDgwMi4xeCwgYmVjYXVzZSBhcyBJ IHNhaWQgYWJvdmUgaXQgYWRkcmVzc2VzIGENCj4gZnJhY3Rpb24gb2YgdGhlIHByb2JsZW0sIGJ1 dCBub3QgdGhlIHdob2xlIHByb2JsZW0uIFN0YW5kYXJkIGRlcGxveW1lbnQgb2YNCj4gODAyLjF4 IHJlcXVpcmVzIGFuIGF1dGhlbnRpY2F0aW9uIHNlcnZlciwgd2hpY2ggY3VycmVudGx5IGRvZXMg bm90IGNvbWUgd2l0aA0KPiBzbWFsbCByb3V0ZXJzLiBJdCBhbHNvIHJlcXVpcmVzIG1hbmFnZW1l bnQgb2YgdGhpcyBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIsDQo+IHdoaWNoIGlzIGEgdGFsbCBvcmRl ciBpbiB0aGVzZSBzbWFsbCBuZXR3b3Jrcy4NCj4gVGhlcmUgaGF2ZSBiZWVuIGF0dGVtcHRzIHRv IGRlZmluZSBhIHNpbXBsZXIgcHJvZmlsZSBvZiA4MDIuMXgsIGluIHdoaWNoIGFsbA0KPiB1c2Vy cyBoYXZlIHRoZSBzYW1lIElEIGFuZCB0aGUgc2FtZSBwYXNzd29yZCAtLSBzdWNoIGFzIHdoYXQg aXMgdXNlZCBpbiB0aGUNCj4gSUVURiBXaS1GaSBuZXR3b3Jrcy4gVGhpcyBkb2VzIGltcHJvdmUg c29tZXdoYXQgb3ZlciB0aGUgcmVzaWRlbnRpYWwNCj4gdmVyc2lvbiBvZiBXUEEsIGluIHdoaWNo IGFsbCB1c2VycyBzaGFyZSB0aGUgc2FtZSAiV2ktRmkgcGFzc3dvcmQiLCBiZWNhdXNlDQo+IGl0 IHByb3ZpZGVzIGJldHRlciBpc29sYXRpb24gYmV0d2VlbiB1c2Vycy4gQnV0IEkgd291bGQgaGF2 ZSBhIGhhcmQgdGltZQ0KPiByZWNvbW1lbmRpbmcgODAyLjF4IGRlcGxveW1lbnQgaW4gcmVzaWRl bnRpYWwgbmV0d29ya3MgImJlY2F1c2Ugb2YNCj4gREhDUHY2IHNlY3VyaXR5Ii4NCj4gDQo+IFdo aWxlIEkgZG8gbGlrZSB0aGUgIkRIQ1AgR3VhcmQiIGNsYXNzIG9mIHNvbHV0aW9ucywgSSBhbSBh bHNvIGNvbmNlcm5lZCB0aGF0DQo+IHRoZSBESENQIEd1YXJkIGNvbmNlcHQgaXMgb25seSBkZWZp bmVkIGJ5IHRoZSBjb21tZXJjaWFsIGxpdGVyYXR1cmUgb2YNCj4gc29tZSB2ZW5kb3JzIC0tIGFu ZCB0aGUgc2FtZSBnb2VzIGZvciBESENQIFNub29waW5nLCB3aGljaCBjb3VsZCBoYXZlIGENCj4g dmFyaWV0eSBvZiBtZWFuaW5ncy4gSWYgeW91IHdhbnQgdG8gdXNlIHRoYXQgdGVybSwgdGhlbiB5 b3Ugc2hvdWxkIGFkZCBhDQo+IHJlZmVyZW5jZSB0byB0aGUgcGFwZXIgd2hlcmUgdGhpcyBpcyBk ZWZpbmVkLiBPciB5b3UgY291bGQgdXNlIG5ldXRyYWwNCj4gbGFuZ3VhZ2UsIGxpa2U6DQo+IA0K PiAgIENvbnNpZGVyaW5nIHRoYXQsIG5ldHdvcmtzIHVzaW5nIERIQ1B2NiwgZGVwZW5kaW5nIG9u IHRoZWlyIHNwZWNpZmljDQo+ICAgdG9wb2xvZ2llcywgc2hvdWxkIGNvbnNpZGVyIHVzaW5nIGFj Y2VzcyBjb250cm9sIG1lY2hhbmlzbXMgc3VjaCBhcw0KPiAgIHRob3NlIGJhc2VkIG9uIElFRUUt ODAyLjFYLCBhbmQgREhDUHY2IGZpbHRlcmluZyBtZWNoYW5pc21zIGRlc2lnbmVkIHRvDQo+ICAg cHJldmVudCBmb3J3YXJkaW5nIG9mIHNwb29mZWQgREhDUHY2IHBhY2tldHMgdGhyb3VnaCB0aGUg cm91dGVyLCBvZnRlbg0KPiAgIHJlZmVycmVkIHRvIGFzICJESENQIEd1YXJkLiINCg0KVGhlcmUg YXJlIG5vIGV4cGVjdGF0aW9ucyBleHByZXNzZWQgZWl0aGVyIGluIHRoaXMgZHJhZnQgb3IgUkZD IDcwODQgKHdoaWNoIHRoaXMgZHJhZnQgYnVpbGRzIHVwb24pIHRoYXQgdGhlIENFIHJvdXRlciBt aWdodCBiZSBmb3J3YXJkaW5nIChvciByZWxheWluZykgREhDUHY2IHBhY2tldHMgdGhyb3VnaCB0 aGUgcm91dGVyLiBSRkMgNzA4NCByZXF1aXJlcyB0aGUgQ0Ugcm91dGVyIHRvIGhhdmUgaXRzIG93 biBXQU4tZmFjaW5nIERIQ1B2NiBjbGllbnQuIElmIGl0IHdhbnRzIHRvIHN1cHBvcnQgYW55IHNv cnQgb2YgTEFOLXNpZGUgREhDUHY2LCBpdCBTSE9VTEQgaGF2ZSBhIERIQ1B2NiBzZXJ2ZXIuIE5v dGhpbmcgYWJvdXQgZm9yd2FyZGluZyBvciByZWxheWluZy4gQWdhaW4sIEkgY29udGVuZCB0aGF0 IGRpc2N1c3NpbmcgREhDUCBHdWFyZCBpbiB0aGUgU2VjdXJpdHkgc2VjdGlvbiBpcyBvdXQgb2Yg c2NvcGUuDQoNCkJhcmJhcmENCg0KPiBJIGFtIGFsc28gc2tlcHRpY2FsIG9mIHRoZSBtZW50aW9u IG9mICJTTUUiIGluIHRoZSBsYXN0IHBhcmFncmFwaCwgaW4NCj4gImRlcGxveW1lbnQgb2YgSVB2 NGFhUyBpbiByZXNpZGVudGlhbCwgU09ITyBhbmQgU01FIG5ldHdvcmtzIi4gVGhlDQo+IGRlZmlu aXRpb24gb2Ygd2hhdCBpcyBhIHNtYWxsIG9yIG1lZGl1bSBlbnRlcnByaXNlIHZhcmllcyBieSBj b3VudHJpZXMuDQo+IEluIHRoZSBFdXJvcGVhbiBVbmlvbiwgaXQgaXMgdXAgdG8gMjUwIGVtcGxv eWVlcy4gSW4gdGhlIFVTLCBpdCBpcyBkZWZpbmVkIGJ5DQo+IHJldmVudWVzIGFuZCBlbXBsb3ll ZXMgbGltaXQsIHR5cGljYWxseSBmZXdlciB0aGFuIDUwMCBlbXBsb3llZXMuIEluIG90aGVyDQo+ IHBhcnQgb2YgdGhlIHdvcmxkLCBpdCBjYW4gYmUgZmV3ZXIgdGhhbiA1MCBlbXBsb3llZXMsIG9y IG1heWJlIGl0IGlzIGp1c3QNCj4gZGVmaW5lZCBieSBhIGxpbWl0IG9uIHJldmVudWVzLiBJbiBh bnkgY2FzZSwgSSB3b3VsZCBwZXJzb25hbGx5IGJlIHJlbHVjdGFudCB0bw0KPiBkZXBsb3kgc2lt cGxlIGRldmljZXMgbGlrZSBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGluIGEgbmV0d29yayB3aXRo IDEwMCB0byAyMDANCj4gcGVvcGxlLCBsZXQgYWxvbmUgNTAwLiBUaGF0IHdvdWxkIGJlIHB1c2hp bmcgbHVjayBhIGJpdCB0b28gZmFyLg0KPiANCj4gVGhlIGludHJvZHVjdGlvbiBvZiB0aGUgZHJh ZnQgc2F5cyAiVGhpcyBkb2N1bWVudCBkZWZpbmVzIElQdjQgc2VydmljZQ0KPiBjb250aW51aXR5 IGZlYXR1cmVzIG92ZXIgYW4gSVB2Ni1vbmx5IG5ldHdvcmssIGZvciBhIHJlc2lkZW50aWFsIG9y IHNtYWxsLQ0KPiBvZmZpY2Ugcm91dGVyLi4uIiBJIHdvdWxkIHN1Z2dlc3QgdXNpbmcgZXhhY3Rs eSB0aGUgc2FtZSBsYW5ndWFnZSwgYXMgaW46DQo+IA0KPiAgIEFzIHN0YXRlZCBpbiB0aGUgaW50 cm9kdWN0aW9uLCB0aGlzIGRvY3VtZW50IGFkZHJlc3NlcyBkZXBsb3ltZW50IG9mDQo+ICAgSVB2 NGFhUyBpbiByZXNpZGVudGlhbCBvciBzbWFsbC1vZmZpY2UgbmV0d29ya3MuICBEZXBsb3ltZW50 IGluIG1vcmUNCj4gICBjaGFsbGVuZ2luZyBlbnZpcm9ubWVudHMgd291bGQgcmVxdWlyZSBhZGRp dGlvbmFsIHNlY3VyaXR5IGFuYWx5c2lzLg0KPiANCj4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4g DQo+IA0KDQo= From nobody Tue Jan 8 10:38:59 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 E82B6130F7B; Tue, 8 Jan 2019 10:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9NQsfahmUCS; Tue, 8 Jan 2019 10:38:41 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42B2130F7C; Tue, 8 Jan 2019 10:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546972717; x=1547577517; 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=NWHTAjpB3qgF9RIdvIm5gVBi9kigqLV1nQcvxISA548=; b=icgLx3vD/73Ik WT7CVo/UcuZ9ZZns2kOxZOqfqJ5NvwGfSfNi6X/x5j/bCmYYR/+KGWCk56wNU99i deV5XjFB4/9ZDJd0Y3ZufA7O/91l9f8DIAy3FB03jKGdqgdjlV0mMAhm+Cfrakcn JLalSVriJ1TkIMzpDKPdEDJdkAXXYY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 08 Jan 2019 19:38:37 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 08 Jan 2019 19:38:36 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006102125.msg; Tue, 08 Jan 2019 19:38:34 +0100 X-MDRemoteIP: 2001:470:1f09:495:3c42:f3de:5da6:6fc4 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Tue, 08 Jan 2019 19:38:34 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1911ba6fdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Tue, 08 Jan 2019 19:38:30 +0100 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , 'Christian Huitema' CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 08 Jan 2019 18:38:45 -0000 Hi Barbara, The security concerns raised *initially* by Christian were related to the u= se of DHCP for configuring the WAN. At least that was what I understood. Th= en we continued discussing about the LAN, which I agree with you, is not a = requirement on this document. I guess the right way to approach this will be to update RFC6092 with new m= inimum security requirements, but this is out of the scope of this thread. This is what I'm proposing, making sure that we are speaking about the DHCP= v6 requirements from this document, but at the same time remembering that t= he LAN side is also important (but not in the scope of this document): 8. Security Considerations The IPv6 Transition CE Router must comply with the Security Considerations as stated in [RFC7084], as well as those stated by each transition mechanism implemented by the IPv6 Transition CE Router. As described in [RFC8026] and [RFC8415] Security Consideration sections, there are generic DHCP security issues, which in the case of this document means that malicious nodes may alter the priority of the transition mechanisms. Considering that, networks using DHCPv6 as indicated in this document,= =20 depending on their specific topologies, should consider using access control mechanisms such as those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designed to prevent forwarding of spoofed DHCPv6 packets to the IPv6 Transition CE, often referred to as "DHCP Guard". Those can be used as well, in the=20 LAN side, but this is out of the scope of this document. As stated in the introduction, this document addresses deployment of IPv4aaS in residential or SOHO networks. Deployment in more challenging environments would require additional security analysis. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Fecha: martes, 8 de enero de 2019, 18:16 Para: 'Christian Huitema' , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "ietf@ietf.org" , "se= cdir@ietf.org" Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 > Maybe I was not clear. I am not overly concerned with what happens on= the > WAN side -- I assume that the ISP deploying customer premise devices = will > find a way to provision them securely. I am concerned that using > DHCPv6 to provision networking parameters on the local hosts exposes > these hosts to generic DHCP spoofing attacks. To mount the DHCP spoof= ing > attacks, the attacker will need to either gain connectivity to the lo= cal > network, or gain controlled of a local device. Access control protoco= ls like > 802.1x will prevent unauthorized devices from connecting to the local > network; they will not close the second avenue of attack, something t= hat > solutions like DHCP guard would do. =20 I agree completely that 802.1X is irrelevant to the types of LANs the C= E routers described by this draft are used in, and shouldn't be mentioned i= n reference to the LAN interfaces of these CE routers. However, IMO, the security section should be discussing security concer= ns that arise specifically as a result of the requirements in the draft. Co= ncerns that are independent of these requirements are out of scope. AFAICT,= none of the requirements in this draft create/enable new threats or attack= vectors related to LAN DHCP spoofing attacks; therefore LAN DHCP spoofing = attacks (discussing them and proposing how to address them) are out of scop= e. =20 > The local router can filter which packets are relayed between Wi-Fi d= evices, > and can filter out spoofed DHCP packets. That's reasonably easy to de= ploy in > small networks, where the only authorized DHCP server is located on t= he > router itself. Of course, the current document is not meant as a gene= ral > home router requirement draft -- it just specifies the narrow problem= of how > these routers should facilitate deployment of > IPv4 as a service. I do like Jordi's succession to refer to DHCP Guar= d as a > potential mitigation of DHCPv6 issues, because it can be deployed sim= ply and > it would thwart a series of potential attacks. =20 Intra-LAN routing/bridging/switching/filtering/relaying is out of scope= of this draft. Intra-LAN behaviors are not relevant to IPv4aaS. There is n= o mention of LAN-side DHCPv6 (or DHCPv4) in the draft. All mention of DHCPv= 6 is WAN interface DHCPv6 client behavior. DHCP(v6) guard isn't a client be= havior. I don't like Jordi's suggested text, because (1) as a WAN behavior = (which is how most people will interpret it) DHCP guard makes no sense, and= (2) as a LAN behavior it's out of scope.=20 =20 > I am less enthusiastic about 802.1x, because as I said above it addre= sses a > fraction of the problem, but not the whole problem. Standard deployme= nt of > 802.1x requires an authentication server, which currently does not co= me with > small routers. It also requires management of this authentication ser= ver, > which is a tall order in these small networks. > There have been attempts to define a simpler profile of 802.1x, in wh= ich all > users have the same ID and the same password -- such as what is used = in the > IETF Wi-Fi networks. This does improve somewhat over the residential > version of WPA, in which all users share the same "Wi-Fi password", b= ecause > it provides better isolation between users. But I would have a hard t= ime > recommending 802.1x deployment in residential networks "because of > DHCPv6 security". >=20 > While I do like the "DHCP Guard" class of solutions, I am also concer= ned that > the DHCP Guard concept is only defined by the commercial literature o= f > some vendors -- and the same goes for DHCP Snooping, which could have= a > variety of meanings. If you want to use that term, then you should ad= d a > reference to the paper where this is defined. Or you could use neutra= l > language, like: >=20 > Considering that, networks using DHCPv6, depending on their specifi= c > topologies, should consider using access control mechanisms such as > those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designe= d to > prevent forwarding of spoofed DHCPv6 packets through the router, of= ten > referred to as "DHCP Guard." =20 There are no expectations expressed either in this draft or RFC 7084 (w= hich this draft builds upon) that the CE router might be forwarding (or rel= aying) DHCPv6 packets through the router. RFC 7084 requires the CE router t= o have its own WAN-facing DHCPv6 client. If it wants to support any sort of= LAN-side DHCPv6, it SHOULD have a DHCPv6 server. Nothing about forwarding = or relaying. Again, I contend that discussing DHCP Guard in the Security se= ction is out of scope. =20 Barbara =20 > I am also skeptical of the mention of "SME" in the last paragraph, in > "deployment of IPv4aaS in residential, SOHO and SME networks". The > definition of what is a small or medium enterprise varies by countrie= s. > In the European Union, it is up to 250 employees. In the US, it is de= fined by > revenues and employees limit, typically fewer than 500 employees. In = other > part of the world, it can be fewer than 50 employees, or maybe it is = just > defined by a limit on revenues. In any case, I would personally be re= luctant to > deploy simple devices like described in the draft in a network with 1= 00 to 200 > people, let alone 500. That would be pushing luck a bit too far. >=20 > The introduction of the draft says "This document defines IPv4 servic= e > continuity features over an IPv6-only network, for a residential or s= mall- > office router..." I would suggest using exactly the same language, as= in: >=20 > As stated in the introduction, this document addresses deployment o= f > IPv4aaS in residential or small-office networks. Deployment in mor= e > challenging environments would require additional security analysis= . >=20 > -- Christian Huitema >=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 Tue Jan 8 11:29: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 58423130FE1; Tue, 8 Jan 2019 11:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKe2qmqsiLfj; Tue, 8 Jan 2019 11:28:52 -0800 (PST) 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 C5CE2130FD7; Tue, 8 Jan 2019 11:28:47 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x08JPmmE000967; Tue, 8 Jan 2019 14:28:34 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2pw0wh2asm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jan 2019 14:28:33 -0500 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 x08JSWrN014604; Tue, 8 Jan 2019 14:28:33 -0500 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 x08JSMDc014339; Tue, 8 Jan 2019 14:28:23 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 4122E4048B5B; Tue, 8 Jan 2019 19:28:22 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30486.vci.att.com (Service) with ESMTPS id 22F744048B58; Tue, 8 Jan 2019 19:28:22 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 14:28:21 -0500 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , "'Christian Huitema'" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 Thread-Index: AQHUplIxzMK3YDjZl0aLw/nLjmGiN6Wj60wAgAAGJ4CAAHv9gP//vwTwgABhWgCAAIqGAIAAVx6wgACabgD//7QMIA== Date: Tue, 8 Jan 2019 19:28:20 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF886D9@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.241] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-08_10:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901080153 Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 08 Jan 2019 19:28:56 -0000 PiBUaGUgc2VjdXJpdHkgY29uY2VybnMgcmFpc2VkICppbml0aWFsbHkqIGJ5IENocmlzdGlhbiB3 ZXJlIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZg0KPiBESENQIGZvciBjb25maWd1cmluZyB0aGUgV0FO LiBBdCBsZWFzdCB0aGF0IHdhcyB3aGF0IEkgdW5kZXJzdG9vZC4gVGhlbiB3ZQ0KPiBjb250aW51 ZWQgZGlzY3Vzc2luZyBhYm91dCB0aGUgTEFOLCB3aGljaCBJIGFncmVlIHdpdGggeW91LCBpcyBu b3QgYQ0KPiByZXF1aXJlbWVudCBvbiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gSSBndWVzcyB0aGUg cmlnaHQgd2F5IHRvIGFwcHJvYWNoIHRoaXMgd2lsbCBiZSB0byB1cGRhdGUgUkZDNjA5MiB3aXRo IG5ldw0KPiBtaW5pbXVtIHNlY3VyaXR5IHJlcXVpcmVtZW50cywgYnV0IHRoaXMgaXMgb3V0IG9m IHRoZSBzY29wZSBvZiB0aGlzIHRocmVhZC4NCj4gDQo+IFRoaXMgaXMgd2hhdCBJJ20gcHJvcG9z aW5nLCBtYWtpbmcgc3VyZSB0aGF0IHdlIGFyZSBzcGVha2luZyBhYm91dCB0aGUNCj4gREhDUHY2 IHJlcXVpcmVtZW50cyBmcm9tIHRoaXMgZG9jdW1lbnQsIGJ1dCBhdCB0aGUgc2FtZSB0aW1lDQo+ IHJlbWVtYmVyaW5nIHRoYXQgdGhlIExBTiBzaWRlIGlzIGFsc28gaW1wb3J0YW50IChidXQgbm90 IGluIHRoZSBzY29wZSBvZiB0aGlzDQo+IGRvY3VtZW50KToNCj4gDQo+IDguICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucw0KPiANCj4gICAgVGhlIElQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgbXVz dCBjb21wbHkgd2l0aCB0aGUgU2VjdXJpdHkNCj4gICAgQ29uc2lkZXJhdGlvbnMgYXMgc3RhdGVk IGluIFtSRkM3MDg0XSwgYXMgd2VsbCBhcyB0aG9zZSBzdGF0ZWQgYnkNCj4gICAgZWFjaCB0cmFu c2l0aW9uIG1lY2hhbmlzbSBpbXBsZW1lbnRlZCBieSB0aGUgSVB2NiBUcmFuc2l0aW9uIENFDQo+ ICAgIFJvdXRlci4NCj4gDQo+ICAgIEFzIGRlc2NyaWJlZCBpbiBbUkZDODAyNl0gYW5kIFtSRkM4 NDE1XSBTZWN1cml0eSBDb25zaWRlcmF0aW9uDQo+ICAgIHNlY3Rpb25zLCB0aGVyZSBhcmUgZ2Vu ZXJpYyBESENQIHNlY3VyaXR5IGlzc3Vlcywgd2hpY2ggaW4gdGhlIGNhc2UNCj4gICAgb2YgdGhp cyBkb2N1bWVudCBtZWFucyB0aGF0IG1hbGljaW91cyBub2RlcyBtYXkgYWx0ZXIgdGhlIHByaW9y aXR5IG9mDQo+ICAgIHRoZSB0cmFuc2l0aW9uIG1lY2hhbmlzbXMuDQo+IA0KPiAgICBDb25zaWRl cmluZyB0aGF0LCBuZXR3b3JrcyB1c2luZyBESENQdjYgYXMgaW5kaWNhdGVkIGluIHRoaXMgZG9j dW1lbnQsDQo+ICAgIGRlcGVuZGluZyBvbiB0aGVpciBzcGVjaWZpYyB0b3BvbG9naWVzLCBzaG91 bGQgY29uc2lkZXIgdXNpbmcgYWNjZXNzDQo+ICAgIGNvbnRyb2wgbWVjaGFuaXNtcyBzdWNoIGFz IHRob3NlIGJhc2VkIG9uIElFRUUtODAyLjFYLCBhbmQNCj4gICAgREhDUHY2IGZpbHRlcmluZyBt ZWNoYW5pc21zIGRlc2lnbmVkIHRvIHByZXZlbnQgZm9yd2FyZGluZw0KPiAgICBvZiBzcG9vZmVk IERIQ1B2NiBwYWNrZXRzIHRvIHRoZSBJUHY2IFRyYW5zaXRpb24gQ0UsIG9mdGVuDQo+ICAgIHJl ZmVycmVkIHRvIGFzICJESENQIEd1YXJkIi4gVGhvc2UgY2FuIGJlIHVzZWQgYXMgd2VsbCwgaW4g dGhlDQo+ICAgIExBTiBzaWRlLCBidXQgdGhpcyBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQuDQo+DQo+ICAgIEFzIHN0YXRlZCBpbiB0aGUgaW50cm9kdWN0aW9uLCB0aGlzIGRv Y3VtZW50IGFkZHJlc3NlcyBkZXBsb3ltZW50IG9mDQo+ICAgIElQdjRhYVMgaW4gcmVzaWRlbnRp YWwgb3IgU09ITyBuZXR3b3Jrcy4gIERlcGxveW1lbnQgaW4gbW9yZQ0KPiAgICBjaGFsbGVuZ2lu ZyBlbnZpcm9ubWVudHMgd291bGQgcmVxdWlyZSBhZGRpdGlvbmFsIHNlY3VyaXR5IGFuYWx5c2lz Lg0KDQoNCkhvdyBhY2Nlc3MgbmV0d29ya3Mgc2VjdXJlIHRoZWlyIGluZnJhc3RydWN0dXJlIGlz IHNwZWNpZmljIHRvIHRoYXQgYWNjZXNzIG5ldHdvcmsncyBhcmNoaXRlY3R1cmUuIEFjY2VzcyBu ZXR3b3JrIGFyY2hpdGVjdHVyZXMgYXJlIHNwZWNpZmllZCBieSBvcmdzIHN1Y2ggYXMgM0dQUCwg Q2FibGVMYWJzLCBhbmQgQkJGLiBJbiB0aGUgY29udGV4dCBvZiBzb21lIGFjY2VzcyBuZXR3b3Jr IGFyY2hpdGVjdHVyZXMsIDgwMi4xWCBpcyBub3QgdGhlIHNvbHV0aW9uIHRoYXQgaXMgdXNlZCwg YW5kIElFVEYgc2hvdWxkbid0IGJlIHN1Z2dlc3RpbmcgdGhleSB1c2UgaXQuIEknbSBub3QgYXdh cmUgb2YgYW55IHRoYXQgdXNlICJESENQdjYgZmlsdGVyaW5nIG1lY2hhbmlzbXMiIG9yICJESENQ IEd1YXJkIi4gTW9zdCB0ZW5kIHRvIHVzZSBtdWNoIG1vcmUgZXh0cmVtZSBzZXBhcmF0aW9uIG9m IGN1c3RvbWVyIHRyYWZmaWMuIEFuZCBpZiBhbiBJU1AncyBvd24gbWFuYWdlZCBuZXR3b3JrIGVs ZW1lbnRzIGFyZSBjb21wcm9taXNlZCwgIkRIQ1AgR3VhcmQiIGlzIG5vdCB0aGUgYW5zd2VyIC0t IGlkZW50aWZ5aW5nIHRoZSBjb21wcm9taXNlZCBuZXR3b3JrIGVsZW1lbnQgYW5kIHJlbW92aW5n IGl0IGZyb20gdGhlIG5ldHdvcmsgaXMgdGhlIGFuc3dlci4gV2hpY2ggbWFrZXMgdGhpcyByZWNv bW1lbmRhdGlvbiBpbGxvZ2ljYWwgYW5kIGluYXBwcm9wcmlhdGUuIEFjY2VzcyBuZXR3b3JrIGFy Y2hpdGVjdHVyZSBpcyBub3QgaW4gc2NvcGUgb2YgdGhpcyBkcmFmdC4gSWYgeW91IHJlYWxseSB3 YW50IHRoZSBwYXJhZ3JhcGggYWJvdXQgZ2VuZXJpYyBESENQIHNlY3VyaXR5IGlzc3VlcywgSSB3 b3VsZCBzdWdnZXN0IGFkZGluZyBzb21ldGhpbmcgbGlrZSB0aGlzIGF0IHRoZSBlbmQ6ICJBY2Nl c3MgbmV0d29yayBhcmNoaXRlY3R1cmUgZm9yIHNlY3VyaW5nIERIQ1Agd2l0aGluIHRoZSBhY2Nl c3MgbmV0d29yayBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gU2VjdXJpbmcgREhD UCBpbiB0aGUgTEFOIGlzIGFsc28gbm90IGluIHNjb3BlLiBESENQIHBhY2tldHMgTVVTVCBOT1Qg YmUgZm9yd2FyZGVkIGJldHdlZW4gTEFOIGFuZCBXQU4gaW50ZXJmYWNlcyBvZiBhbiBJUHY2IFRy YW5zaXRpb24gQ0Ugcm91dGVyLiIgQW5kIGRlbGV0ZSB0aGUgbGFzdCAyIHBhcmFncmFwaHMuDQpC YXJiYXJhDQoNCj4gUmVnYXJkcywNCj4gSm9yZGkNCj4gDQo+IA0KPiANCj4g77u/LS0tLS1NZW5z YWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBl biBub21icmUgZGUgIlNUQVJLLCBCQVJCQVJBIEgiDQo+IDxiczc2NTJAYXR0LmNvbT4NCj4gRmVj aGE6IG1hcnRlcywgOCBkZSBlbmVybyBkZSAyMDE5LCAxODoxNg0KPiBQYXJhOiAnQ2hyaXN0aWFu IEh1aXRlbWEnIDxodWl0ZW1hQGh1aXRlbWEubmV0PiwgSk9SREkgUEFMRVQgTUFSVElORVoNCj4g PGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+DQo+IENDOiAidjZv cHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4sICJpZXRmQGlldGYub3JnIiA8aWV0ZkBpZXRm Lm9yZz4sDQo+ICJzZWNkaXJAaWV0Zi5vcmciIDxzZWNkaXJAaWV0Zi5vcmc+DQo+IEFzdW50bzog UmU6IFt2Nm9wc10gU2VjZGlyIHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLXY2b3BzLXRy YW5zaXRpb24tDQo+IGlwdjRhYXMtMTINCj4gDQo+ICAgICA+IE1heWJlIEkgd2FzIG5vdCBjbGVh ci4gSSBhbSBub3Qgb3Zlcmx5IGNvbmNlcm5lZCB3aXRoIHdoYXQgaGFwcGVucyBvbg0KPiB0aGUN Cj4gICAgID4gV0FOIHNpZGUgLS0gSSBhc3N1bWUgdGhhdCB0aGUgSVNQIGRlcGxveWluZyBjdXN0 b21lciBwcmVtaXNlIGRldmljZXMNCj4gd2lsbA0KPiAgICAgPiBmaW5kIGEgd2F5IHRvIHByb3Zp c2lvbiB0aGVtIHNlY3VyZWx5LiBJIGFtIGNvbmNlcm5lZCB0aGF0IHVzaW5nDQo+ICAgICA+IERI Q1B2NiB0byBwcm92aXNpb24gbmV0d29ya2luZyBwYXJhbWV0ZXJzIG9uIHRoZSBsb2NhbCBob3N0 cyBleHBvc2VzDQo+ICAgICA+IHRoZXNlIGhvc3RzIHRvIGdlbmVyaWMgREhDUCBzcG9vZmluZyBh dHRhY2tzLiBUbyBtb3VudCB0aGUgREhDUA0KPiBzcG9vZmluZw0KPiAgICAgPiBhdHRhY2tzLCB0 aGUgYXR0YWNrZXIgd2lsbCBuZWVkIHRvIGVpdGhlciBnYWluIGNvbm5lY3Rpdml0eSB0byB0aGUg bG9jYWwNCj4gICAgID4gbmV0d29yaywgb3IgZ2FpbiBjb250cm9sbGVkIG9mIGEgbG9jYWwgZGV2 aWNlLiBBY2Nlc3MgY29udHJvbCBwcm90b2NvbHMgbGlrZQ0KPiAgICAgPiA4MDIuMXggd2lsbCBw cmV2ZW50IHVuYXV0aG9yaXplZCBkZXZpY2VzIGZyb20gY29ubmVjdGluZyB0byB0aGUgbG9jYWwN Cj4gICAgID4gbmV0d29yazsgdGhleSB3aWxsIG5vdCBjbG9zZSB0aGUgc2Vjb25kIGF2ZW51ZSBv ZiBhdHRhY2ssIHNvbWV0aGluZyB0aGF0DQo+ICAgICA+IHNvbHV0aW9ucyBsaWtlIERIQ1AgZ3Vh cmQgd291bGQgZG8uDQo+IA0KPiAgICAgSSBhZ3JlZSBjb21wbGV0ZWx5IHRoYXQgODAyLjFYIGlz IGlycmVsZXZhbnQgdG8gdGhlIHR5cGVzIG9mIExBTnMgdGhlIENFDQo+IHJvdXRlcnMgZGVzY3Jp YmVkIGJ5IHRoaXMgZHJhZnQgYXJlIHVzZWQgaW4sIGFuZCBzaG91bGRuJ3QgYmUgbWVudGlvbmVk IGluDQo+IHJlZmVyZW5jZSB0byB0aGUgTEFOIGludGVyZmFjZXMgb2YgdGhlc2UgQ0Ugcm91dGVy cy4NCj4gICAgIEhvd2V2ZXIsIElNTywgdGhlIHNlY3VyaXR5IHNlY3Rpb24gc2hvdWxkIGJlIGRp c2N1c3Npbmcgc2VjdXJpdHkgY29uY2VybnMNCj4gdGhhdCBhcmlzZSBzcGVjaWZpY2FsbHkgYXMg YSByZXN1bHQgb2YgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGUgZHJhZnQuIENvbmNlcm5zDQo+IHRo YXQgYXJlIGluZGVwZW5kZW50IG9mIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgb3V0IG9mIHNjb3Bl LiBBRkFJQ1QsIG5vbmUNCj4gb2YgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRyYWZ0IGNyZWF0 ZS9lbmFibGUgbmV3IHRocmVhdHMgb3IgYXR0YWNrIHZlY3RvcnMNCj4gcmVsYXRlZCB0byBMQU4g REhDUCBzcG9vZmluZyBhdHRhY2tzOyB0aGVyZWZvcmUgTEFOIERIQ1Agc3Bvb2ZpbmcgYXR0YWNr cw0KPiAoZGlzY3Vzc2luZyB0aGVtIGFuZCBwcm9wb3NpbmcgaG93IHRvIGFkZHJlc3MgdGhlbSkg YXJlIG91dCBvZiBzY29wZS4NCj4gDQo+ICAgICA+IFRoZSBsb2NhbCByb3V0ZXIgY2FuIGZpbHRl ciB3aGljaCBwYWNrZXRzIGFyZSByZWxheWVkIGJldHdlZW4gV2ktRmkNCj4gZGV2aWNlcywNCj4g ICAgID4gYW5kIGNhbiBmaWx0ZXIgb3V0IHNwb29mZWQgREhDUCBwYWNrZXRzLiBUaGF0J3MgcmVh c29uYWJseSBlYXN5IHRvDQo+IGRlcGxveSBpbg0KPiAgICAgPiBzbWFsbCBuZXR3b3Jrcywgd2hl cmUgdGhlIG9ubHkgYXV0aG9yaXplZCBESENQIHNlcnZlciBpcyBsb2NhdGVkIG9uIHRoZQ0KPiAg ICAgPiByb3V0ZXIgaXRzZWxmLiBPZiBjb3Vyc2UsIHRoZSBjdXJyZW50IGRvY3VtZW50IGlzIG5v dCBtZWFudCBhcyBhIGdlbmVyYWwNCj4gICAgID4gaG9tZSByb3V0ZXIgcmVxdWlyZW1lbnQgZHJh ZnQgLS0gaXQganVzdCBzcGVjaWZpZXMgdGhlIG5hcnJvdyBwcm9ibGVtIG9mDQo+IGhvdw0KPiAg ICAgPiB0aGVzZSByb3V0ZXJzIHNob3VsZCBmYWNpbGl0YXRlIGRlcGxveW1lbnQgb2YNCj4gICAg ID4gSVB2NCBhcyBhIHNlcnZpY2UuIEkgZG8gbGlrZSBKb3JkaSdzIHN1Y2Nlc3Npb24gdG8gcmVm ZXIgdG8gREhDUCBHdWFyZCBhcyBhDQo+ICAgICA+IHBvdGVudGlhbCBtaXRpZ2F0aW9uIG9mIERI Q1B2NiBpc3N1ZXMsIGJlY2F1c2UgaXQgY2FuIGJlIGRlcGxveWVkIHNpbXBseQ0KPiBhbmQNCj4g ICAgID4gaXQgd291bGQgdGh3YXJ0IGEgc2VyaWVzIG9mIHBvdGVudGlhbCBhdHRhY2tzLg0KPiAN Cj4gICAgIEludHJhLUxBTiByb3V0aW5nL2JyaWRnaW5nL3N3aXRjaGluZy9maWx0ZXJpbmcvcmVs YXlpbmcgaXMgb3V0IG9mIHNjb3BlIG9mDQo+IHRoaXMgZHJhZnQuIEludHJhLUxBTiBiZWhhdmlv cnMgYXJlIG5vdCByZWxldmFudCB0byBJUHY0YWFTLiBUaGVyZSBpcyBubw0KPiBtZW50aW9uIG9m IExBTi1zaWRlIERIQ1B2NiAob3IgREhDUHY0KSBpbiB0aGUgZHJhZnQuIEFsbCBtZW50aW9uIG9m IERIQ1B2Ng0KPiBpcyBXQU4gaW50ZXJmYWNlIERIQ1B2NiBjbGllbnQgYmVoYXZpb3IuIERIQ1Ao djYpIGd1YXJkIGlzbid0IGEgY2xpZW50DQo+IGJlaGF2aW9yLiBJIGRvbid0IGxpa2UgSm9yZGkn cyBzdWdnZXN0ZWQgdGV4dCwgYmVjYXVzZSAoMSkgYXMgYSBXQU4gYmVoYXZpb3INCj4gKHdoaWNo IGlzIGhvdyBtb3N0IHBlb3BsZSB3aWxsIGludGVycHJldCBpdCkgREhDUCBndWFyZCBtYWtlcyBu byBzZW5zZSwgYW5kDQo+ICgyKSBhcyBhIExBTiBiZWhhdmlvciBpdCdzIG91dCBvZiBzY29wZS4N Cj4gDQo+ICAgICA+IEkgYW0gbGVzcyBlbnRodXNpYXN0aWMgYWJvdXQgODAyLjF4LCBiZWNhdXNl IGFzIEkgc2FpZCBhYm92ZSBpdCBhZGRyZXNzZXMgYQ0KPiAgICAgPiBmcmFjdGlvbiBvZiB0aGUg cHJvYmxlbSwgYnV0IG5vdCB0aGUgd2hvbGUgcHJvYmxlbS4gU3RhbmRhcmQNCj4gZGVwbG95bWVu dCBvZg0KPiAgICAgPiA4MDIuMXggcmVxdWlyZXMgYW4gYXV0aGVudGljYXRpb24gc2VydmVyLCB3 aGljaCBjdXJyZW50bHkgZG9lcyBub3QgY29tZQ0KPiB3aXRoDQo+ICAgICA+IHNtYWxsIHJvdXRl cnMuIEl0IGFsc28gcmVxdWlyZXMgbWFuYWdlbWVudCBvZiB0aGlzIGF1dGhlbnRpY2F0aW9uIHNl cnZlciwNCj4gICAgID4gd2hpY2ggaXMgYSB0YWxsIG9yZGVyIGluIHRoZXNlIHNtYWxsIG5ldHdv cmtzLg0KPiAgICAgPiBUaGVyZSBoYXZlIGJlZW4gYXR0ZW1wdHMgdG8gZGVmaW5lIGEgc2ltcGxl ciBwcm9maWxlIG9mIDgwMi4xeCwgaW4gd2hpY2gNCj4gYWxsDQo+ICAgICA+IHVzZXJzIGhhdmUg dGhlIHNhbWUgSUQgYW5kIHRoZSBzYW1lIHBhc3N3b3JkIC0tIHN1Y2ggYXMgd2hhdCBpcyB1c2Vk IGluDQo+IHRoZQ0KPiAgICAgPiBJRVRGIFdpLUZpIG5ldHdvcmtzLiBUaGlzIGRvZXMgaW1wcm92 ZSBzb21ld2hhdCBvdmVyIHRoZSByZXNpZGVudGlhbA0KPiAgICAgPiB2ZXJzaW9uIG9mIFdQQSwg aW4gd2hpY2ggYWxsIHVzZXJzIHNoYXJlIHRoZSBzYW1lICJXaS1GaSBwYXNzd29yZCIsDQo+IGJl Y2F1c2UNCj4gICAgID4gaXQgcHJvdmlkZXMgYmV0dGVyIGlzb2xhdGlvbiBiZXR3ZWVuIHVzZXJz LiBCdXQgSSB3b3VsZCBoYXZlIGEgaGFyZCB0aW1lDQo+ICAgICA+IHJlY29tbWVuZGluZyA4MDIu MXggZGVwbG95bWVudCBpbiByZXNpZGVudGlhbCBuZXR3b3JrcyAiYmVjYXVzZSBvZg0KPiAgICAg PiBESENQdjYgc2VjdXJpdHkiLg0KPiAgICAgPg0KPiAgICAgPiBXaGlsZSBJIGRvIGxpa2UgdGhl ICJESENQIEd1YXJkIiBjbGFzcyBvZiBzb2x1dGlvbnMsIEkgYW0gYWxzbyBjb25jZXJuZWQNCj4g dGhhdA0KPiAgICAgPiB0aGUgREhDUCBHdWFyZCBjb25jZXB0IGlzIG9ubHkgZGVmaW5lZCBieSB0 aGUgY29tbWVyY2lhbCBsaXRlcmF0dXJlIG9mDQo+ICAgICA+IHNvbWUgdmVuZG9ycyAtLSBhbmQg dGhlIHNhbWUgZ29lcyBmb3IgREhDUCBTbm9vcGluZywgd2hpY2ggY291bGQNCj4gaGF2ZSBhDQo+ ICAgICA+IHZhcmlldHkgb2YgbWVhbmluZ3MuIElmIHlvdSB3YW50IHRvIHVzZSB0aGF0IHRlcm0s IHRoZW4geW91IHNob3VsZCBhZGQgYQ0KPiAgICAgPiByZWZlcmVuY2UgdG8gdGhlIHBhcGVyIHdo ZXJlIHRoaXMgaXMgZGVmaW5lZC4gT3IgeW91IGNvdWxkIHVzZSBuZXV0cmFsDQo+ICAgICA+IGxh bmd1YWdlLCBsaWtlOg0KPiAgICAgPg0KPiAgICAgPiAgIENvbnNpZGVyaW5nIHRoYXQsIG5ldHdv cmtzIHVzaW5nIERIQ1B2NiwgZGVwZW5kaW5nIG9uIHRoZWlyIHNwZWNpZmljDQo+ICAgICA+ICAg dG9wb2xvZ2llcywgc2hvdWxkIGNvbnNpZGVyIHVzaW5nIGFjY2VzcyBjb250cm9sIG1lY2hhbmlz bXMgc3VjaCBhcw0KPiAgICAgPiAgIHRob3NlIGJhc2VkIG9uIElFRUUtODAyLjFYLCBhbmQgREhD UHY2IGZpbHRlcmluZyBtZWNoYW5pc21zIGRlc2lnbmVkDQo+IHRvDQo+ICAgICA+ICAgcHJldmVu dCBmb3J3YXJkaW5nIG9mIHNwb29mZWQgREhDUHY2IHBhY2tldHMgdGhyb3VnaCB0aGUgcm91dGVy LA0KPiBvZnRlbg0KPiAgICAgPiAgIHJlZmVycmVkIHRvIGFzICJESENQIEd1YXJkLiINCj4gDQo+ ICAgICBUaGVyZSBhcmUgbm8gZXhwZWN0YXRpb25zIGV4cHJlc3NlZCBlaXRoZXIgaW4gdGhpcyBk cmFmdCBvciBSRkMgNzA4NCAod2hpY2gNCj4gdGhpcyBkcmFmdCBidWlsZHMgdXBvbikgdGhhdCB0 aGUgQ0Ugcm91dGVyIG1pZ2h0IGJlIGZvcndhcmRpbmcgKG9yIHJlbGF5aW5nKQ0KPiBESENQdjYg cGFja2V0cyB0aHJvdWdoIHRoZSByb3V0ZXIuIFJGQyA3MDg0IHJlcXVpcmVzIHRoZSBDRSByb3V0 ZXIgdG8gaGF2ZQ0KPiBpdHMgb3duIFdBTi1mYWNpbmcgREhDUHY2IGNsaWVudC4gSWYgaXQgd2Fu dHMgdG8gc3VwcG9ydCBhbnkgc29ydCBvZiBMQU4tc2lkZQ0KPiBESENQdjYsIGl0IFNIT1VMRCBo YXZlIGEgREhDUHY2IHNlcnZlci4gTm90aGluZyBhYm91dCBmb3J3YXJkaW5nIG9yDQo+IHJlbGF5 aW5nLiBBZ2FpbiwgSSBjb250ZW5kIHRoYXQgZGlzY3Vzc2luZyBESENQIEd1YXJkIGluIHRoZSBT ZWN1cml0eSBzZWN0aW9uDQo+IGlzIG91dCBvZiBzY29wZS4NCj4gDQo+ICAgICBCYXJiYXJhDQo+ IA0KPiAgICAgPiBJIGFtIGFsc28gc2tlcHRpY2FsIG9mIHRoZSBtZW50aW9uIG9mICJTTUUiIGlu IHRoZSBsYXN0IHBhcmFncmFwaCwgaW4NCj4gICAgID4gImRlcGxveW1lbnQgb2YgSVB2NGFhUyBp biByZXNpZGVudGlhbCwgU09ITyBhbmQgU01FIG5ldHdvcmtzIi4gVGhlDQo+ICAgICA+IGRlZmlu aXRpb24gb2Ygd2hhdCBpcyBhIHNtYWxsIG9yIG1lZGl1bSBlbnRlcnByaXNlIHZhcmllcyBieSBj b3VudHJpZXMuDQo+ICAgICA+IEluIHRoZSBFdXJvcGVhbiBVbmlvbiwgaXQgaXMgdXAgdG8gMjUw IGVtcGxveWVlcy4gSW4gdGhlIFVTLCBpdCBpcyBkZWZpbmVkDQo+IGJ5DQo+ICAgICA+IHJldmVu dWVzIGFuZCBlbXBsb3llZXMgbGltaXQsIHR5cGljYWxseSBmZXdlciB0aGFuIDUwMCBlbXBsb3ll ZXMuIEluDQo+IG90aGVyDQo+ICAgICA+IHBhcnQgb2YgdGhlIHdvcmxkLCBpdCBjYW4gYmUgZmV3 ZXIgdGhhbiA1MCBlbXBsb3llZXMsIG9yIG1heWJlIGl0IGlzIGp1c3QNCj4gICAgID4gZGVmaW5l ZCBieSBhIGxpbWl0IG9uIHJldmVudWVzLiBJbiBhbnkgY2FzZSwgSSB3b3VsZCBwZXJzb25hbGx5 IGJlDQo+IHJlbHVjdGFudCB0bw0KPiAgICAgPiBkZXBsb3kgc2ltcGxlIGRldmljZXMgbGlrZSBk ZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGluIGEgbmV0d29yayB3aXRoIDEwMCB0bw0KPiAyMDANCj4g ICAgID4gcGVvcGxlLCBsZXQgYWxvbmUgNTAwLiBUaGF0IHdvdWxkIGJlIHB1c2hpbmcgbHVjayBh IGJpdCB0b28gZmFyLg0KPiAgICAgPg0KPiAgICAgPiBUaGUgaW50cm9kdWN0aW9uIG9mIHRoZSBk cmFmdCBzYXlzICJUaGlzIGRvY3VtZW50IGRlZmluZXMgSVB2NCBzZXJ2aWNlDQo+ICAgICA+IGNv bnRpbnVpdHkgZmVhdHVyZXMgb3ZlciBhbiBJUHY2LW9ubHkgbmV0d29yaywgZm9yIGEgcmVzaWRl bnRpYWwgb3Igc21hbGwtDQo+ICAgICA+IG9mZmljZSByb3V0ZXIuLi4iIEkgd291bGQgc3VnZ2Vz dCB1c2luZyBleGFjdGx5IHRoZSBzYW1lIGxhbmd1YWdlLCBhcyBpbjoNCj4gICAgID4NCj4gICAg ID4gICBBcyBzdGF0ZWQgaW4gdGhlIGludHJvZHVjdGlvbiwgdGhpcyBkb2N1bWVudCBhZGRyZXNz ZXMgZGVwbG95bWVudCBvZg0KPiAgICAgPiAgIElQdjRhYVMgaW4gcmVzaWRlbnRpYWwgb3Igc21h bGwtb2ZmaWNlIG5ldHdvcmtzLiAgRGVwbG95bWVudCBpbiBtb3JlDQo+ICAgICA+ICAgY2hhbGxl bmdpbmcgZW52aXJvbm1lbnRzIHdvdWxkIHJlcXVpcmUgYWRkaXRpb25hbCBzZWN1cml0eSBhbmFs eXNpcy4NCj4gICAgID4NCj4gICAgID4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4gICAgID4NCj4g ICAgID4NCj4gDQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+ICAgICB2Nm9wc0BpZXRmLm9yZw0K PiAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0K PiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lGYVEmYz1MRlla LQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy0NCj4gOHNjOFNZOFRxNHZyZm9nJm09Z0d3 dXNmU0NVamtRaWV1TlExSTc2eU56NTQzMjFMejhraVFwcUhCQnZ1MCZzDQo+ID02Mk5KajJueEhw N2xaeGY1aUVmdDRTRlo5LW1YUHZxU0F2WnZoRmJ1T3UwJmU9DQo+IA0KPiANCj4gDQo+IA0KPiAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMg b3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNBX193d3cudGhlaXB2 NmNvbXBhbnkuY29tJmQ9RHdJRmFRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6 aEMtDQo+IDhzYzhTWThUcTR2cmZvZyZtPWdHd3VzZlNDVWprUWlldU5RMUk3NnlOejU0MzIxTHo4 a2lRcHFIQkJ2dTAmcw0KPiA9eVJ3ZnpDMFVrZXlXd1dvQzVMdGhXa0dERGtBUFNvcXJOVzJNWnZG dk5fbyZlPQ0KPiBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2Fn ZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvcg0KPiBjb25m aWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIg bm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLA0KPiBjb3B5aW5nLCBkaXN0cmli dXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlm DQo+IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYQ0KPiBjcmltaW5hbCBvZmZlbnNlLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55DQo+IGRp c2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9m IHRoaXMgaW5mb3JtYXRpb24sDQo+IGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNo ZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUNCj4gY29uc2lkZXJlZCBh IGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5k ZXIgdG8NCj4gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0K PiANCj4gDQoNCg== From nobody Tue Jan 8 20:43:00 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 3AE14129AB8; Tue, 8 Jan 2019 20:42:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154700897323.25519.3473287235255788469.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2019 20:42:53 -0800 Archived-At: Subject: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) 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, 09 Jan 2019 04:42:53 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: Discuss 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-transition-ipv4aas/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3.2.1. I do not see why the use of RFC8115 (464XLAT-6) is being mandated for the use of 464XLAT. What is the intent of such a mandate? Especially, since the uPrefix64 is used for address synthesis for SSM for IPv4 *sources* in the IPv6 domain. Given that IPv4 multicast support itself is only conditional in Section 4, I do not see a need at all for this MUST requirement. Can you please clarify? From nobody Tue Jan 8 22:13: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 23E1E12D4E7 for ; Tue, 8 Jan 2019 22:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBKXME9eXwwb for ; Tue, 8 Jan 2019 22:13:15 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 840AF129C6A for ; Tue, 8 Jan 2019 22:13:15 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gh772-000jnr-1H for v6ops@ietf.org; Wed, 09 Jan 2019 07:13:13 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gh76x-0005Em-IP for v6ops@ietf.org; Wed, 09 Jan 2019 01:13:08 -0500 Received: (qmail 25413 invoked from network); 9 Jan 2019 06:13:06 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jan 2019 06:13:06 -0000 To: JORDI PALET MARTINEZ , "STARK, BARBARA H" Cc: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <9674e692-41fd-1ef2-c4dc-9c01d4b49cc0@huitema.net> Date: Tue, 8 Jan 2019 22:13:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.232 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jMfeynSaT0c7a12CP4J+WR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9AxWC0E4UFL1FYKawsH9LlKzVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5+lC8ScYqqrIKKgZkuEMYGaXe0Of4jddu9xC8 8+iQ5nb7LoaTAX7mj3bIh4FDz/DsTWjvPyjQw0UjfF+Jrlh6iu5FWD3Fo0oXNNKNfWMJhMmBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQviUSfAdJk YJaAlfzQz6q7eKBmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsiW9oFktVPzI6hjS2b07n6nEnix/VaU47nUhRtloJq3YTNs3t0KXzRb eVcZbDBcTWLFVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNuW3bv1nPfn3AWXq7M22DtZ0 Dg9K+vwGh2YhLXUzLTJYs7W549ydvqZDiFMXDyPJeOLAZaGSgN5mw+PlGXM5gorozswVgmo2tH4W 8yU3FuMqXnVen1aQKsKCHDSTAtBaKHVebqCfCHZ16fGIDXJ+FNM8CVsONrMJuGzuoGnKTKcyyDl+ Iey4xwZiQVVdRpyDl8axOrG/UD1Qlecr4/jiv/qf3MLbn7l3g+Lh7r9C5nLM5w5EnMvejU8iZPQY 1HEgdUy2ZS50wJ+lQ+LaxBNJUp6t2ykfuEOAy+YBuZa3mFPXkVWClPVvbW5lVyQanRxw5p2JYH/6 BohvTRmOq56pXi2xVeaE7wHMAOKzNxZH1vP9C0T1BLTNamueI0y1oJZKcQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 09 Jan 2019 06:13:17 -0000 On 1/8/2019 10:38 AM, JORDI PALET MARTINEZ wrote: > The security concerns raised *initially* by Christian were related to t= he use of DHCP for configuring the WAN. At least that was what I understo= od. Then we continued discussing about the LAN, which I agree with you, i= s not a requirement on this document. I may be very confused, because the way I read your draft I assumed that the DHCPv6 S46 option was meant to inform the LAN-side devices of the available and preferred transition services. From what you are telling me, the S46 option is actually provided by the WAN side DHCPv6 server, of which the CPE is a client. That would be the preferred way for an ISP to configure the customer premise device. If the DHCPv6 option is only used on the WAN side, then I agree with Barbara and you that solutions like DHCP Guard or 802.1x are not relevant. There is no need for the proposed paragraph starting with "considering that" and ending with "scope of this document". On the other hand, if I was that much confused, others will be too. I might be useful to drop a line in section 3.2 explain in layman terms how the S46 option is used. -- Christian Huitema From nobody Wed Jan 9 01:30: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 24D7E130DE5; Wed, 9 Jan 2019 01:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 YraCy6E0kY18; Wed, 9 Jan 2019 01:30:15 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A38A130DF7; Wed, 9 Jan 2019 01:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547026211; x=1547631011; 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=4xpbfllqRSg9ZRMU44cNj5VTyQxBBab8rNKozOu/XKU=; b=t6QABCR+GAFkV HW7g5cQcFEzPXxPoTR8RzkqguJo10rlES9LQw2xV6S5EkuO+HsTRCcpUhrxIUKMz QR2cUKj+77K/ZXci2lJsU42WNcCcpublYoEkmWQZ77K+ifD9V/xCgYOUpPuHpWte 3ZOFYIdyUZSwgR+3sPMiqWDybHRfmQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 09 Jan 2019 10:30:11 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 09 Jan 2019 10:30:11 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006102941.msg; Wed, 09 Jan 2019 10:30:10 +0100 X-MDRemoteIP: 2001:470:1f09:495:4069:342c:af81:26bf X-MDHelo: [10.10.10.140] X-MDArrival-Date: Wed, 09 Jan 2019 10:30:10 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=191216c492=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 09 Jan 2019 10:30:06 +0100 From: JORDI PALET MARTINEZ To: Suresh Krishnan , The IESG CC: , , Message-ID: Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) References: <154700897323.25519.3473287235255788469.idtracker@ietfa.amsl.com> In-Reply-To: <154700897323.25519.3473287235255788469.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] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) 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, 09 Jan 2019 09:30:27 -0000 Hi Suresh, You can implement RFC8115 even if there is no multicast support. We were considering updating RFC8026 to support 464XLAT (which impacts on e= xisting implementations). Then thru the WG discussion, and thanks to the in= puts of a Med, co-author of both (RFC8026 and RFC8115), we discovered that = we can use this alternative (with zeroed ASM_mPrefix64 and SSM_mPrefix64). = This choice doesn't impact on existing implementations. You can probably better understand this change if you look at v02 (search f= or RFC8026 and the IANA section, and compare with the actual version 12): https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/02/?in= clude_text=3D1 This avoids a new DHCPv6 option for the NAT64 prefix discovery, which faile= d in previous INT-AREA attempts: https://tools.ietf.org/html/draft-li-intarea-nat64-prefix-dhcp-option-01 The background is that we need to make sure that: 1) ISP has several choices to offer the NAT64 prefix. 2) They work even if the user changes the DNS servers. 3) The ISP is able to control the priority of the transition mechanism bein= g used. One more consideration, is that in general the CEs considered by this docum= ent, already have multicast support (even if is not needed for implementing= RFC8115), as they are becoming more frequently used in services including = IPTV support. So, in summary, implementing or not multicast support, is not related to th= e implementation of RFC8115 (just a simple DHCPv6 option) which is used her= e for discovering the NAT64 prefix and allowing the prioritization of the t= ransition mechanisms, avoiding updating other IETF documents and waiting fo= r the IETF to approve a new standard DHCPv6 option specific for the NAT64. Please, let me know if this clarifies your discuss, or do you need some mor= e info. Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Suresh Krishnan Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 5:43 Para: The IESG CC: , = , Asunto: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ip= v4aas-12: (with DISCUSS) Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: Discuss =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-transition-ipv4aas/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 * Section 3.2.1. =20 I do not see why the use of RFC8115 (464XLAT-6) is being mandated for t= he use of 464XLAT. What is the intent of such a mandate? Especially, since the uPrefix64 is used for address synthesis for SSM for IPv4 *sources* in t= he IPv6 domain. Given that IPv4 multicast support itself is only conditional in= Section 4, I do not see a need at all for this MUST requirement. Can you please= clarify? =20 =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 Wed Jan 9 01: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 0BC29130DD3 for ; Wed, 9 Jan 2019 01:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=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 M5GZetbc4GoI for ; Wed, 9 Jan 2019 01:54:42 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 95B57130DCC for ; Wed, 9 Jan 2019 01:54:39 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id m62so10783651ith.5 for ; Wed, 09 Jan 2019 01:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WOSRYjDp8DSrJX2BDWlvhkP1ijv2TUhGYPIoCy6Gm50=; b=Dg1nzAf38fl7bGMDhphcYeYHBihRckWf4Hdtgo8sy86wjQuedLS1fCrl7NJeUezi/z ABq7GKO+17YeUN79+CmDXqmp93YV/HRcBwT2VxZUFZrw4ZmE2IEhqKAAR6hSynXs9/j+ T5c6DrccXgeqwgDGfgPyrLcjJQKGQUpZOewU8ST6dd4OydZl8RMItzm/owffPYIENm0v 2Fqlx61qqoqieVWNC1SUzKuTODRXfqlYfKhIrYNr7tUdocAAWi22sQBMwFBhmU2dKolS ps37dxOny6eIjGAkk+OgwI4cFTw2Mt4trsNjRmIPu2ixCJS6wzOSyswWcV/L/V4UCBUa x1uQ== 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=WOSRYjDp8DSrJX2BDWlvhkP1ijv2TUhGYPIoCy6Gm50=; b=PJpmmnWRM0V0TmvSWr+z4DJjLki93UtU0Amr4CI69A3IJPcKYyJsCOc3TlpcBtOzsA 3d5wV2OM8BEYtp0oqnKSUnJiWDst/G1zG8QyePQafKPtDmE8g+qDC6qYtlq24AuNM6uM rAtGn5SCKyLu2K3ZF2uUQztJMEf4hbn4KzpWhQFr1dL5PSKzlvRSTVmBlRjzz6ouvNXC PujIWbszq5ddg2LW3GZ+RCXWzHyQGyQ9xQtCCOvtNQ/NDD5cnbie0/KgcOYIKJ/h4nm1 gsX+03DG5ZCXsYdceeOVs0bs9lv9GD+yYPvdnOWgh5ZQSaKEHQRJxEfc35DA5/EP3ZpO 2+Yg== X-Gm-Message-State: AJcUukfbweXkG+NC0oQoX8JD7cRxPBnr9dZRLFfZjBCQR3xyd3PdxhJ9 LshME+hFNWj7fYaw07U0SysCj+tjnjv50aswaH0hsA== X-Google-Smtp-Source: ALg8bN6GlFmI36gWvZ7MJdTjd1dOshHMhQNolTXqVgqIGOr1mQ2VYu2/pzG6x0AdtTyYm3ZRnaM80tuSF0qEE84wBaQ= X-Received: by 2002:a05:660c:1c4:: with SMTP id s4mr3567405itk.24.1547027678373; Wed, 09 Jan 2019 01:54:38 -0800 (PST) MIME-Version: 1.0 References: <154700897323.25519.3473287235255788469.idtracker@ietfa.amsl.com> In-Reply-To: From: Lorenzo Colitti Date: Wed, 9 Jan 2019 18:54:26 +0900 Message-ID: To: JORDI PALET MARTINEZ Cc: Suresh Krishnan , The IESG , draft-ietf-v6ops-transition-ipv4aas@ietf.org, v6ops-chairs@ietf.org, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="0000000000003aa6f4057f0373a8" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) 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, 09 Jan 2019 09:54:45 -0000 --0000000000003aa6f4057f0373a8 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ wrote: > So, in summary, implementing or not multicast support, is not related to > the implementation of RFC8115 (just a simple DHCPv6 option) which is used > here for discovering the NAT64 prefix and allowing the prioritization of > the transition mechanisms, avoiding updating other IETF documents and > waiting for the IETF to approve a new standard DHCPv6 option specific for > the NAT64. > Jordi: per my recollection, IIRC the reason there is no DHCPv6 option to specify the NAT64 prefix is that there was no consensus to define a way to provision the NAT64 prefix via DHCPv6. (In fact, I think I remember you presenting such an option a few IETFs ago and receiving pretty negative opinions on it from the mike line.) If that's the case, then it's not appropriate to ignore that lack of consensus and essentially define such an option anyway. It's not even clear to me how an informational document (which this is) can take RFC 8115 (which is a standards track document) and redefine the uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines uPrefix64 as not representing standard unicast addresses: uPrefix64: this field identifies the IPv6 unicast prefix to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. Standards track documents have precedence over informational documents, right? If so, then even if this informational document is published as is, the text will effectively be a no-op because it contradicts RFC 8115. --0000000000003aa6f4057f0373a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 9, 2019 at 6= :31 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:
So, in summary, implementing or not multicast support, is not related = to the implementation of RFC8115 (just a simple DHCPv6 option) which is use= d here for discovering the NAT64 prefix and allowing the prioritization of = the transition mechanisms, avoiding updating other IETF documents and waiti= ng for the IETF to approve a new standard DHCPv6 option specific for the NA= T64.

Jordi: per my recollection, IIRC t= he reason there is no DHCPv6 option to specify the NAT64 prefix is that the= re was no consensus to define a way to provision the NAT64 prefix via DHCPv= 6. (In fact, I think I remember you presenting such an option a few IETFs a= go and receiving pretty negative opinions on it from the mike line.) If tha= t's the case, then it's not appropriate to ignore that lack of cons= ensus and essentially define such an option anyway.

It's not even clear to me how an informational document (which this i= s) can take RFC 8115 (which is a standards track document) and redefine the= uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines uPrefix= 64 as not representing standard unicast addresses:

=C2=A0 =C2=A0uPrefix64:=C2=A0 this field identifies the IPv6 unicast prefi= x to be used
=C2=A0 =C2=A0 =C2=A0 in SSM mode for constructing th= e IPv4-embedded IPv6 addresses
=C2=A0 =C2=A0 =C2=A0 representing = the IPv4 multicast sources in the IPv6 domain.

Sta= ndards track documents have precedence over informational documents, right?= If so, then even if this informational document is published as is, the te= xt will effectively be a no-op because it contradicts RFC 8115.
=
--0000000000003aa6f4057f0373a8-- From nobody Wed Jan 9 02: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 5757F130DC7; Wed, 9 Jan 2019 02:00:49 -0800 (PST) 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, MIME_QP_LONG_LINE=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 SH21frN-N973; Wed, 9 Jan 2019 02:00:46 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E75E130DC1; Wed, 9 Jan 2019 02:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547028042; x=1547632842; 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=O/vx57nzBvAhV+STNBXGsG ScS+qwuIm9XmwbbGaOhvs=; b=du92qiYsbnt/IO3NwsHsUboczZI9rsY3yvu45f sa1bXAxLyq6UDALLVZxdYqQtQf1dMsjbkpueiDXSFPYyHOLPSdkms7LviTXnetmR Kg29FdJ1MMUs18B4eaDJegyoj07NE91DQ73WVQ9gca3YhlRdOD6wH/Lxvymm7pdR q1EDE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:00:42 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:00:41 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006102986.msg; Wed, 09 Jan 2019 11:00:40 +0100 X-MDRemoteIP: 2001:470:1f09:495:4069:342c:af81:26bf X-MDHelo: [10.10.10.140] X-MDArrival-Date: Wed, 09 Jan 2019 11:00:40 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=191216c492=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 09 Jan 2019 11:00:39 +0100 From: JORDI PALET MARTINEZ To: Lorenzo Colitti , JORDI PALET MARTINEZ CC: "v6ops@ietf.org WG" , , , Suresh Krishnan , The IESG Message-ID: Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) References: <154700897323.25519.3473287235255788469.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3629876439_747940606" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) 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, 09 Jan 2019 10:00:50 -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_3629876439_747940606 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Lorenzo, =20 Yes, I recall that very well. The only objections where from you and from D= avid. =20 We are using a format that is not defined in RFC8115 for something else. It= is a trick, right, but is not contradicting neither changing any standard,= because the configuration of the two zeroed fields. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 10:55 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org WG" , , , Suresh Krishnan = , The IESG Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transitio= n-ipv4aas-12: (with DISCUSS) =20 On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ wrote: So, in summary, implementing or not multicast support, is not related to th= e implementation of RFC8115 (just a simple DHCPv6 option) which is used her= e for discovering the NAT64 prefix and allowing the prioritization of the t= ransition mechanisms, avoiding updating other IETF documents and waiting fo= r the IETF to approve a new standard DHCPv6 option specific for the NAT64. =20 Jordi: per my recollection, IIRC the reason there is no DHCPv6 option to sp= ecify the NAT64 prefix is that there was no consensus to define a way to pr= ovision the NAT64 prefix via DHCPv6. (In fact, I think I remember you prese= nting such an option a few IETFs ago and receiving pretty negative opinions= on it from the mike line.) If that's the case, then it's not appropriate t= o ignore that lack of consensus and essentially define such an option anywa= y. =20 It's not even clear to me how an informational document (which this is) can= take RFC 8115 (which is a standards track document) and redefine the uPref= ix64 field to mean a unicast prefix. RFC 8115 clearly defines uPrefix64 as = not representing standard unicast addresses: =20 uPrefix64: this field identifies the IPv6 unicast prefix to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. =20 Standards track documents have precedence over informational documents, rig= ht? If so, then even if this informational document is published as is, the= text will effectively be a no-op because it contradicts RFC 8115. _______________________________________________ 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_3629876439_747940606 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Lorenzo,

 

Yes, I recall t= hat very well. The only objections where from you and from David.

 

We are using a format that is not defined in RFC8115 for something else.= It is a trick, right, but is not contradicting neither changing any standa= rd, because the configuration of the two zeroed fields.


Regards,

Jordi

 

<= /div>

 

 

De: v6ops <v6ops-bounces@ietf.org&g= t; en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org&g= t;
Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 10:55
Para: <= /b>JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org&g= t;
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>, <= draft-ietf-v6ops-transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.org= >, Suresh Krishnan <suresh@kaloom.com>, The IESG <iesg@ietf.org= >
Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-= v6ops-transition-ipv4aas-12: (with DISCUSS)

 

On Wed,= Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org&= gt; wrote:

So, in summa= ry, implementing or not multicast support, is not related to the implementa= tion of RFC8115 (just a simple DHCPv6 option) which is used here for discov= ering the NAT64 prefix and allowing the prioritization of the transition me= chanisms, avoiding updating other IETF documents and waiting for the IETF t= o approve a new standard DHCPv6 option specific for the NAT64.

=  

Jordi: per my recollection, IIRC the reason there is no DHCPv6 option to = specify the NAT64 prefix is that there was no consensus to define a way to = provision the NAT64 prefix via DHCPv6. (In fact, I think I remember you pre= senting such an option a few IETFs ago and receiving pretty negative opinio= ns on it from the mike line.) If that's the case, then it's not appropriate= to ignore that lack of consensus and essentially define such an option any= way.

 

It's not even clear to me how an informational document (which this is) can tak= e RFC 8115 (which is a standards track document) and redefine the uPrefix64= field to mean a unicast prefix. RFC 8115 clearly defines uPrefix64 as not = representing standard unicast addresses:

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>   uPrefix64:&nb= sp; this field identifies the IPv6 unicast prefix to be used

=

    =   in SSM mode for constructing the IPv4-embedded IPv6 addresses

 =     representing the IPv4 multicast sources in the IPv6 domain.<= o:p>

=  

Standards track documents have precedence over informational documen= ts, right? If so, then even if this informational document is published as = is, the text will effectively be a no-op because it contradicts RFC 8115.

_______________________________________________ v6ops mailing l= ist v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops <= /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_3629876439_747940606-- From nobody Wed Jan 9 02: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 13147130DCC for ; Wed, 9 Jan 2019 02:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=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 QKwgh1cvjuKE for ; Wed, 9 Jan 2019 02:07:10 -0800 (PST) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 637B4128766 for ; Wed, 9 Jan 2019 02:07:10 -0800 (PST) Received: by mail-io1-xd44.google.com with SMTP id g8so5579791iok.4 for ; Wed, 09 Jan 2019 02:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=66zJMDuSvF+4ffvvbIAU40L/kEW3Wze7kSmF3w1ZFIo=; b=TKN7u7MZghjQSNWt6IZPqd+UmajhqivHxh+C3Fxo/854IW3zp9dyFmaVMu12NFEF+k eJyAg7G3JJ3hHnAjURMLgXqHJMJTDfzNJuSS4OiyJrlXMkeCDEVZPcwuadXo07sjCph5 U3OVSuIbIoBbAWZFroQ6m3tefFa3FNDTQ9UJxznoRtKs6fAdivEdq2OE8zgaY2MrkV8S GtaNEh47vzcNc7/fcguPPLWOBnBAPaBK+4XXJsJShaEMGQbnuQH6NgYFlKxT3zjXU0XG W7XT5SCGJGoHddueBmrcbpnteIYmTnI7qD2P2KFy6jWgtrFRfeomz704Rl9Ry0Cwbdfg yBFg== 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=66zJMDuSvF+4ffvvbIAU40L/kEW3Wze7kSmF3w1ZFIo=; b=qR/YGlrXFTHw21amJCP56C+AbgMPI8Db3qSKVPZn4YAcEp8dUoiVI7UUczhncLybK0 uDduejsyHhgEpMYzhJ91wYwch3A2bfxuqoA49OtnrMBvcuSmml9AxPDg5YPQTGhiW9bF J+cTdrSL5DVahnhUvL636TyoxnyHT5zmksTyGN1J4vq0757iitXyt5R/l8b+t6D7ozgk jO3Z8AANzgKY7TdrQJgpX5/PXvlY7qf8BXFuLAz+fspT81Zh5Rcs2NxFQJ97hzlBBTxS TM2z7bpOya7GnoCzI0oNuIWB5HgyJFszg04fjxahMBfplJOjkpzQV7fJHN8UhBuYBuUF PxmA== X-Gm-Message-State: AJcUukceIuJs2O25xr4xhrvwrzQuq/0O5FBflPc5i4+TeUjVJySN/8AP MRxaZO6kv0dbdSFiHXmZP2H7sbRJ73mwdWFjEnnHrg== X-Google-Smtp-Source: ALg8bN72jD1Tj4eo+AxO2rHMSmeEdUENpD3TXdZc5gMHBKW8JxLSttO5LBp4kBMC/C8q8QErOcbPxAFenck26x3iXz8= X-Received: by 2002:a5d:959a:: with SMTP id a26mr3417641ioo.278.1547028429207; Wed, 09 Jan 2019 02:07:09 -0800 (PST) MIME-Version: 1.0 References: <154700897323.25519.3473287235255788469.idtracker@ietfa.amsl.com> In-Reply-To: From: Lorenzo Colitti Date: Wed, 9 Jan 2019 19:06:58 +0900 Message-ID: To: JORDI PALET MARTINEZ Cc: Lorenzo Colitti , The IESG , "v6ops@ietf.org WG" , v6ops-chairs@ietf.org, draft-ietf-v6ops-transition-ipv4aas@ietf.org, Suresh Krishnan Content-Type: multipart/alternative; boundary="000000000000fb6e5c057f039f69" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) 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, 09 Jan 2019 10:07:14 -0000 --000000000000fb6e5c057f039f69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It *is* contradicting the standard. The standard says that the uPrefix64 is "to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain". This document says that it should be used as a unicast NAT64 prefix. On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ wrote: > Hi Lorenzo, > > > > Yes, I recall that very well. The only objections where from you and from > David. > > > > We are using a format that is not defined in RFC8115 for something else. > It is a trick, right, but is not contradicting neither changing any > standard, because the configuration of the two zeroed fields. > > > Regards, > > Jordi > > > > > > > > *De: *v6ops en nombre de Lorenzo Colitti > > *Fecha: *mi=C3=A9rcoles, 9 de enero de 2019, 10:55 > *Para: *JORDI PALET MARTINEZ > *CC: *"v6ops@ietf.org WG" , < > draft-ietf-v6ops-transition-ipv4aas@ietf.org>, , > Suresh Krishnan , The IESG > *Asunto: *Re: [v6ops] Suresh Krishnan's Discuss on > draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) > > > > On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ 40consulintel.es@dmarc.ietf.org> wrote: > > So, in summary, implementing or not multicast support, is not related to > the implementation of RFC8115 (just a simple DHCPv6 option) which is used > here for discovering the NAT64 prefix and allowing the prioritization of > the transition mechanisms, avoiding updating other IETF documents and > waiting for the IETF to approve a new standard DHCPv6 option specific for > the NAT64. > > > > Jordi: per my recollection, IIRC the reason there is no DHCPv6 option to > specify the NAT64 prefix is that there was no consensus to define a way t= o > provision the NAT64 prefix via DHCPv6. (In fact, I think I remember you > presenting such an option a few IETFs ago and receiving pretty negative > opinions on it from the mike line.) If that's the case, then it's not > appropriate to ignore that lack of consensus and essentially define such = an > option anyway. > > > > It's not even clear to me how an informational document (which this is) > can take RFC 8115 (which is a standards track document) and redefine the > uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines > uPrefix64 as not representing standard unicast addresses: > > > > uPrefix64: this field identifies the IPv6 unicast prefix to be used > > in SSM mode for constructing the IPv4-embedded IPv6 addresses > > representing the IPv4 multicast sources in the IPv6 domain. > > > > Standards track documents have precedence over informational documents, > right? If so, then even if this informational document is published as is= , > the text will effectively be a no-op because it contradicts RFC 8115. > > _______________________________________________ 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 > 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. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000fb6e5c057f039f69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It *is* contradicting the standard. The s= tandard says that the uPrefix64 is "to be used in SSM mode for constru= cting the IPv4-embedded IPv6 addresses representing the IPv4 multicast sour= ces in the IPv6 domain". This document says that it should be used as = a unicast NAT64 prefix.

On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ <jordi.pale= t=3D40consulintel.es@dma= rc.ietf.org> wrote:

Hi Lorenzo,

=C2=A0

Yes, I recall that very well. The only= objections where from you and from David.

=C2=A0<= u>

We are using a format that is not defined in RFC8115 for somethi= ng else. It is a trick, right, but is not contradicting neither changing an= y standard, because the configuration of the two zeroed fields.


Regards,

Jordi

=C2=A0

=C2=A0=

=C2=A0

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti <lore= nzo=3D40go= ogle.com@dmarc.ietf.org>
Fecha: mi=C3=A9rcoles, 9 de enero= de 2019, 10:55
Para: JORDI PALET MARTINEZ <jordi.palet=3D40consulin= tel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>, <draf= t-ietf-v6ops-transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.org>, Suresh= Krishnan <suresh= @kaloom.com>, The IESG <iesg@ietf.org>
Asunto: Re: [v6ops] Suresh Kris= hnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS= )

=C2=A0

On Wed, Jan 9, 2019 at 6:31 PM JORDI PA= LET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:<= /u>

So, in summary, implementing or not multicast supp= ort, is not related to the implementation of RFC8115 (just a simple DHCPv6 = option) which is used here for discovering the NAT64 prefix and allowing th= e prioritization of the transition mechanisms, avoiding updating other IETF= documents and waiting for the IETF to approve a new standard DHCPv6 option= specific for the NAT64.

=C2=A0

Jordi: per my recollection= , IIRC the reason there is no DHCPv6 option to specify the NAT64 prefix is = that there was no consensus to define a way to provision the NAT64 prefix v= ia DHCPv6. (In fact, I think I remember you presenting such an option a few= IETFs ago and receiving pretty negative opinions on it from the mike line.= ) If that's the case, then it's not appropriate to ignore that lack= of consensus and essentially define such an option anyway.

=C2= =A0

It's not even clear to me how an informational document (which this i= s) can take RFC 8115 (which is a standards track document) and redefine the= uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines uPrefix= 64 as not representing standard unicast addresses:

<= div>

=C2=A0

=C2=A0 = =C2=A0uPrefix64:=C2=A0 this field identifies the IPv6 unicast prefix to be = used

=C2=A0 =C2=A0 =C2=A0 in SSM mode for constructing the IPv4-embedd= ed IPv6 addresses

=C2=A0 =C2=A0 =C2=A0 representing the IPv4 multicas= t sources in the IPv6 domain.

=C2=A0

Standards track documents ha= ve precedence over informational documents, right? If so, then even if this= informational document is published as is, the text will effectively be a = no-op because it contradicts RFC 8115.

<= /div>

__________________= _____________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/li= stinfo/v6ops


******************************= ****************
IPv4 is over
Are you ready for the new Internet ?
http://www.thei= pv6company.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@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000fb6e5c057f039f69-- From nobody Wed Jan 9 02:10: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 CA9D1129B88; Wed, 9 Jan 2019 02:09:52 -0800 (PST) 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, MIME_QP_LONG_LINE=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 qnWPTS5LfOv8; Wed, 9 Jan 2019 02:09:49 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC14A128766; Wed, 9 Jan 2019 02:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547028587; x=1547633387; 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=VtxPG1QocJpXFnduShT4zJ s0d+6mwwoXyWd4huSXb5o=; b=oMK0718LH9H8TPBDsApTk7AvROUbBtqg0a0jWY 6G6Q6ZsnhRWY4LLenwIa13yf6+I8dGc7QIeL8AVu3hPqz+7IA5Oe1pKsboPUgqjf 6//MMvYeqdIcJkS3UkwOWKYhMQgyeUo6MTv0Y5ijbueYJWIlUk43em3XkLdr8nQ3 JE6fY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:09:47 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:09:46 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006103005.msg; Wed, 09 Jan 2019 11:09:45 +0100 X-MDRemoteIP: 2001:470:1f09:495:4069:342c:af81:26bf X-MDHelo: [10.10.10.140] X-MDArrival-Date: Wed, 09 Jan 2019 11:09:45 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=191216c492=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 09 Jan 2019 11:09:44 +0100 From: JORDI PALET MARTINEZ To: Lorenzo Colitti , JORDI PALET MARTINEZ CC: "v6ops@ietf.org WG" , , , The IESG , Suresh Krishnan Message-ID: Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) References: <154700897323.25519.3473287235255788469.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3629876984_1427299695" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) 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, 09 Jan 2019 10:09:53 -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_3629876984_1427299695 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Only if the other two fields are zeroed, which is a case not defined in the= standard. At least that=E2=80=99s my understanding. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 11:08 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org WG" , , , Lorenzo Colitti , The IESG , Suresh Krishnan Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transitio= n-ipv4aas-12: (with DISCUSS) =20 It *is* contradicting the standard. The standard says that the uPrefix64 is= "to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses = representing the IPv4 multicast sources in the IPv6 domain". This document = says that it should be used as a unicast NAT64 prefix. =20 On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ wrote: Hi Lorenzo, =20 Yes, I recall that very well. The only objections where from you and from D= avid. =20 We are using a format that is not defined in RFC8115 for something else. It= is a trick, right, but is not contradicting neither changing any standard,= because the configuration of the two zeroed fields. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 10:55 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org WG" , , , Suresh Krishnan = , The IESG Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transitio= n-ipv4aas-12: (with DISCUSS) =20 On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ wrote: So, in summary, implementing or not multicast support, is not related to th= e implementation of RFC8115 (just a simple DHCPv6 option) which is used her= e for discovering the NAT64 prefix and allowing the prioritization of the t= ransition mechanisms, avoiding updating other IETF documents and waiting fo= r the IETF to approve a new standard DHCPv6 option specific for the NAT64. =20 Jordi: per my recollection, IIRC the reason there is no DHCPv6 option to sp= ecify the NAT64 prefix is that there was no consensus to define a way to pr= ovision the NAT64 prefix via DHCPv6. (In fact, I think I remember you prese= nting such an option a few IETFs ago and receiving pretty negative opinions= on it from the mike line.) If that's the case, then it's not appropriate t= o ignore that lack of consensus and essentially define such an option anywa= y. =20 It's not even clear to me how an informational document (which this is) can= take RFC 8115 (which is a standards track document) and redefine the uPref= ix64 field to mean a unicast prefix. RFC 8115 clearly defines uPrefix64 as = not representing standard unicast addresses: =20 uPrefix64: this field identifies the IPv6 unicast prefix to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. =20 Standards track documents have precedence over informational documents, rig= ht? If so, then even if this informational document is published as is, the= text will effectively be a no-op because it contradicts RFC 8115. _______________________________________________ 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@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_3629876984_1427299695 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Only if the other two fields are zeroed, whi= ch is a case not defined in the standard. At least that=E2=80=99s my unders= tanding.


Regards,

Jordi

=  

 

 

De: v6ops= <v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=3D= 40google.com@dmarc.ietf.org>
Fecha: mi=C3=A9rcoles, 9 de enero= de 2019, 11:08
Para: JORDI PALET MARTINEZ <jordi.palet=3D40co= nsulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org WG"= <v6ops@ietf.org>, <v6ops-chairs@ietf.org>, <draft-ietf-v6op= s-transition-ipv4aas@ietf.org>, Lorenzo Colitti <lorenzo=3D40google.c= om@dmarc.ietf.org>, The IESG <iesg@ietf.org>, Suresh Krishnan <= suresh@kaloom.com>
Asunto: Re: [v6ops] Suresh Krishnan's Discu= ss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)

&n= bsp;

It *is* contradicting the standard. The standard says that the uPrefix= 64 is "to be used in SSM mode for constructing the IPv4-embedded IPv6 = addresses representing the IPv4 multicast sources in the IPv6 domain".= This document says that it should be used as a unicast NAT64 prefix.<= /o:p>

 

On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf= .org> wrote:

H= i Lorenzo,

 

Yes, I recall that = very well. The only objections where from you and from David.

 

We are using a format that is not defined in = RFC8115 for something else. It is a trick, right, but is not contradicting = neither changing any standard, because the configuration of the two zeroed = fields.


Regards,

Jordi

&nb= sp;

 

 

De: v= 6ops <v6ops-= bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmar= c.ietf.org>
Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 10:= 55
Para: JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.= ietf.org>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>, <draft-ietf-v6ops-= transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.org>, Suresh Krishnan <= ;suresh@kaloom.com>, The IESG <ies= g@ietf.org>
Asunto: Re: [v6ops] Suresh Krishnan's Discuss = on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)=

 

On Wed, Jan 9, 2019 at 6:31 PM JORDI PALE= T MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:<= /o:p>

So, in summary,= implementing or not multicast support, is not related to the implementatio= n of RFC8115 (just a simple DHCPv6 option) which is used here for discoveri= ng the NAT64 prefix and allowing the prioritization of the transition mecha= nisms, avoiding updating other IETF documents and waiting for the IETF to a= pprove a new standard DHCPv6 option specific for the NAT64.

<= /blockquote>

 

=

Jordi: per my recollection, IIRC the reason there= is no DHCPv6 option to specify the NAT64 prefix is that there was no conse= nsus to define a way to provision the NAT64 prefix via DHCPv6. (In fact, I = think I remember you presenting such an option a few IETFs ago and receivin= g pretty negative opinions on it from the mike line.) If that's the case, t= hen it's not appropriate to ignore that lack of consensus and essentially d= efine such an option anyway.

 

It's not even clear t= o me how an informational document (which this is) can take RFC 8115 (which= is a standards track document) and redefine the uPrefix64 field to mean a = unicast prefix. RFC 8115 clearly defines uPrefix64 as not representing stan= dard unicast addresses:

=  

   uPre= fix64:  this field identifies the IPv6 unicast prefix to be used<= /o:p>

      in SSM m= ode for constructing the IPv4-embedded IPv6 addresses

<= div>

      representing the IPv4 mu= lticast sources in the IPv6 domain.

 

Stand= ards track documents have precedence over informational documents, right? I= f so, then even if this informational document is published as is, the text= will effectively be a no-op because it contradicts RFC 8115.

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


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

T= his electronic message contains information which may be privileged or conf= idential. The information is intended to be for the exclusive use of the in= dividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if pa= rtially, including attached files, is strictly prohibited and will be consi= dered a criminal offense. If you are not the intended recipient be aware th= at any disclosure, copying, distribution or use of the contents of this inf= ormation, even if partially, including attached files, is strictly prohibit= ed, will be considered a criminal offense, so you must reply to the origina= l sender to inform about this communication and delete it.

_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mail= man/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_3629876984_1427299695-- From nobody Wed Jan 9 02:21: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 BB80612F1AC; Wed, 9 Jan 2019 02:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0uB010-ImgS; Wed, 9 Jan 2019 02:21:15 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A50412008A; Wed, 9 Jan 2019 02:21:15 -0800 (PST) Received: from astfgl.hanazo.no (77.16.55.6.tmi.telenormobil.no [77.16.55.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 2D27CFECBCC8; Wed, 9 Jan 2019 10:21:14 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D0A35C1D195; Wed, 9 Jan 2019 11:21:11 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ole Troan In-Reply-To: Date: Wed, 9 Jan 2019 11:21:11 +0100 Cc: JORDI PALET MARTINEZ , "v6ops@ietf.org WG" , v6ops-chairs@ietf.org, draft-ietf-v6ops-transition-ipv4aas@ietf.org, The IESG , Suresh Krishnan Content-Transfer-Encoding: quoted-printable Message-Id: <751B33D3-09CF-447B-A61A-814CA5260308@employees.org> References: <154700897323.25519.3473287235255788469.idtracker@ietfa.amsl.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) 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, 09 Jan 2019 10:21:18 -0000 > It *is* contradicting the standard. The standard says that the = uPrefix64 is "to be used in SSM mode for constructing the IPv4-embedded = IPv6 addresses representing the IPv4 multicast sources in the IPv6 = domain". This document says that it should be used as a unicast NAT64 = prefix. I must agree with Lorenzo here. This is not the right document to specify a new NAT64 prefix discovery = mechanism. Ole >=20 > On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ = wrote: > Hi Lorenzo, >=20 > =20 >=20 > Yes, I recall that very well. The only objections where from you and = from David. >=20 > =20 >=20 > We are using a format that is not defined in RFC8115 for something = else. It is a trick, right, but is not contradicting neither changing = any standard, because the configuration of the two zeroed fields. >=20 >=20 > Regards, >=20 > Jordi >=20 > =20 >=20 > =20 >=20 > =20 >=20 > De: v6ops en nombre de Lorenzo Colitti = > Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 10:55 > Para: JORDI PALET MARTINEZ = > CC: "v6ops@ietf.org WG" , = , , = Suresh Krishnan , The IESG > Asunto: Re: [v6ops] Suresh Krishnan's Discuss on = draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) >=20 > =20 >=20 > On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ = wrote: >=20 > So, in summary, implementing or not multicast support, is not related = to the implementation of RFC8115 (just a simple DHCPv6 option) which is = used here for discovering the NAT64 prefix and allowing the = prioritization of the transition mechanisms, avoiding updating other = IETF documents and waiting for the IETF to approve a new standard DHCPv6 = option specific for the NAT64. >=20 > =20 >=20 > Jordi: per my recollection, IIRC the reason there is no DHCPv6 option = to specify the NAT64 prefix is that there was no consensus to define a = way to provision the NAT64 prefix via DHCPv6. (In fact, I think I = remember you presenting such an option a few IETFs ago and receiving = pretty negative opinions on it from the mike line.) If that's the case, = then it's not appropriate to ignore that lack of consensus and = essentially define such an option anyway. >=20 > =20 >=20 > It's not even clear to me how an informational document (which this = is) can take RFC 8115 (which is a standards track document) and redefine = the uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines = uPrefix64 as not representing standard unicast addresses: >=20 > =20 >=20 > uPrefix64: this field identifies the IPv6 unicast prefix to be = used >=20 > in SSM mode for constructing the IPv4-embedded IPv6 addresses >=20 > representing the IPv4 multicast sources in the IPv6 domain. >=20 > =20 >=20 > Standards track documents have precedence over informational = documents, right? If so, then even if this informational document is = published as is, the text will effectively be a no-op because it = contradicts RFC 8115. >=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 >=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 9 02:30: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 500D312F1AC; Wed, 9 Jan 2019 02:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 jtr_gUOWMrtU; Wed, 9 Jan 2019 02:30:26 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14DD12F1A2; Wed, 9 Jan 2019 02:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547029824; x=1547634624; 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=vT/XEAgZAZVb0i7qY5c5RVHoIgywp4H58PJGELx2mE8=; b=QHj5p8jFlG+ct AKyIPwvDX2RkZKxJXNm8Ff9r5uqmW2QfytlFAg1EDQrGElbSzyEZyZRtowIFORuB XRlRA6ptB6qcs+8oKMbooWbIwJhgKoOSzCFHQruPbvR4CcKrjoWoHSwnbfEJp0J9 WjkOkhkd5qSf3TzhLJAh4DQ9cntJ2Q= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:30:24 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:30:22 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006103042.msg; Wed, 09 Jan 2019 11:30:20 +0100 X-MDRemoteIP: 2001:470:1f09:495:4069:342c:af81:26bf X-MDHelo: [10.10.10.140] X-MDArrival-Date: Wed, 09 Jan 2019 11:30:20 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=191216c492=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 09 Jan 2019 11:30:17 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , "STARK, BARBARA H" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> <9674e692-41fd-1ef2-c4dc-9c01d4b49cc0@huitema.net> In-Reply-To: <9674e692-41fd-1ef2-c4dc-9c01d4b49cc0@huitema.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 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, 09 Jan 2019 10:30:28 -0000 Hi Christian, No, it was not intended to configure the LANs, just the CE. I think that's clear in the document (abstract, intro), so if you feel that= something else need to be included to make sure that is not misunderstood,= please, let me know. In Section 3.2 I've added this, let me know if you think is now clearer: Note that this document is only configuring the IPv4aaS in the IPv6 Transition CE Router itself, and not forwarding such information to devices attached to the LANs, so the WAN configuration, availability of native IPv4 or IPv4aaS, is transparent for them. Regarding the Security Section, following your points and Barbara suggestio= ns I've this: The IPv6 Transition CE Router must comply with the Security Considerations as stated in [RFC7084], as well as those stated by each transition mechanism implemented by the IPv6 Transition CE Router. As described in [RFC8026] and [RFC8415] Security Consideration sections, there are generic DHCP security issues, which in the case of this document means that malicious nodes may alter the priority of the transition mechanisms. Access network architecture for securing DHCP within the access network is out of scope of this document. Securing DHCP in the LAN is also not in scope. DHCP packets MUST NOT be forwarded between LAN and WAN interfaces of an IPv6 Transition CE router. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de Christian Huitema Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 7:14 Para: JORDI PALET MARTINEZ , "STARK, BARBARA H"= CC: "v6ops@ietf.org" , "ietf@ietf.org" , "se= cdir@ietf.org" Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 =20 On 1/8/2019 10:38 AM, JORDI PALET MARTINEZ wrote: > The security concerns raised *initially* by Christian were related to= the use of DHCP for configuring the WAN. At least that was what I understo= od. Then we continued discussing about the LAN, which I agree with you, is = not a requirement on this document. =20 I may be very confused, because the way I read your draft I assumed tha= t the DHCPv6 S46 option was meant to inform the LAN-side devices of the available and preferred transition services. From what you are telling me, the S46 option is actually provided by the WAN side DHCPv6 server, of which the CPE is a client. That would be the preferred way for an IS= P to configure the customer premise device. =20 If the DHCPv6 option is only used on the WAN side, then I agree with Barbara and you that solutions like DHCP Guard or 802.1x are not relevant. There is no need for the proposed paragraph starting with "considering that" and ending with "scope of this document". =20 On the other hand, if I was that much confused, others will be too. I might be useful to drop a line in section 3.2 explain in layman terms how the S46 option is used. =20 -- Christian Huitema =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 Wed Jan 9 08:32:58 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 E5CDA130EF7; Wed, 9 Jan 2019 08:32:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154705156992.5147.7445961267352437833.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 08:32:49 -0800 Archived-At: Subject: [v6ops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-v6ops-transition-ipv4aas-12=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, 09 Jan 2019 16:32:50 -0000 Mirja KĂźhlewind has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: 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-transition-ipv4aas/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some more processing-related comments: 1) "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, are not used as described in RFC 2119 [RFC2119]." While it is not forbidden to define their own language requirements, I find this really confusing. I've seen that RFC7084 uses the same definition but actually I don't think the usage is really that different. I'd say the keywords are used in a similar fashion in other informational docs. 2) In the abstract: "this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms." Shouldn't this doc maybe actually update RFC7084 then? Otherwise,how is someone reading RFC7084 supposed to know about this RFC as well? From nobody Wed Jan 9 10:06: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 BBC7F130FA3; Wed, 9 Jan 2019 10:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Jpr7QJUooJrF; Wed, 9 Jan 2019 10:06:26 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745D0130F0F; Wed, 9 Jan 2019 10:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547057182; x=1547661982; 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=1ul1YBcaopyamEnUKrIATesxqa469DuJr9w+5HTxUVQ=; b=LbAN2CgYTBPun 3Cj0GgjPRXOIkpcNd5ppArrL8BUekrWFXIMZnGFW9KVwHFW7iKDOU0Jto1UZR7WZ OgRg7+asm9VHLgVb/BsbFlyxfmnBb0BTEN1fCNsvnoF5BOM+7NP2xMDDc2egBQEg hIndREWA7gIP4lMGK+RInkX5SWqOgw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 09 Jan 2019 19:06:22 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 09 Jan 2019 19:06:21 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006103488.msg; Wed, 09 Jan 2019 19:06:21 +0100 X-MDRemoteIP: 2001:470:1f09:495:8138:a806:ea:6435 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Wed, 09 Jan 2019 19:06:21 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=191216c492=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 09 Jan 2019 19:06:16 +0100 From: JORDI PALET MARTINEZ To: Mirja =?UTF-8?B?S8O8aGxld2luZA==?= , The IESG CC: , , Message-ID: <16E5BEC5-AB75-4C31-BA43-03B24DB2DF8B@consulintel.es> Thread-Topic: [v6ops] Mirja =?UTF-8?B?S8O8aGxld2luZCdz?= No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT) References: <154705156992.5147.7445961267352437833.idtracker@ietfa.amsl.com> In-Reply-To: <154705156992.5147.7445961267352437833.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-transition-ipv4aas-12=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, 09 Jan 2019 18:06:29 -0000 Hi Mirja, I'm happy using or not RFC2119, but this work started as an update of RFC70= 84, we just used the same way. I fully agree that basically the intent is t= he same, but this part of the text may explain it: " This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality." Regarding updating RFC7084, as said, it was my original intent, we had very= long debates in the WG about that, and the decision was finally not going = into that direction, because lots of RFI/RFQs are based on RFC7084, etc. Also, the difference is RFC7084 only takes care of "must support IPv6" (any= thing related to transition is optional), and here the intent is to make su= re that new CEs support IPv4aaS. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Mirja K=C3=BChlewind Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 17:33 Para: The IESG CC: , = , Asunto: [v6ops] Mirja K=C3=BChlewind's No Objection on draft-ietf-v6ops-tra= nsition-ipv4aas-12: (with COMMENT) Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: 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-transition-ipv4aas/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 Some more processing-related comments: =20 1) "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, are not used as described in RFC 2119 [RFC2119]." While it is not forbidden to define their own language requirements, I = find this really confusing. I've seen that RFC7084 uses the same definition = but actually I don't think the usage is really that different. I'd say the = keywords are used in a similar fashion in other informational docs. =20 2) In the abstract: "this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms." Shouldn't this doc maybe actually update RFC7084 then? Otherwise,how is= someone reading RFC7084 supposed to know about this RFC as well? =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 Jan 9 13:20:07 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 8ACAB130EAB; Wed, 9 Jan 2019 13:20:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154706880056.5071.13286309675725067813.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 13:20:00 -0800 Archived-At: Subject: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (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, 09 Jan 2019 21:20:01 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: 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-transition-ipv4aas/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm willing to believe that Since it is impossible to know prior to sale which transition mechanism a device will need over its lifetime, IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanisms supported by this document. Service providers who specify feature sets for IPv6 Transition CE Router may specify a different set of features than those included in this document, for example supporting only some of the transition mechanisms enumerated in this document. we can't do better than requiring all IPv6 Transition CE Routers to support all five transition mechanisms listed in this document, but I am wondering if five is hitting a natural law, or if someone is likely to come up with more transition mechanisms (that the existing CE routers won't support because they're already deployed). But I trust the working group is doing its best ... From nobody Wed Jan 9 13:48: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 761AE130FCB; Wed, 9 Jan 2019 13:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 NirLeD35Fjbl; Wed, 9 Jan 2019 13:48:00 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C59712DD85; Wed, 9 Jan 2019 13:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547070477; x=1547675277; 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=d3OEXL1C+Ac8WGnmb7A/2mVVpt5HZ7W369hbUgZUxVs=; b=WBI2L6uIwhDSh Ph1WtwbRIVoZZl2Ul/X5/g/8gsUEfT8GWhX8feNA7i0dJkJC9na1kdO9CiCEScG2 a4SqRBnj5tYepS5Tr3CtoPg5GUEf0jDz7kcElwQlLJIHc8dDFb40+K0z5f848/Fm e3/m9WqOyKFrB65JCh+oReDP5l/9bQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 09 Jan 2019 22:47:57 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 09 Jan 2019 22:47:57 +0100 Received: from [10.10.10.131] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006103745.msg; Wed, 09 Jan 2019 22:47:55 +0100 X-MDRemoteIP: 2001:470:1f09:495:514e:9f61:d043:7ea8 X-MDHelo: [10.10.10.131] X-MDArrival-Date: Wed, 09 Jan 2019 22:47:55 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=191216c492=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 09 Jan 2019 22:47:55 +0100 From: JORDI PALET MARTINEZ To: Spencer Dawkins , The IESG CC: , , Message-ID: <6B5109DF-9D64-47E2-9994-7A9D5B28D8A7@consulintel.es> Thread-Topic: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT) References: <154706880056.5071.13286309675725067813.idtracker@ietfa.amsl.com> In-Reply-To: <154706880056.5071.13286309675725067813.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] Spencer Dawkins' No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (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, 09 Jan 2019 21:48:03 -0000 Hi Spencer, I think the key point is understanding that all those transition mechanisms= share a single data plane, code is already available and there are many "c= ommon" parts among them, etc. Explaining that was the reason for section 7 (Code Considerations) and ther= e are several Open Source implementations (OpenWRT and VPP, for example), a= nd I know there are several vendors already using those for their own "impl= ementations". Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Spencer Dawkins Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 22:20 Para: The IESG CC: , = , Asunto: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-transitio= n-ipv4aas-12: (with COMMENT) Spencer Dawkins has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: 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-transition-ipv4aas/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 I'm willing to believe that =20 Since it is impossible to know prior to sale which transition mechanism a device will need over its lifetime, IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanisms supported by this document. Service providers who specify feature sets for IPv6 Transition CE Router may specify a different set of features than those included in this document, for example supporting only some of the transition mechanisms enumerated in this document. =20 we can't do better than requiring all IPv6 Transition CE Routers to sup= port all five transition mechanisms listed in this document, but I am wondering = if five is hitting a natural law, or if someone is likely to come up with more transition mechanisms (that the existing CE routers won't support becau= se they're already deployed). =20 But I trust the working group is doing its best ... =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 Jan 9 14:05: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 34EC712D4F2; Wed, 9 Jan 2019 14:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHXw2jLUcSFg; Wed, 9 Jan 2019 14:05:31 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 8395C126DBF; Wed, 9 Jan 2019 14:05:31 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id e26so6838645lfc.2; Wed, 09 Jan 2019 14:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IqjdU1V8oKX9hlcrGl6KGx/2GlL164E/ffWCG1cPySU=; b=YrlBC9RS+LU2b2qJDj1mWmD+7uMmdeSljit5DZvX411uEFD3weiot+gVfzAz4TCoAN Y7JVF7cVjsKezLFmwB+A2JykUKOdNJjg5U/rq+WjLM0UZdUOF/dooFlM/iopogWobqJX t5EDMOrVQULRm05dqWti9uaymv2Mu8jEnAFhavd16zGpTE5CbCDyaOdXggRUnTZmO3nV xfw/B0P9j40q93xJ6h/3lTSijbqKsAXPKg8ufIT/FvU3iGDBUAWlfYxncUDP/EGPUFvo FLwe1oBT+p97o5gmw6LjeIcXSjP8fthMmrSwzkdV1uAId8aQnBFtMD4BAHSa5AqmhmQQ yoTQ== 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=IqjdU1V8oKX9hlcrGl6KGx/2GlL164E/ffWCG1cPySU=; b=Ah5TkgmVn+InKAmFTkXAz24t8OKIOIxXDf01acUIHU2M8a4m7pOecGhA13cyC3bOMF e6mZPLH389ciiFDjRAMIr4YCtlsJTcgBE0EfJu+9nbhx0+ixZfANd8Cq2GCu7qfAxLGs uC/k8vfjhSpHonce8I/IGY8GZSgePR0XrduKN/U7djawuBO2KwkYAN6sIaCQUvCJJyKG c3JjuGuSlWgMJgvEbArQmXcwfV/fFWR79GK0eiYTrGfHZtuYcukIpla+mgv8feEsgdU8 Tj7vgIaBKH4GZH1H7xrkmED/8G7dAZ4m2eJ+yVEGfLJUJ1zDqGWnt4vEnMdd8cjUJx8a tn+w== X-Gm-Message-State: AJcUukf+paW0xN/V2vsPRsKAMg4SCaBAMyshkfvG5KfuqqVyGlaIB8nx gX4r3IHeftdtWwZUIDkL9yEo1eEufDnDUoaAs17lZg== X-Google-Smtp-Source: ALg8bN75c3cl4VzoMaEElPJUv2KUMdQUp7olsNOG/jYoWpqrLMAbTNwFPyr6jXTCDm0QAtmLPPTqtej2WCDE04603RI= X-Received: by 2002:a19:a302:: with SMTP id m2mr4732967lfe.108.1547071529514; Wed, 09 Jan 2019 14:05:29 -0800 (PST) MIME-Version: 1.0 References: <154706880056.5071.13286309675725067813.idtracker@ietfa.amsl.com> <6B5109DF-9D64-47E2-9994-7A9D5B28D8A7@consulintel.es> In-Reply-To: <6B5109DF-9D64-47E2-9994-7A9D5B28D8A7@consulintel.es> From: Spencer Dawkins at IETF Date: Wed, 9 Jan 2019 16:05:16 -0600 Message-ID: To: JORDI PALET MARTINEZ Cc: The IESG , draft-ietf-v6ops-transition-ipv4aas@ietf.org, V6ops Chairs , v6ops list Content-Type: multipart/alternative; boundary="000000000000f57d1c057f0da894" Archived-At: Subject: Re: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (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, 09 Jan 2019 22:05:34 -0000 --000000000000f57d1c057f0da894 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Jordi, On Wed, Jan 9, 2019 at 3:47 PM JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi Spencer, > > I think the key point is understanding that all those transition > mechanisms share a single data plane, code is already available and there > are many "common" parts among them, etc. > > Explaining that was the reason for section 7 (Code Considerations) and > there are several Open Source implementations (OpenWRT and VPP, for > example), and I know there are several vendors already using those for > their own "implementations". > Thanks for the background. It's helpful. I noticed another AD mentioning combinatorial complexity in a ballot position on another draft on this telechat, and wish we could could start to push back on mandatory support for multiple mechanisms, but I do remember enough about the history of IPv4/IPv6 transition and coexistence that I'm not surprised this isn't the right draft to start that discussion with! Spencer > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Spencer Dawkins < > spencerdawkins.ietf@gmail.com> > Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 22:20 > Para: The IESG > CC: , , > > Asunto: [v6ops] Spencer Dawkins' No Objection on > draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT) > > Spencer Dawkins has entered the following ballot position for > draft-ietf-v6ops-transition-ipv4aas-12: 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 th= is > 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-transition-ipv4aas/ > > > > ---------------------------------------------------------------------= - > COMMENT: > ---------------------------------------------------------------------= - > > I'm willing to believe that > > Since it is impossible to know prior to sale which transition > mechanism a device will need over its lifetime, IPv6 Transition CE > Router intended for the retail market MUST support all the IPv4aaS > transition mechanisms supported by this document. Service provide= rs > who specify feature sets for IPv6 Transition CE Router may specify= a > different set of features than those included in this document, fo= r > example supporting only some of the transition mechanisms enumerat= ed > in this document. > > we can't do better than requiring all IPv6 Transition CE Routers to > support all > five transition mechanisms listed in this document, but I am wonderin= g > if five > is hitting a natural law, or if someone is likely to come up with mor= e > transition mechanisms (that the existing CE routers won't support > because > they're already deployed). > > But I trust the working group is doing its best ... > > > _______________________________________________ > 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 > 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. > > > > --000000000000f57d1c057f0da894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Jordi,=C2=A0

On Wed, Jan 9, 2019 at 3:47 PM JORDI PALET MAR= TINEZ <jordi.palet@consuli= ntel.es> wrote:
Hi Spencer,

I think the key point is understanding that all those transition mechanisms= share a single data plane, code is already available and there are many &q= uot;common" parts among them, etc.

Explaining that was the reason for section 7 (Code Considerations) and ther= e are several Open Source implementations (OpenWRT and VPP, for example), a= nd I know there are several vendors already using those for their own "= ;implementations".

Thanks for the = background. It's helpful.=C2=A0

I noticed anot= her AD mentioning combinatorial complexity in a ballot position on another = draft on this telechat, and wish we could could start to push back on manda= tory support for multiple mechanisms, but I do remember enough about the hi= story of IPv4/IPv6 transition and coexistence that I'm not surprised th= is isn't the right draft to start that discussion with!

<= /div>
Spencer=C2=A0

Regards,
Jordi



=EF=BB=BF-----Mensaje original-----
De: v6ops <v= 6ops-bounces@ietf.org> en nombre de Spencer Dawkins <spencerdawkins.ietf@= gmail.com>
Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 22:20
Para: The IESG <iesg@= ietf.org>
CC: <draft-ietf-v6ops-transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.= org>, <v6ops@= ietf.org>
Asunto: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-trans= ition-ipv4aas-12: (with COMMENT)

=C2=A0 =C2=A0 Spencer Dawkins has entered the following ballot position for=
=C2=A0 =C2=A0 draft-ietf-v6ops-transition-ipv4aas-12: No Objection

=C2=A0 =C2=A0 When responding, please keep the subject line intact and repl= y to all
=C2=A0 =C2=A0 email addresses included in the To and CC lines. (Feel free t= o cut this
=C2=A0 =C2=A0 introductory paragraph, however.)


=C2=A0 =C2=A0 Please refer to https://www.i= etf.org/iesg/statement/discuss-criteria.html
=C2=A0 =C2=A0 for more information about IESG DISCUSS and COMMENT positions= .


=C2=A0 =C2=A0 The document, along with other ballot positions, can be found= here:
=C2=A0 =C2=A0 https://datatrack= er.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/



=C2=A0 =C2=A0 -------------------------------------------------------------= ---------
=C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 -------------------------------------------------------------= ---------

=C2=A0 =C2=A0 I'm willing to believe that

=C2=A0 =C2=A0 =C2=A0 =C2=A0Since it is impossible to know prior to sale whi= ch transition
=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism a device will need over its lifetime, = IPv6 Transition CE
=C2=A0 =C2=A0 =C2=A0 =C2=A0Router intended for the retail market MUST suppo= rt all the IPv4aaS
=C2=A0 =C2=A0 =C2=A0 =C2=A0transition mechanisms supported by this document= .=C2=A0 Service providers
=C2=A0 =C2=A0 =C2=A0 =C2=A0who specify feature sets for IPv6 Transition CE = Router may specify a
=C2=A0 =C2=A0 =C2=A0 =C2=A0different set of features than those included in= this document, for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example supporting only some of the transition m= echanisms enumerated
=C2=A0 =C2=A0 =C2=A0 =C2=A0in this document.

=C2=A0 =C2=A0 we can't do better than requiring all IPv6 Transition CE = Routers to support all
=C2=A0 =C2=A0 five transition mechanisms listed in this document, but I am = wondering if five
=C2=A0 =C2=A0 is hitting a natural law, or if someone is likely to come up = with more
=C2=A0 =C2=A0 transition mechanisms (that the existing CE routers won't= support because
=C2=A0 =C2=A0 they're already deployed).

=C2=A0 =C2=A0 But I trust the working group is doing its best ...


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




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



--000000000000f57d1c057f0da894-- From nobody Wed Jan 9 14:17:24 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 9563B12D84D; Wed, 9 Jan 2019 14:17:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154707223560.5147.9494634309376362054.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 14:17:15 -0800 Archived-At: Subject: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (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, 09 Jan 2019 22:17:16 -0000 Ben Campbell has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: 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-transition-ipv4aas/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General: I'm curious why this is not a BCP. The shepherd review states that it doesn't recommend practices, but that seems to be me to be exactly what it does. abstract: Does this need to update RFC7084? §1, 2nd paragraph: The paragraph does not parse. §1.1: Is there a reason not to use the updated boilerplate from RFC 8174? §3.2, third paragraph: The paragraph is hard to follow. Please consider breaking into simpler sentences. §3.2.1: "The IPv6 Transition CE Router MUST support CLAT functionality [RFC6877] if intended for the retail market. If 464XLAT is supported, it MUST be implemented according to [RFC6877]." The 2nd MUST seems redundant; we don't generally need to say that a function defined in an RFC MUST be implemented according to that RFC unless there's some reason to expect people might do otherwise. §7: - The entirety of this section is very hard to parse. - "... only integration and testing cost may become a minor issue." I don't think that's a judgement the IETF is in a position to make. It's not all that unusual for integration and testing to be greater costs than coding. §8, 2nd paragraph: Is there any guidance that can be given for mitigating this issue in the context of transition mechanisms? From nobody Wed Jan 9 23:19:11 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 7AE03129A87; Wed, 9 Jan 2019 23:19:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154710474949.4881.472024069770211091.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 23:19:09 -0800 Archived-At: Subject: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (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, 10 Jan 2019 07:19:09 -0000 Adam Roach has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: 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-transition-ipv4aas/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Ben and Mirja's question about the formal relationship between this document and RFC 7084. I also share Ben's confusion about the document's status as not being a BCP -- statements like the following are, by my understanding of the term, specifying practices that are considered to be "best" at the present time: * "The IPv6 Transition CE Router MUST implement a DNS proxy as described in [RFC5625] (DNS Proxy Implementation Guidelines)." * "The IPv6 Transition CE Router MUST support the DHCPv6 S46 priority options described in [RFC8026]." * "The IPv6 Transition CE Router MUST have a GUI, CLI and/or API option to manually enable/disable each of the supported transition mechanisms." If these (and similarly phrased) statements are not recommending best current practices, then I don't understand the purpose of this document. From nobody Thu Jan 10 03:14: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 DD4C5130DC4; Thu, 10 Jan 2019 03:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4xGsmHGeWZ2; Thu, 10 Jan 2019 03:14:01 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5401271FF; Thu, 10 Jan 2019 03:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547118839; x=1547723639; 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=X6sTUaSPx83L7NtiXg04Rx2iQXSAHamEV+e3S7PsvTw=; b=azsaMIcUEosCM wGnbSY3UyI/ZHRP0FK5/l5zx3mExP1J7prkU4abUn7PDEv7hUgUT0BZjMwOQgKX1 jPqISFP1vtOUEgvzUhhADa9czCtRIGP170x8I8ctEQbv9SBMkXDLKZpdMzXA81L8 pdN2oyNQ0JKo/+ZOlI17zzfPnwJEiw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 10 Jan 2019 12:13:59 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 10 Jan 2019 12:13:57 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006104655.msg; Thu, 10 Jan 2019 12:13:56 +0100 X-MDRemoteIP: 2001:470:1f09:495:6d25:fb99:feb6:ac39 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Thu, 10 Jan 2019 12:13:56 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1913f26ae7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 10 Jan 2019 12:13:54 +0100 From: JORDI PALET MARTINEZ To: Ben Campbell , The IESG CC: , , Message-ID: Thread-Topic: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT) References: <154707223560.5147.9494634309376362054.idtracker@ietfa.amsl.com> In-Reply-To: <154707223560.5147.9494634309376362054.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] Ben Campbell's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (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, 10 Jan 2019 11:14:09 -0000 Hi Ben, There has been long discussion in the WG about updating RFC7084. Initially = this document was RFC7084-bis and accepted as WG item (https://datatracker.= ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/), but then it was decided to mak= e it an independent document. Regarding RFC2119/8174 usage, I've already provided in previous comments my= opinion on that. I will be fine to use that boilerplate if this is an issu= e, but we clearly state that it is a special language, following RFC7084, a= s we are trying to make both documents "coherent". I will submit a new version in an hour or so, including the last agreed (in= v6ops) as a result of the security-area review by Christian Huitema for th= e security section changes which I think also resolves your last comment. I'm going to try to take the opportunity to tidy up the sentences that you = commented so they are more "parseable". Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Ben Campbell Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 23:17 Para: The IESG CC: , = , Asunto: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-transition-= ipv4aas-12: (with COMMENT) Ben Campbell has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: 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-transition-ipv4aas/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 General: I'm curious why this is not a BCP. The shepherd review states = that it doesn't recommend practices, but that seems to be me to be exactly what= it does. =20 abstract: Does this need to update RFC7084? =20 =C2=A71, 2nd paragraph: The paragraph does not parse. =20 =C2=A71.1: Is there a reason not to use the updated boilerplate from RF= C 8174? =20 =C2=A73.2, third paragraph: The paragraph is hard to follow. Please con= sider breaking into simpler sentences. =20 =C2=A73.2.1: "The IPv6 Transition CE Router MUST support CLAT functiona= lity [RFC6877] if intended for the retail market. If 464XLAT is supported, it MUST be implemented according to [RFC6877]." The 2nd MUST seems redundant; we don't generally need to say that a fun= ction defined in an RFC MUST be implemented according to that RFC unless ther= e's some reason to expect people might do otherwise. =20 =C2=A77: - The entirety of this section is very hard to parse. =20 - "... only integration and testing cost may become a minor issue." I don't think that's a judgement the IETF is in a position to make. It'= s not all that unusual for integration and testing to be greater costs than c= oding. =20 =C2=A78, 2nd paragraph: Is there any guidance that can be given for mit= igating this issue in the context of transition mechanisms? =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 Jan 10 03:24: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 7B86F130E13; Thu, 10 Jan 2019 03:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obloHY9tKQz2; Thu, 10 Jan 2019 03:24:31 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F17130E0E; Thu, 10 Jan 2019 03:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547119467; x=1547724267; 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=xKtF/jQoyKntFwJ0xagn2kWbs8HIrqOvoOp38Vr0HFw=; b=A0oqrW1c+pJEZ 6fUSfGWQIrL21yZJsZY0OIiJRVxXWRTRmF9FB+LfWDusG71+a2iSgKWkgBGjWx41 y37Cgffe++m+VdppXJAyYldGWjcTjPPBreDvMfZgHyPOaESSnbUnWNr6azoQUDK8 7gV7Rky5XhvJ/rDzLG2fBEFo5pbveU= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 10 Jan 2019 12:24:27 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 10 Jan 2019 12:24:27 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006104666.msg; Thu, 10 Jan 2019 12:24:26 +0100 X-MDRemoteIP: 2001:470:1f09:495:6d25:fb99:feb6:ac39 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Thu, 10 Jan 2019 12:24:26 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1913f26ae7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 10 Jan 2019 12:24:24 +0100 From: JORDI PALET MARTINEZ To: Adam Roach , The IESG CC: , , Message-ID: <355A2033-7CF0-4B4F-B9AA-22D81D8C8FF3@consulintel.es> Thread-Topic: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT) References: <154710474949.4881.472024069770211091.idtracker@ietfa.amsl.com> In-Reply-To: <154710474949.4881.472024069770211091.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] Adam Roach's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (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, 10 Jan 2019 11:24:33 -0000 Hi Adam, I just replied to Ben comments, and I already did to Mirja, so don't think = I can add anything else on that point. I missed the BCP point on the response to Ben, so here is it. My understanding is that BCP is a "current practices". Some of the consider= ations in the document are new. No new protocols (that's why is info), but = new requirements to put "together" in a CE existing protocols and how to ta= ke advantage of "coordinating" them, so the operator can deploy IPv4aaS, or= even change from dual-stack to IPv4aaS, or one IPv4aaS technology to anoth= er or have different customers with different IPv4aaS technologies, etc. This means that, for clarity, we have text that may seem redundant if you a= lready know all the details of each of the IPv4aaS technologies, but it mak= es very easy for an operator to have a single document to "follow the path"= in a coherent way. This is part of the scope of v6ops chapter, providing guidance for the depl= oyment of and operation of new and existing IPv6 networks. Let me know if this clarify your point on this. Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Adam Roach Fecha: jueves, 10 de enero de 2019, 8:19 Para: The IESG CC: , = , Asunto: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-transition-ip= v4aas-12: (with COMMENT) Adam Roach has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-12: 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-transition-ipv4aas/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 I share Ben and Mirja's question about the formal relationship between = this document and RFC 7084. =20 I also share Ben's confusion about the document's status as not being a= BCP -- statements like the following are, by my understanding of the term, spe= cifying practices that are considered to be "best" at the present time: =20 * "The IPv6 Transition CE Router MUST implement a DNS proxy as described in [RFC5625] (DNS Proxy Implementation Guidelines)." =20 * "The IPv6 Transition CE Router MUST support the DHCPv6 S46 priority options described in [RFC8026]." =20 * "The IPv6 Transition CE Router MUST have a GUI, CLI and/or API option to manually enable/disable each of the supported transition mechanisms." =20 If these (and similarly phrased) statements are not recommending best c= urrent practices, then I don't understand the purpose of this document. =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 Jan 10 03:56:26 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 8E84E130E0E; Thu, 10 Jan 2019 03:56:25 -0800 (PST) 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.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <154712138552.30788.17161126404984592785@ietfa.amsl.com> Date: Thu, 10 Jan 2019 03:56:25 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-13.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: Thu, 10 Jan 2019 11:56:26 -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 : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-13.txt Pages : 24 Date : 2019-01-10 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or by vendors who sell through the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is necessary because there aren't sufficient IPv4 addresses available for every possible customer/device. However, devices or applications in the customer LANs (Local Area Networks) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-13 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 10 04:02: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 632FC130E13 for ; Thu, 10 Jan 2019 04:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10R5P2-A9hbl for ; Thu, 10 Jan 2019 04:02:21 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41BA130E0E for ; Thu, 10 Jan 2019 04:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547121739; x=1547726539; 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=69Vge5vW cHfam2YM+RrlgjNUXIGwIy59VueXx50yUGg=; b=gl9E1ZYpWKu8nfhcbfbpFPd5 zIKuzjIPCxSk3cB6flzCYQOu+D9sjIXYXCY7BLKHkcYIUg3zrblgNJt2BlcmlYAH p6f+NLJPdWCXDfqaeOfLaxpOTeHOQzvFcdvel4xucYgiVnG8bl0vGfpWwQ8XrlVj io9hutW+8hTlsYNz5v8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 10 Jan 2019 13:02:19 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 10 Jan 2019 13:02:17 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006104705.msg for ; Thu, 10 Jan 2019 13:02:17 +0100 X-MDRemoteIP: 2001:470:1f09:495:6d25:fb99:feb6:ac39 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Thu, 10 Jan 2019 13:02:17 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1913f26ae7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 10 Jan 2019 13:02:16 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-13.txt References: <154712138552.30788.17161126404984592785@ietfa.amsl.com> In-Reply-To: <154712138552.30788.17161126404984592785@ietfa.amsl.com> 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-ietf-v6ops-transition-ipv4aas-13.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, 10 Jan 2019 12:02:27 -0000 Hi all, This version includes the agreed changes from the security-area review and = a few other editorial changes/clarifications from the other area reviews, a= s well as comments from the IESG review. Pending issue is the Suresh discuss, as didn't heard back from him. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: jueves, 10 de enero de 2019, 12:56 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-13.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-13.txt Pages : 24 Date : 2019-01-10 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or by vendors who sell through the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). Thi= s is necessary because there aren't sufficient IPv4 addresses availabl= e for every possible customer/device. However, devices or application= s in the customer LANs (Local Area Networks) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-13 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-13 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -13 =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 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =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 Jan 10 06:41: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 103AB130EEF; Thu, 10 Jan 2019 06:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=jshV3Wuy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KqD9uGo8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkPVL7-vkCBM; Thu, 10 Jan 2019 06:41:20 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF54A130EFC; Thu, 10 Jan 2019 06:41:19 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2FFF223346; Thu, 10 Jan 2019 09:41:19 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 10 Jan 2019 09:41:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=T zmFuFCRk2nk3tESE1kWF2iFMxjGHgte2usBAFEjH0s=; b=jshV3WuyA7GGawSwl SDO0TO1+Tog3c9CVCaK9NUEnkybrEJgSLN7nRedkGoyzuJxAoQvKAYmD4VdITvv5 PHycmnzGHC6JqcHTnkWi4oSYV6baYnQfL7GE7dAdU1E1V17BY27ri3Va+VDngyBo ckZpJrlaHVRF0nVw2Rb9u+gpzDQ9p5Ik4aIQ6Bpze+sLEj7XPnjpaCiAJqSDdn4F ek+nFnePh4IQVTGI1sRCyGO9siPAzuQ6pWODyYkC+6URM8a4u6OnEOiTK54kadbI rleirmdOzazutHod3r1/hEz9yTKPCJV8IHrauWO7xxNCe9i74eDB+AOgcPN1nwA/ Lbvrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=TzmFuFCRk2nk3tESE1kWF2iFMxjGHgte2usBAFEjH 0s=; b=KqD9uGo8qFbCmQVkAiacA/SZHBsGJZ6XLVUDyxcKlJ76rCSqX0N8Wc0a9 Nq241b66UxROIk5BReQH8v9ntSTXi+v4pPrMzMuemBpVIYbqf8LRNDdlmRutaYzx XgOiSbtHY60LJHHN4746EqDcYGCyDiIbSc+Pm+rxk80M7KuIhI4yxrdEM69gUcJI xIjsy+jSG4a8BBQpxHyb/CPZai4tWR3PV1ihIQ9OYUtsjELT8ae29Cxsta7lympz hNeTvkwX9q2vyDjFP5x7oQ0nGYUEEFbMCfwEWhGaKsAekaUmgxQZEokQOyX1n8xD 8VFF+UjylpgHY5rMccuWqZWwAwpMA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeefgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffgf fkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegr lhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrghinhepihgvthhfrdhorhhgne cukfhppedujeefrdefkedruddujedrkeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr lhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D700102ED; Thu, 10 Jan 2019 09:41:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <154648618337.32563.8004719155986024146@ietfa.amsl.com> Date: Thu, 10 Jan 2019 09:41:17 -0500 Cc: IETF Gen-ART , v6ops@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3BF5CD51-AAB3-40A4-95F5-5EB7ED10A041@cooperw.in> References: <154648618337.32563.8004719155986024146@ietfa.amsl.com> To: Matthew Miller X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] [Gen-art] Genart last call review of draft-ietf-v6ops-transition-ipv4aas-12 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, 10 Jan 2019 14:41:22 -0000 Matt, thanks for your review. Jordi, thanks for your responses. I = entered a DISCUSS ballot concerning the use of capitalized keywords. Alissa > On Jan 2, 2019, at 10:29 PM, Matthew Miller = wrote: >=20 > Reviewer: Matthew Miller > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-v6ops-transition-ipv4aas-12 > Reviewer: Matthew A. Miller > Review Date: 2019-01-02 > IETF LC End Date: 2018-12-14 > IESG Telechat date: 2019-01-10 >=20 > Summary: This document is ready to be published as Informational, > but has some nits that should be addressed before publication. >=20 > Major issues: N/A >=20 > Minor issue: >=20 > There are some instances within the main content that RFC 2119 > keywords are present as lower case. If these are intentional, then > RFC 8174 needs to be applied. >=20 > Nits/editorial comments:=20 >=20 > * In section 1. "Introduction" (and its subsections), the term "IPv6 > Transition CE Router" is not preceded with a definite or indefinite > article, although it is throughout the rest of this document. > * In section 1. "Introduction", the phrase "prohibitive expense" > ought to be "prohibitively expensive". > * In section 7. "Code Considerations", the word "neither" might be > better as "nor" in the phrase "in terms of RAM memory, neither > other hardware requirements". > * In section 7. "Code Considerations", there seems to be a misplaced > coma; "cost of NAT44 code so, existing hardware supports them with > minimal impact" reads better as "cost of NAT44 code, so existing > hardware supports them with minimal impact". > * In section 11. "Annex A: Usage Scenarios", the comma seems > unneeded in the phrase "another CE behind it, takes care of that". > * In section 12. "Annex B: End-User Network Architecture", the > term "end-user" should be used consistently, it is sometimes > "end user". >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Jan 10 06:42:50 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 7AC59130EEF; Thu, 10 Jan 2019 06:42:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154713136049.30772.14214762331468539097.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2019 06:42:40 -0800 Archived-At: Subject: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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, 10 Jan 2019 14:42:41 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-13: Discuss 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-transition-ipv4aas/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I think the standard RFC 8174 boilerplate is needed here. I think it was a mistake to use the 2119 keywords differently in RFC 7084, and that mistake need not be repeated. This document uses the normative keywords in the same ways as many other informational documents. RFC 2119 is not focused on interoperability, but rather on the requirements that the specification using the keywords is laying out. (2) I don't think it is appropriate for this document to defined a new normative keyword, "DEFAULT," in Section 1.1. The right place to do that would be an update to RFC 2119 or RFC 8174. This is especially problematic given that the one place in this document where it is used, it is in a paragraph that also uses other normative keywords. Since it's only used once, I would suggest just explaining what it means in that location (3.2.2) rather than defining it as a keyword. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == Section 1 == OLD This ensures that remote IPv4-only services continue to be accessible, from an IPv6-only Internet Service Provider access network (typically referred as WAN - Wide Area Network, even if in some cases it may be metropolitan, regional, etc.), from both, IPv4-only and IPv6-only applications or devices in the LAN side. NEW This ensures that remote IPv4-only services continue to be accessible from an IPv6-only Internet Service Provider (ISP) access network from both IPv4-only and IPv6-only applications and devices on the LAN side. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if in some cases they may be metropolitan or regional. (Then you could deleted the parenthetical "(Internet Service Providers)" in the sentence below Figure 1.) It seems odd that Figure 1 appears in Section 1 but isn't referenced in the text until Section 12. I think you need a sentence in this section to describe what is depicted in the figure or why it is there, or you need to remove the figure. s/devices or applications/devices and applications/ == Section 3.2 == s/an automated IPv6 transition mechanism provisioning/automated IPv6 transition mechanism provisioning/ s/per interface/per interface/ Would suggest dropping "(which may depend on each transition mechanism)" since it makes the sentence confusing and doesn't add anything. == Section 3.2.1 == OLD If DNS64 [RFC6147] is not used, or not trusted, as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer, then the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115], which also can be used if the service provider uses DNS64 [RFC6147]. NEW It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]. These can also be used if the service provider uses DNS64. == Section 7 == I would suggest starting this section with "At the time of this writing, ..." == Section 12 == The text that refers to Figure 1 I think is meant to refer to Figure 2. Or if not, text is needed to describe Figure 2. From nobody Thu Jan 10 06:50:07 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 3A40E1311C5; Thu, 10 Jan 2019 06:49:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2019 06:49:50 -0800 Archived-At: Subject: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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, 10 Jan 2019 14:49:54 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-13: Discuss 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-transition-ipv4aas/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I guess this is related to Suresh's Discuss as well. It's late in the day and I'm reading quickly, so my apologies if I've missed something obvious and this is in fact a non-issue. That said, process-wise, it seems that 464XLAT-6 in Section 3.2.1 is attempting to direct an implementation of RFC 8115 to violate a MUST-level requirement from that document ("the conveyed multicast IPv6 prefix MUST belong to the [ASM|SSM] range") by allowing for all-zero ASM_mPrefix64 and SSM_mPrefix64 fields. (Furthermore, the end of Section 3 of RFC 8115 appears to suggest that the Well-Known DNS Name heuristic discovery-based method should be used instead, when only unicast services are needed.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [note: I reviewed the -12 version, as the -13 arrived during the middle of my review and I wanted to remain internally consistent] I don't think that making "DEFAULT" a capitalized keyword adds any value; the one usage reads fine with "default" in lowercase. Section 1 These routers rely upon "Basic Requirements for IPv6 Customer Edge Routers" [RFC7084], so the scope of this document is to ensure the IPv4 "service continuity" support, in the LAN side, ensuring that remote IPv4-only services are accessible, from an IPv6-only Internet Service Provider access network (typically referred as WAN - Wide Area Network, even in some cases it may be metropolitan, regional, etc.) even from IPv6-only applications or devices in the LAN side. nit: this is a single very-long sentence. I suggest breaking it into two or three smaller ones (e.g., break after "in the LAN side". device, causing IPv4 addresses to become prohibitive expense. This, nit: "a prohibitive expense" or "prohibitively expensive" Since it is impossible to know prior to sale which transition mechanism a device will need over its lifetime, IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanisms supported by this document. Service providers nit: it's probably more "listed in" this document than "supported by". Section 1.1 I think it would be okay to just use the normal BCP 14 boilerplate, even though this is an information document placing (opt-in) requirements on devices to be used in a certain use case. Section 3.2 TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or API option to manually enable/disable each of the supported transition mechanisms. Do we really need to pick and name interfaces, or can we just say "MUST have a configuration interface"? TRANS-3: If an IPv6 Transition CE Router supports more than one LAN subnet, the IPv6 Transition CE Router MUST allow appropriate subnetting and configuring the address space nit: perhaps "configuration of"? (which may depend on each transition mechanism) among the several interfaces. In some transition mechanisms, this may require differentiating mappings/translations per interfaces. nit: perhaps "different mappings/translations" or "differentiating mappings/translations on a per-interface basis" CONFIG-1: Request the relevant configuration options for each supported transition mechanisms, which MUST remain disabled at this step. This seems like it could make for really bad UX in some cases, such as when a user is only given one class of configuration information from their ISP and is hopelessly confused by questions (about other mechanisms) that they don't have answers for. Is the MUST requirement (not quoted) to follow this step really justified? Section 3.2.1 If 464XLAT is supported, it MUST be implemented according to [RFC6877]. [...] Do we want to consider adding "or a successor document"? 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network Address Translation (NAT) on IPv4 traffic translated using the CLAT, unless a dedicated /64 prefix has been "MUST, unless" is sometimes an awkward formulation. In general, even reordering to "Unless X, Y MUST ..." is frequently an improvement. Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST be used to send PCP requests to the server. What entity does this requirement apply to (and under what conditions, if any)? 464XLAT-7: The priority for the NAT64 prefix, in case the network provides several choices, MUST be: 1) [RFC7225], 2) [RFC8115], and 3) [RFC7050]. I'm not entirely sure why this has to be a MUST -- a SHOULD would leave room for implementations to have different preferences, say, if they like DHCP discovery more than PCP. If DNS64 [RFC6147] is not used, or not trusted, as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer, then the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115], which also can be used if the service provider uses DNS64 [RFC6147]. This is another long and convoluted sentence. If I am correct in inferring that "as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer" is intended to justify not trusting DNS64, then I suggest putting it in parentheses (in which case the now-internal parenthetical could be changed to just be offset by commas). Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST be used to send PCP requests to the server. Same comment as for Section 3.2.1. Section 7 However, it has been confirmed from existing open source implementations (OpenWRT/LEDE, Linux, others), that adding the support for the new transitions mechanisms, requires around 10-12 Kbytes (because most of the code base is shared among several transition mechanisms already supported by [RFC7084]), as a single data plane is common to all them, which typically means about 0,15% of the existing code size in popular CEs already in the market [OpenWRT]. nit: This sentence is very long. Even if it is not split into smaller sentences for clarity, I would suggest at least clarifying that the 0,15% refers to 10-12 KB being 0.15% of the existing code size. In general, the new requirements don't have extra cost in terms of RAM memory, neither other hardware requirements such as more powerful CPUs, if compared to the cost of NAT44 code so, existing hardware supports them with minimal impact. nit: s/neither/nor/; s/ so,/, so/; s/supports them/should be able to support them/. Finally, in some cases, operators supporting several transition mechanisms may need to consider training costs for staff in all those techniques for their operation and management, even if this is not nit: I don't think "those" is the right word here; maybe "the"? Section 8 I agree with the secdir reviewer that it would be pretty easy to include some more discussion of the DHCP (in)security situation in some common network types that would be relevant for this document, e.g., giving some guidance that for residential networks the risk/reward is likely in favor of trusting the information in DHCP responses even without DHCP security. Section 11 The situation previously described, where there is ongoing IPv6 deployment and lack of IPv4 addresses, is not happening at the same pace in every country, and even within every country, every ISP. For nit: "for every ISP" the global transition timings cannot be estimated. nit: they can be estimated by anyone with a pulse; what cannot be done is reliable estimation. Considering that situation and different possible usage cases, the IPv6 Transition CE Router described in this document is expected to be used typically, in residential/household, Small Office/Home Office (SOHO) and Small/Medium Enterprise (SME). [...] I share the concern expressed in the directorate review of the use of the term "SME" here (but did not yet get a chance to fully follow the subsequent discussion). The above is not intended to be comprehensive list of all the possible usage cases, just an overall view. In fact, combinations of nit: "a comprehensive" the above usages are also possible, as well as situations where the same CE is used at different times in different scenarios or even different services providers that may use a different transition mechanism. nit: "or even with different" available in any IPv6 router, when using GUA (IPv6 Global Unicast nit: no comma here Addresses), unless they are blocked by firewall rules, which may require some manual configuration by means of a GUI, CLI and/or API. same comment as above -- can't we just say "manual configuration" and not guess at modes of doing so? already provide a GUI and/or a CLI to manually configure them, or the possibility to setup the CE in bridge mode, so another CE behind it, takes care of that. The requirements for that support are out of the nit: no comma before "takes care of that" It is not relevant who provides the IPv6 Transition CE Router. In most of the cases is the service provider, and in fact is responsible, typically, of provisioning/managing at least the WAN nit: "it is the service provider" nit: "in fact they are responsible, typically, for provisioning/managing" underscores the importance of the IPv6 Transition CE Routers supporting the same requirements defined in this document. nit: generally I see "supporting" with "features" and "meeting" or "fulfilling" with "requirements". Section 12 combined with a dynamic routing protocol. Once again, this is true for both, IPv4 and IPv6. nit: no comma here From nobody Thu Jan 10 06:53: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 1185F130F1D; Thu, 10 Jan 2019 06:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBAynxC5mvbM; Thu, 10 Jan 2019 06:53:03 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967D7130F1A; Thu, 10 Jan 2019 06:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547131980; x=1547736780; 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=Pip62aIAB2JhyzXYr/YexAtC793dlq/Xu2gVAIHpM2c=; b=ihN7ss3SGrFfi 45UdbNhPiD46dtS+hKHwmC+GLkYnttJj3Y5L0eTj3YT+ZkeT9w+We6JLcnaSPRFD /2KMuvDhR0koc3MBGbuSKulqSrTgprQy2U/tvUtLya19bmxzk4a4YDDqASz2IH6O LxayG873Y/fdQCRJRiK8Kno5cvOZYo= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 10 Jan 2019 15:53:00 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 10 Jan 2019 15:53:00 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006104871.msg; Thu, 10 Jan 2019 15:52:59 +0100 X-MDRemoteIP: 2001:470:1f09:495:fcec:f8ce:9c9f:fd05 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Thu, 10 Jan 2019 15:52:59 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1913f26ae7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 10 Jan 2019 15:52:59 +0100 From: JORDI PALET MARTINEZ To: Alissa Cooper , The IESG CC: , , Message-ID: <2D4CAEDC-F02F-4BEB-8D80-DB0B461B6D30@consulintel.es> Thread-Topic: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT) References: <154713136049.30772.14214762331468539097.idtracker@ietfa.amsl.com> In-Reply-To: <154713136049.30772.14214762331468539097.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 Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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, 10 Jan 2019 14:53:06 -0000 Hi Alissa, Thanks for the review. See my inputs below, in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alissa Cooper Fecha: jueves, 10 de enero de 2019, 15:43 Para: The IESG CC: , = , Asunto: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4= aas-13: (with DISCUSS and COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-13: Discuss =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-transition-ipv4aas/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 (1) I think the standard RFC 8174 boilerplate is needed here. I think i= t was a mistake to use the 2119 keywords differently in RFC 7084, and that mist= ake need not be repeated. This document uses the normative keywords in the same = ways as many other informational documents. RFC 2119 is not focused on interoperability, but rather on the requirements that the specification= using the keywords is laying out. =20 (2) I don't think it is appropriate for this document to defined a new normative keyword, "DEFAULT," in Section 1.1. The right place to do tha= t would be an update to RFC 2119 or RFC 8174. This is especially problematic gi= ven that the one place in this document where it is used, it is in a paragraph t= hat also uses other normative keywords. Since it's only used once, I would sugge= st just explaining what it means in that location (3.2.2) rather than defining = it as a keyword. =20 I've no problem in proceeding as you indicated in (1) and (2) above. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 =3D=3D Section 1 =3D=3D =20 OLD This ensures that remote IPv4-only services continue to be accessible, from an IPv6-only Internet Service Provider access network (typicall= y referred as WAN - Wide Area Network, even if in some cases it may be metropolitan, regional, etc.), from both, IPv4-only and IPv6-only applications or devices in the LAN side. =20 NEW This ensures that remote IPv4-only services continue to be accessible from an IPv6-only Internet Service Provider (ISP) access network fro= m both IPv4-only and IPv6-only applications and devices on the LAN side. Th= ese ISP access networks are typically referred to as Wide Area Networks (WAN= s), even if in some cases they may be metropolitan or regional. =20 (Then you could deleted the parenthetical "(Internet Service Providers)= " in the sentence below Figure 1.) Thanks, this looks much better. =20 It seems odd that Figure 1 appears in Section 1 but isn't referenced in= the text until Section 12. I think you need a sentence in this section to d= escribe what is depicted in the figure or why it is there, or you need to remov= e the figure. Right, I think this is something that is related to the xml editor, and did= n't realized that. The reference in section 12 is for Figure 2, not Figure = 1 ... So it was incorrectly renumbered. =20 s/devices or applications/devices and applications/ =20 =3D=3D Section 3.2 =3D=3D =20 s/an automated IPv6 transition mechanism provisioning/automated IPv6 tr= ansition mechanism provisioning/ =20 s/per interface/per interface/ =20 Would suggest dropping "(which may depend on each transition mechanism)= " since it makes the sentence confusing and doesn't add anything. =20 =3D=3D Section 3.2.1 =3D=3D =20 OLD If DNS64 [RFC6147] is not used, or not trusted, as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer, the= n the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115], which also can be used if the service provider uses DNS64 [RFC6147]. =20 NEW It may be the case that the service provider does not use or does not t= rust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behin= d the CE) may be modified by the customer. In that case, the service provider= may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]= . These can also be used if the service provider uses DNS64. =20 =3D=3D Section 7 =3D=3D =20 I would suggest starting this section with "At the time of this writing= , ..." =20 =3D=3D Section 12 =3D=3D =20 The text that refers to Figure 1 I think is meant to refer to Figure 2.= Or if not, text is needed to describe Figure 2. =20 Right, all the precented changes look fine to me. Thanks! =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 Jan 10 07:02:50 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 71F031294D0; Thu, 10 Jan 2019 07:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_FILL_THIS_FORM_SHORT=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=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 k_RBO-0BEgch; Thu, 10 Jan 2019 07:02:28 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BB6129AB8; Thu, 10 Jan 2019 07:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547132546; x=1547737346; 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=utBGJVISqMZhVi8h2ATOKKWey0r1ailyg+vHvFP6gQI=; b=TO3rmO79RqWxI ky9U8aXKixk0Y8nvrRgZMlAooKqs25xsaPrtEXtZJCt8acmgtTNhWXaTuuHHBnaT mfICauMGpFAAENnE5Y7Y/X5QKhe5kOXki9qbWkdNJco7/E8zjFmC2lk1XHMQbCLz PR+WO9wkGquAwF5WjWaaLlTKWPDn/Y= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 10 Jan 2019 16:02:26 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 10 Jan 2019 16:02:25 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006104887.msg; Thu, 10 Jan 2019 16:02:25 +0100 X-MDRemoteIP: 2001:470:1f09:495:fcec:f8ce:9c9f:fd05 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Thu, 10 Jan 2019 16:02:25 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1913f26ae7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 10 Jan 2019 16:02:21 +0100 From: JORDI PALET MARTINEZ To: Benjamin Kaduk , The IESG CC: , , Message-ID: <299A99AE-6212-4750-B07F-BBAD69DA20CC@consulintel.es> Thread-Topic: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT) References: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> In-Reply-To: <154713179023.30772.10696284348809827591.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 Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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, 10 Jan 2019 15:02:32 -0000 Hi Benjamin, Thanks for your review. I saw your earlier comments earlier this morning, b= ut only got this email right now. I will check all the detailed suggestions, but I'm sure some of them have a= lready been resolved in -13 (submitted earlier today), such as breaking lon= g sentences and a few others. Even if the subject of the emails says -13, I think you've been reviewing -= 12, but I will make sure to follow all them anyway, I guess is some kind of= failure with the tools. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Benjamin Kaduk Fecha: jueves, 10 de enero de 2019, 15:50 Para: The IESG CC: , = , Asunto: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv= 4aas-13: (with DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-13: Discuss =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-transition-ipv4aas/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 I guess this is related to Suresh's Discuss as well. =20 It's late in the day and I'm reading quickly, so my apologies if I've missed something obvious and this is in fact a non-issue. That said, process-wise, it seems that 464XLAT-6 in Section 3.2.1 is attempting to direct an implementation of RFC 8115 to violate a MUST-level requiremen= t from that document ("the conveyed multicast IPv6 prefix MUST belong to = the [ASM|SSM] range") by allowing for all-zero ASM_mPrefix64 and SSM_mPrefi= x64 fields. (Furthermore, the end of Section 3 of RFC 8115 appears to sugg= est that the Well-Known DNS Name heuristic discovery-based method should be used instead, when only unicast services are needed.) =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 [note: I reviewed the -12 version, as the -13 arrived during the middle= of my review and I wanted to remain internally consistent] =20 I don't think that making "DEFAULT" a capitalized keyword adds any valu= e; the one usage reads fine with "default" in lowercase. =20 Section 1 =20 These routers rely upon "Basic Requirements for IPv6 Customer Edge Routers" [RFC7084], so the scope of this document is to ensure the IPv4 "service continuity" support, in the LAN side, ensuring that remote IPv4-only services are accessible, from an IPv6-only Internet Service Provider access network (typically referred as WAN - Wide Area Network, even in some cases it may be metropolitan, regional, etc.) even from IPv6-only applications or devices in the LAN side. =20 nit: this is a single very-long sentence. I suggest breaking it into t= wo or three smaller ones (e.g., break after "in the LAN side". =20 device, causing IPv4 addresses to become prohibitive expense. This, =20 nit: "a prohibitive expense" or "prohibitively expensive" =20 Since it is impossible to know prior to sale which transition mechanism a device will need over its lifetime, IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanisms supported by this document. Service providers =20 nit: it's probably more "listed in" this document than "supported by". =20 Section 1.1 =20 I think it would be okay to just use the normal BCP 14 boilerplate, eve= n though this is an information document placing (opt-in) requirements on devices to be used in a certain use case. =20 Section 3.2 =20 TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or API option to manually enable/disable each of the supporte= d transition mechanisms. =20 Do we really need to pick and name interfaces, or can we just say "MUST have a configuration interface"? =20 TRANS-3: If an IPv6 Transition CE Router supports more than one LAN subnet, the IPv6 Transition CE Router MUST allow appropriate subnetting and configuring the address space =20 nit: perhaps "configuration of"? =20 (which may depend on each transition mechanism) among the several interfaces. In some transition mechanisms, this may require differentiating mappings/translations per interfaces. =20 nit: perhaps "different mappings/translations" or "differentiating mappings/translations on a per-interface basis" =20 CONFIG-1: Request the relevant configuration options for each supported transition mechanisms, which MUST remain disabled at this step. =20 This seems like it could make for really bad UX in some cases, such as = when a user is only given one class of configuration information from their = ISP and is hopelessly confused by questions (about other mechanisms) that t= hey don't have answers for. Is the MUST requirement (not quoted) to follow this step really justified? =20 Section 3.2.1 =20 If 464XLAT is supported, it MUST be implemented according to [RFC6877]. [...] =20 Do we want to consider adding "or a successor document"? =20 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network Address Translation (NAT) on IPv4 traffic translated using the CLAT, unless a dedicated /64 prefix has been =20 "MUST, unless" is sometimes an awkward formulation. In general, even reordering to "Unless X, Y MUST ..." is frequently an improvement. =20 Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST be used to send PCP requests to the server. =20 What entity does this requirement apply to (and under what conditions, = if any)? =20 464XLAT-7: The priority for the NAT64 prefix, in case the network provides several choices, MUST be: 1) [RFC7225], 2) [RFC8115], and 3) [RFC7050]. =20 I'm not entirely sure why this has to be a MUST -- a SHOULD would leave room for implementations to have different preferences, say, if they li= ke DHCP discovery more than PCP. =20 If DNS64 [RFC6147] is not used, or not trusted, as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer, the= n the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115], which also can be used if the service provider uses DNS64 [RFC6147]. =20 This is another long and convoluted sentence. If I am correct in infer= ring that "as the DNS configuration at the CE (or hosts behind the CE) may b= e modified by the customer" is intended to justify not trusting DNS64, th= en I suggest putting it in parentheses (in which case the now-internal parenthetical could be changed to just be offset by commas). =20 Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST b= e used to send PCP requests to the server. =20 Same comment as for Section 3.2.1. =20 Section 7 =20 However, it has been confirmed from existing open source implementations (OpenWRT/LEDE, Linux, others), that adding the support for the new transitions mechanisms, requires around 10-12 Kbytes (because most o= f the code base is shared among several transition mechanisms already supported by [RFC7084]), as a single data plane is common to all them, which typically means about 0,15% of the existing code size in popular CEs already in the market [OpenWRT]. =20 nit: This sentence is very long. Even if it is not split into smaller sentences for clarity, I would suggest at least clarifying that the 0,1= 5% refers to 10-12 KB being 0.15% of the existing code size. =20 In general, the new requirements don't have extra cost in terms of RAM memory, neither other hardware requirements such as more powerfu= l CPUs, if compared to the cost of NAT44 code so, existing hardware supports them with minimal impact. =20 nit: s/neither/nor/; s/ so,/, so/; s/supports them/should be able to support them/. =20 Finally, in some cases, operators supporting several transition mechanisms may need to consider training costs for staff in all thos= e techniques for their operation and management, even if this is not =20 nit: I don't think "those" is the right word here; maybe "the"? =20 Section 8 =20 I agree with the secdir reviewer that it would be pretty easy to includ= e some more discussion of the DHCP (in)security situation in some common network types that would be relevant for this document, e.g., giving so= me guidance that for residential networks the risk/reward is likely in fav= or of trusting the information in DHCP responses even without DHCP securit= y. =20 Section 11 =20 The situation previously described, where there is ongoing IPv6 deployment and lack of IPv4 addresses, is not happening at the same pace in every country, and even within every country, every ISP. Fo= r =20 nit: "for every ISP" =20 the global transition timings cannot be estimated. =20 nit: they can be estimated by anyone with a pulse; what cannot be done = is reliable estimation. =20 Considering that situation and different possible usage cases, the IPv6 Transition CE Router described in this document is expected to be used typically, in residential/household, Small Office/Home Offic= e (SOHO) and Small/Medium Enterprise (SME). [...] =20 I share the concern expressed in the directorate review of the use of t= he term "SME" here (but did not yet get a chance to fully follow the subsequent discussion). =20 The above is not intended to be comprehensive list of all the possible usage cases, just an overall view. In fact, combinations o= f =20 nit: "a comprehensive" =20 the above usages are also possible, as well as situations where the same CE is used at different times in different scenarios or even different services providers that may use a different transition mechanism. =20 nit: "or even with different" =20 available in any IPv6 router, when using GUA (IPv6 Global Unicast =20 nit: no comma here =20 Addresses), unless they are blocked by firewall rules, which may require some manual configuration by means of a GUI, CLI and/or API. =20 same comment as above -- can't we just say "manual configuration" and n= ot guess at modes of doing so? =20 already provide a GUI and/or a CLI to manually configure them, or th= e possibility to setup the CE in bridge mode, so another CE behind it, takes care of that. The requirements for that support are out of th= e =20 nit: no comma before "takes care of that" =20 It is not relevant who provides the IPv6 Transition CE Router. In most of the cases is the service provider, and in fact is responsible, typically, of provisioning/managing at least the WAN =20 nit: "it is the service provider" nit: "in fact they are responsible, typically, for provisioning/managin= g" =20 underscores the importance of the IPv6 Transition CE Routers supporting the same requirements defined in this document. =20 nit: generally I see "supporting" with "features" and "meeting" or "fulfilling" with "requirements". =20 Section 12 =20 combined with a dynamic routing protocol. Once again, this is true for both, IPv4 and IPv6. =20 nit: no comma here =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 Jan 10 08:43: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 944AD130E95; Thu, 10 Jan 2019 08:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuuF8JXZDgW2; Thu, 10 Jan 2019 08:43:49 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26116130E97; Thu, 10 Jan 2019 08:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547138626; x=1547743426; 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=+f7Ddk44lAA8V/OJcMO7mU8OFJZ7vPGUvITs09PiGHc=; b=FovOuoC+wEpBW Aou9xh0sT7XqblfIS7rRBn/56dXF/6OaX0ASkIPWl+PT6ZzeP0tNoDGyAuMz4hus 8tWm+lHf+4xAnUtFWTDVAabJFbUpPQqrGStBRJM1iNgMbcxljmRSXNyIIZfkAgW0 K5gRLFMbICzitoXzKtpPIl2PWfZ9rE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 10 Jan 2019 17:43:46 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 10 Jan 2019 17:43:45 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006105116.msg; Thu, 10 Jan 2019 17:43:33 +0100 X-MDRemoteIP: 2001:470:1f09:495:fcec:f8ce:9c9f:fd05 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Thu, 10 Jan 2019 17:43:33 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1913f26ae7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 10 Jan 2019 17:43:32 +0100 From: JORDI PALET MARTINEZ To: Benjamin Kaduk , The IESG CC: , , Message-ID: <16C30688-747B-4723-BBD7-FF82FCAA6A26@consulintel.es> Thread-Topic: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT) References: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> In-Reply-To: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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, 10 Jan 2019 16:43:52 -0000 Hi Benjamin, Thanks again for your detailed review. I'm already working in a draft for a new version including all the nits that you mention (some already were corrected in -13). Some clarifications to some of your comments. Section 3.2 TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or API option to manually enable/disable each of the supported transition mechanisms. Do we really need to pick and name interfaces, or can we just say "MUST have a configuration interface"? Yes, the point here is to make sure that at least there is a GUI and CLI (or API). The idea is that the customer is able to buy a CE and later on use it in a different ISP. So, having both facilitate that, even in the case of a manual configuration required by the user. Normally DHCP-based mechanisms should do it, and also is currently very common that both are already supported, so not a big issue. CONFIG-1: Request the relevant configuration options for each supported transition mechanisms, which MUST remain disabled at this step. This seems like it could make for really bad UX in some cases, such as when a user is only given one class of configuration information from their ISP and is hopelessly confused by questions (about other mechanisms) that they don't have answers for. Is the MUST requirement (not quoted) to follow this step really justified? This is needed to allow the rest of the config/priority process. I believe you are misinterpreting as something done by the user in the GUI or something. While it may be possible, it not the case. It is all done by DHCP. Section 3.2.1 If 464XLAT is supported, it MUST be implemented according to [RFC6877]. [...] Do we want to consider adding "or a successor document"? I think if we do that, we could need doing that for every RFC ... that's why we have documents updating previous ones, so I don't think so. Regards, Jordi ********************************************** 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 Thu Jan 10 14:36: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 A08971312A2; Thu, 10 Jan 2019 14:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.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 AhaVYNZBKBjB; Thu, 10 Jan 2019 14:36:40 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730116.outbound.protection.outlook.com [40.107.73.116]) (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 23B8D131293; Thu, 10 Jan 2019 14:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7rjybcYJoXwaYTiyb5+aQuryE6qVwuYm6YViH94mdX8=; b=CslsXvRtx1C/mmPpPm/4sM1y6qfegqLyaB5kw2RUY8Lub3IhGuIQR1qJz3rfdT8EBm3aoMlBhKVWWFfAb5oB8o63BfFZV/PssYiIT+5/fbhLk3SOJc7t4GFLfKsnkZgBxYcKSRcagc/6QyreaNeb9+p/YTsQf2Vm6j5rcJIC3pE= Received: from DM5PR0101CA0002.prod.exchangelabs.com (2603:10b6:4:28::15) by BN8PR01MB5523.prod.exchangelabs.com (2603:10b6:408:ba::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.13; Thu, 10 Jan 2019 22:36:37 +0000 Received: from BY2NAM03FT013.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::209) by DM5PR0101CA0002.outlook.office365.com (2603:10b6:4:28::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.7 via Frontend Transport; Thu, 10 Jan 2019 22:36:37 +0000 Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT013.mail.protection.outlook.com (10.152.84.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Thu, 10 Jan 2019 22:36:37 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0AMaXgN032327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 17:36:35 -0500 Date: Thu, 10 Jan 2019 16:36:33 -0600 From: Benjamin Kaduk To: JORDI PALET MARTINEZ CC: The IESG , , , Message-ID: <20190110223633.GS28515@kduck.mit.edu> References: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> <16C30688-747B-4723-BBD7-FF82FCAA6A26@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <16C30688-747B-4723-BBD7-FF82FCAA6A26@consulintel.es> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(136003)(346002)(2980300002)(199004)(189003)(229853002)(8936002)(6346003)(46406003)(26005)(186003)(7696005)(8676002)(55016002)(356004)(76176011)(106466001)(336012)(1076003)(66574012)(47776003)(33656002)(53416004)(50466002)(246002)(75432002)(486006)(6916009)(316002)(956004)(36906005)(58126008)(23726003)(54906003)(16586007)(97756001)(476003)(126002)(104016004)(2906002)(426003)(4326008)(446003)(26826003)(478600001)(5660300001)(88552002)(6246003)(86362001)(14444005)(106002)(305945005)(11346002)(786003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR01MB5523; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT013; 1:2t5fsVOoPGvZBP3cOZU+uDym52KgWSACofJFHGshYOvzsUHvmipsvkzuF9f2dIQjHQD/LlkOqtY5OLFNgDJpsuPbAjEMcX+unoakY/MkbgzApH+NLeeyh1OZs68Jrex1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 51884907-0e80-46f9-2e82-08d6774c1519 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BN8PR01MB5523; X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5523; 3:d7lksu0AVBXL1y+bDUmZa9rirHezVcsmnM5qoSj6wDuJAuN7WmPgMOeevcOXe4nkPdLxvxSCFk7HxLRsaKHgZpEJSvBabEkZ2468vWgeF3/ptsAb0U+hvsGEh2gkFEcPvdgVNmzCfYE8SptxhWOHKGNtfKKo03A6/i5UPGQH4QLNIrkMJGIvpirHo64++bwjb61092BnjMtLYQk15yVXEwPzUHeKbdCZrJ3ZxboO3xLYZ+KFgqy/AyFy3PC2gfpSRBhHPODUFyWxL+XTLQT9LVwwEd3BDlSkwez++SXfxqKh+KzkBlogUAcZek+c2vrF8seaOvclWa6OUfe+obWDaf8i5N+FghQ/twVYYmN91OB9ImhEZmMv0tr90CvyQwEY; 25:bnBySoIHc+SsgVCzxJmIADdmWpZOzGSNMV+5ihI5kBIH1X3+qeV4GCbIgvQhqsI39n4kZRpJYwouFLmST2nx25jMYrw5pJGQ1+d2XtSh5wwIQ1Ynv11JBckz9CjBbpqZOZiVj9kLnH2CzDCUFwJqay/3+mTVGNuTtkcM5INhg7Sk+1OawuVlqW+x4KpSGeSr0nOp+d5VcFU8TEUSchUwKcRZ6uWFFxGR+w2Zvn5W/Qe/OHQPhopk+bXOS3eAeDUvvBvpJ7xFSpV9VVamZs7Pr4yWI9PW8mR3zr68gbJZchifpy5+yaYlMaD0ni2Jo0hCd9nvbVYDiyvRFW6Jw35MAg== X-MS-TrafficTypeDiagnostic: BN8PR01MB5523: X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5523; 31:f1afNhBSq76fhPL+nLkbaMU67UUC1AJwEKCtjtuG0E67dByCzhYmdhqyHTgl7DcAhldcxPPebXvypn4ksdpXLHATTqxX3JFW+hR0qmOEdXwWckndkSZlKkdMtjSfGC7Dwy9/Fx1J82Ap4TxM9atBMVTR1uSvwx3uynOozOz0DddJbqOpCDOEDFJWOz6z8Wp111/aRV2aMNxx4+o8f87/mGhbCuwxiRJOPoDv1gT+gbQ=; 20:YcRGhUO/uR+aynwXSj9+60kxYKCVHxDj5UxX7Exx04WBOAJbtaWoYUq+6FHkmTHab31UjLdlc85MPNogylYlidqcm5TZ6ZYZSAQjmLsNJl0KHPtl6rZuDX7SHpYznehSQzH4NktvJNvM52RjV8OGl2pl6E4vW2dPb58D448dpBhbGr3rkUJczB1y0op95LRlOsnG4FUkwLj3Ix7XXp/fFawLIiaaRVxUkFPt6wgwE+hMuwO1+1EaNIB6YvCKLc4WxiZkCSCEp9AK1Z9vPMQuZlc9QLjkiiiXNGln+M/lM+VjN6km85AWU8eV9YPb4AOwff7blKC9RFUphXMiVPKm9rCO1IbDf5LNmUs3AnA9wZQDVfi3D1q4AWq6iM2ijLGNAMNgpFQMX5EFJCDy6K1e6s5cSc4uogk/GdOIQWZPpdRD0YIUu0TuuJJwe6jDjSTXkEBaai9XZC47XKgiUmOOQNnt0UkVmqKmi18i/iqKNko3OzTPLOQRQBl7yQ1u0mV8 X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5523; 4:cg21kPEA4bJ76fw9BXrNVW6Bf+nQrHvNXh0Buuy/szM/8SBSQZsEd8qTN+WWzd2scn+gYdwi75gW906cuJMi70leGMXDrBp5a+/o3yQYgBEtZeg5JPkeGPQbx1csPehyiHQAoyBb51QMmTPQaRQUUL7x02ERMasR1dy68kAp5CxVm9nhHVNpXvQ2YChzbjwb/MfBQQzgoc+U/vTtV7f4ZoowgFJvJP7Xtsizd7dUX5wH4BEq0mX5SWlQcgcNKHJIvkcK8+4VpMqycwb7HjT+pvj9ydCJl/e/oaecZcPUsUU= X-Forefront-PRVS: 0913EA1D60 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN8PR01MB5523; 23:4uCG5Sd+/X+TqLh1aOl+rSos5mPXQ4KBFIfyld0o1?= =?us-ascii?Q?k8aqiL1nxsCs4fonYOkrbmvcP8HFuwtbE0NC+IhH7f5AxB1PvqZJ4qkcf+La?= =?us-ascii?Q?DRZEx6PeLbEJm3fgbB2STh0CkbTqUVk8jGdc4l+f3wd6zD9iqXEgB+znXw2O?= =?us-ascii?Q?8M8loPwtvEaGiTQRe7wF33oDkjCwGZ3Vn8Rr8OJUCixHc/b+Tn0GtCnubmOs?= =?us-ascii?Q?1dC+qcWNvhuSPg+ohwt3LJksHDfzsZ5B0iuGkyEO/gQ62gd282b26BcnKj8e?= =?us-ascii?Q?Seq92v1BSZ7ujGcxr1nq9bLNle8SYLWnFh3qrFicRcPcO3/auTJgXq4Jj7q0?= =?us-ascii?Q?KmLVOxUITLRXPH769L4vraWgSaI4Je78R4FvjGhIjgUEFP6QcAEoreTsDuF+?= =?us-ascii?Q?N2BShD+6WyHmOAMhj7prZP034K8a3tJ3Q46x6qeoZlnPd2yzSmqbtUrIRf6p?= =?us-ascii?Q?FUoSJH6/t4zreDQXEoEZmx7ViRqzIRD1ArwkHyseVrW7rjyQNqzIx3KLLCvw?= =?us-ascii?Q?2ljnrKLmzLeZsJH2GDNnMaHeDzu3BrhrHxdNR+CmISR/PYJ8E3lGiuUIIq3n?= =?us-ascii?Q?xSwBxZ8erZGLbKiy3PSINK6W7ZsMu/4uwmNor1KnF5Bm8b2Q9YftvnWGbl5t?= =?us-ascii?Q?hd+nNLiqeje33VEa0P+j8fkqSsPfe9/6U3fjNuZ8+DqjK0YJofApYPcWT+Iq?= =?us-ascii?Q?r337QId5HnZEwSOlYEVS6fZ4GGSk9INpzYWCO3hzPopvCkj3Uj5SJMFidJxK?= =?us-ascii?Q?CJN2qx5EdS5t+eImMy52yWomc7qR58M1y7C0jrJzkArB2JnlNJxVkx5TlUQ7?= =?us-ascii?Q?pLB+iRziOsown3AGzf+IGZlgkcy5ar5m4pwRgJQKPoAU1Sq7Zsq/TFqdn24t?= =?us-ascii?Q?7TpZy3iL8/GKY2tdHGHFqqG4H5DrVYf/PwQiBO6JoSd9GkZBEmNQAiHE7s3J?= =?us-ascii?Q?VqKJeTOawUwwCe6EHOkqEpjQP2HDcXOpj9h1QQgoY/e+wBdfqKby6HhW8VYj?= =?us-ascii?Q?+3zuhfBySTQ+zsHUauDT14APl80qo+z+I3PjM+ak2wcNn7eMwJoDq6quis9w?= =?us-ascii?Q?fSDG4zSrX6UzWYK6VkHL2LKBNkyFdIZmgj8Fpf/v4/aKcfhR/KSTUjO7LLHy?= =?us-ascii?Q?gmKxKprawt0EOQLL4/RbnhvinvPT3pz3IMfu/+Cg5Kne0LaTSjtq1jRpHzt1?= =?us-ascii?Q?ZDHoAnYV3lrNsETbumxokoctfHydSSjunyKjR07m10TnG89Qmd+QZNnaS2o8?= =?us-ascii?Q?MI+FJNpN/LImO/iOmpO197VKQjUQk55YCOycZ5x?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: pjUfulJPTpdfZZw2pbUSPX6mjIdQ3IvUkmNH3t7rNA6oRQlc+BDj5J4f6qF1cgpuLjWhTMO81t7YRtfkdZIGjTvETuMucHg+HWXbNqFALErRglLodSg0tRoE/T00DxdSoY4n/iycg03qVicDrRmmzmLN8mmX0PpoXtUtANkQ8Xo594bf+2kS4CGVPRNl7qcqAAMDKPbb2ZXQ37EaxvcXMWJcA+UG5zQyZ3JaPuqWMlguEFmhtBkqRwMqk2mjMoYyXmZm5znnHIU06RHVvx2AHSmfipsvcNMTXiZG2f+Ll3GmyDIM04XqkgFAZXx/t1d8deoXylDqbqOqqgARzTkXpowt6U16KRCWBjqfdKwmSiW1ZoGc7cQr/S/h1AhMqtKWjUw7B5OnMv8Rx9zX4x3sV1PJKc4/YFDIYbwozTAwSMQ= X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5523; 6:997eNFSOEe5j9V5FMsqp4ICOvtWFsybEfxudxJXX1H6/RRUACN6lkfawJuHFWFp9YIOch4cL5cKidlHavXtZJ2JEE/gXsoxkeV6/e3CUTQ+j/SJlOu7OdgIzA55eLQ5r3pY0/dYXOUVrJYansDQaNrlQKD2SNFX3dUjbsDlWKHHxXJbbiVhPyLnwfiD4aFB6T/ph65JOMIt/jU+eJEt8p+IafwPyKyxYOImS+h7cCrkKDEzyhT2iH66l/dYNjuuV+uvMbOqI9GCO+YPd4iT68w9Zc8FPJdzA64o6wJJsqPSTpRb8Qf4beC5DtE/RGUlXRnwTYfoMNRs5ZJoMDotKvVOdA6RuCO8BWeo6o8zxqwksaAIMwrD2ZRe+VlgZGiUg2ZH4BbTJ+JfXR0tywqGpCKUsihhOs99c7DPugSVJxLdZE5NqGqVHzL4sm2hlr6kv6ng/9A3jbAUnUFYIx9nhcQ==; 5:nrLkELYx5xCNMWpfj2YwfdpnWxBUgpd/QeTw4KbhFCzbMDkyxPoE/d9579TF/x+R+7SNcWFjCDHOGx8lF99jiEWUS8rOcuA2IjT32VIm/5ihitGatGeNGxKZuXFrbzxjkWosdaWzQh3SOOrohvL9rJCqDNrosFVpdd8jC6oXJARzoTj0OPs6QjydIJx1ZVS0xHengaxbeI8rzdoCvesm2w==; 7:t+mcl+vea0bRv7XD7iShsxtPG+pUsC7L6+qa0irR3VOEkcm3ESzWiFU5b+UTNxF4TjK+xrzee+p/Bajq5BohdacCdl8Wh2Vu1PkHV3cfAV7QUndJGoviOB4KjTLP+dlZ431hsyI/wfc8gjqulg/zlQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2019 22:36:37.0476 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 51884907-0e80-46f9-2e82-08d6774c1519 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR01MB5523 Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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, 10 Jan 2019 22:36:43 -0000 On Thu, Jan 10, 2019 at 05:43:32PM +0100, JORDI PALET MARTINEZ wrote: > Hi Benjamin, > > Thanks again for your detailed review. > > I'm already working in a draft for a new version including all the nits that you mention (some already were corrected in -13). > > Some clarifications to some of your comments. > > Section 3.2 > > TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or > API option to manually enable/disable each of the supported > transition mechanisms. > > Do we really need to pick and name interfaces, or can we just say "MUST > have a configuration interface"? > > Yes, the point here is to make sure that at least there is a GUI and CLI (or API). The idea is that the customer is able to buy a CE and later on use it in a different ISP. So, having both facilitate that, even in the case of a manual configuration required by the user. Normally DHCP-based mechanisms should do it, and also is currently very common that both are already supported, so not a big issue. Er, do you require both GUI and CLI, or not? The current text only requires at least one. (But yes, I agree it's common to support both already, so this is not likely to be a burdensome requirement.) > CONFIG-1: Request the relevant configuration options for each > supported transition mechanisms, which MUST remain > disabled at this step. > > This seems like it could make for really bad UX in some cases, such as when > a user is only given one class of configuration information from their ISP > and is hopelessly confused by questions (about other mechanisms) that they > don't have answers for. Is the MUST requirement (not quoted) to follow > this step really justified? > > This is needed to allow the rest of the config/priority process. I believe you are misinterpreting as something done by the user in the GUI or something. While it may be possible, it not the case. It is all done by DHCP. I think you are right about my confusion; thanks for picking up on it. > > Section 3.2.1 > > If 464XLAT is > supported, it MUST be implemented according to [RFC6877]. [...] > > Do we want to consider adding "or a successor document"? > > I think if we do that, we could need doing that for every RFC ... that's why we have documents updating previous ones, so I don't think so. Well, another alternative is (as Ben suggests) to just not include this sentence at all. Which would of course also address my point here :) -Benjamin From nobody Fri Jan 11 02: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 5498F12DF72; Fri, 11 Jan 2019 02:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 KXCbJeNKSc_N; Fri, 11 Jan 2019 02:52:05 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA4A12872C; Fri, 11 Jan 2019 02:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547203921; x=1547808721; 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=q8tWiWnIYFvTjuorBgNF/GWk7l0cGJyNPbp9t087dOg=; b=WXDj/MhfkuvGd NEgztOVk8IZ+IK/6Sy3khfoPExzJgOQ3hXtul8JhCemvBqzOtmhlj2KdMZXTnmNB PAcLHINDYKjsikGbibVB/U/fOdZBwg0mz6VpZc9KXAK+qfvx6MELe7x7C5mwWPbO s8/pJ96IGYc0hUFvrGQlwgSVhaJ6ho= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 11 Jan 2019 11:52:01 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 11 Jan 2019 11:52:01 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006106010.msg; Fri, 11 Jan 2019 11:51:59 +0100 X-MDRemoteIP: 2001:470:1f09:495:6543:abdf:f040:b629 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Fri, 11 Jan 2019 11:51:59 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=191404dd5b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Fri, 11 Jan 2019 11:51:57 +0100 From: JORDI PALET MARTINEZ To: Benjamin Kaduk CC: The IESG , , , Message-ID: <35F9A19F-DC78-470F-B104-3BA764508D09@consulintel.es> Thread-Topic: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT) References: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> <16C30688-747B-4723-BBD7-FF82FCAA6A26@consulintel.es> <20190110223633.GS28515@kduck.mit.edu> In-Reply-To: <20190110223633.GS28515@kduck.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 Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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, 11 Jan 2019 10:52:07 -0000 Hi Benjamin, Responses below, in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Benjamin Kaduk Fecha: jueves, 10 de enero de 2019, 23:36 Para: JORDI PALET MARTINEZ CC: The IESG , , , Asunto: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition= -ipv4aas-13: (with DISCUSS and COMMENT) On Thu, Jan 10, 2019 at 05:43:32PM +0100, JORDI PALET MARTINEZ wrote: > Hi Benjamin, >=20 > Thanks again for your detailed review. >=20 > I'm already working in a draft for a new version including all the ni= ts that you mention (some already were corrected in -13). >=20 > Some clarifications to some of your comments. > =20 > Section 3.2 > =20 > TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI a= nd/or > API option to manually enable/disable each of the su= pported > transition mechanisms. > =20 > Do we really need to pick and name interfaces, or can we just say= "MUST > have a configuration interface"? >=20 > Yes, the point here is to make sure that at least there is a GUI and = CLI (or API). The idea is that the customer is able to buy a CE and later o= n use it in a different ISP. So, having both facilitate that, even in the c= ase of a manual configuration required by the user. Normally DHCP-based mec= hanisms should do it, and also is currently very common that both are alrea= dy supported, so not a big issue. =20 Er, do you require both GUI and CLI, or not? The current text only requires at least one. (But yes, I agree it's common to support both already, so this is not likely to be a burdensome requirement.) =20 Yes, the idea is "GUI and CLI" or "GUI and API" or all them. I was reading = that correctly, but may be (once more) is a problem between Spanish-English= ... What about: "The IPv6 Transition CE Router MUST have a GUI and either a CLI or API (or = both) to manually enable/disable each of the supported transition mechanism= s." =20 > =20 > Section 3.2.1 > =20 > If 464XLAT is > supported, it MUST be implemented according to [RFC6877]. [..= .] > =20 > Do we want to consider adding "or a successor document"? >=20 > I think if we do that, we could need doing that for every RFC ... tha= t's why we have documents updating previous ones, so I don't think so. =20 Well, another alternative is (as Ben suggests) to just not include this sentence at all. Which would of course also address my point here :) We have this text for every transition mechanism. The transition mechanisms= have "2/3" pieces. One is the transition mechanism itself, another one is = what is needed in the operator network, and then what is needed in the CE. = I think for clarity, even if looks like a repetition, we decided to keep us= ing the same wording on this that was used in RFC7084. For example, DS-Lite is the mechanism, AFTR is the operator part, B4 is the= CE part. If you look at the text (section 3.2.2), we are referring first t= o the overall DS-Lite, then we say that the CE must implement the B4 follow= ing what is said about that in the RFC. I still believe is good to keep that way. Thanks! Regards, Jordi ********************************************** 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 Jan 11 13:25: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 2E9D212958B; Fri, 11 Jan 2019 13:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.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 SifSSe4clESj; Fri, 11 Jan 2019 13:25:07 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750094.outbound.protection.outlook.com [40.107.75.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3416A128CE4; Fri, 11 Jan 2019 13:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DVZ2HOJMv3L1+cSx07bcbZmKVtOVVdfn5x9agKMmZX0=; b=aRN7v2tezW7tNQLZyKAFz/eeDPB8OTRS70aUsEXA9t5Pa6Kyf3DaqzJO8F7sThMXc1D1Ynmeki5PemsuMqZIpVZN7T5eyF9sATlJh+aaczEqlOPicDL8Xe/JUJ9LdEQoFT5JTqPZxukp4/T+ArfXMAV2Rd/VX21+LcMYtgbeZHc= Received: from CY4PR01CA0021.prod.exchangelabs.com (2603:10b6:903:1f::31) by BN6PR0101MB2947.prod.exchangelabs.com (2603:10b6:405:2c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.13; Fri, 11 Jan 2019 21:25:04 +0000 Received: from BY2NAM03FT058.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::207) by CY4PR01CA0021.outlook.office365.com (2603:10b6:903:1f::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.13 via Frontend Transport; Fri, 11 Jan 2019 21:25:04 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT058.mail.protection.outlook.com (10.152.85.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Fri, 11 Jan 2019 21:25:04 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0BLP0Zk001315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Jan 2019 16:25:02 -0500 Date: Fri, 11 Jan 2019 15:25:00 -0600 From: Benjamin Kaduk To: JORDI PALET MARTINEZ CC: , , The IESG , Message-ID: <20190111212500.GQ28515@kduck.mit.edu> References: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> <16C30688-747B-4723-BBD7-FF82FCAA6A26@consulintel.es> <20190110223633.GS28515@kduck.mit.edu> <35F9A19F-DC78-470F-B104-3BA764508D09@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <35F9A19F-DC78-470F-B104-3BA764508D09@consulintel.es> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(136003)(39860400002)(2980300002)(199004)(189003)(59124004)(33656002)(50466002)(8936002)(58126008)(6246003)(54906003)(106002)(956004)(8676002)(36906005)(316002)(55016002)(75432002)(86362001)(786003)(446003)(11346002)(4326008)(426003)(476003)(126002)(246002)(229853002)(47776003)(5660300001)(106466001)(53416004)(104016004)(478600001)(1076003)(7696005)(186003)(2486003)(76176011)(23676004)(356004)(26005)(305945005)(26826003)(336012)(66574012)(486006)(93886005)(2906002)(88552002)(2870700001)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR0101MB2947; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT058; 1:wEX0RjzUOioTQzJEp/qgAi/uqtNDOOxYVqLhK5qN4v5sPaY/32287LJeZ6aTGt6lpR8ze670QHEXwbmvhpVxNGY4wKC1fn75HlT/60bt4lkEvaLft6XYzYtiUjZQ0hXq X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f7132d8c-b4e8-49cd-b3bf-08d6780b40c1 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BN6PR0101MB2947; X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2947; 3:xNGcmHoXUcYMEx5Rodd0LSLkOI9iCMcxSR1MxjudEgRSi4/f0/D17n1LoLEM2a+hB8dK7zTpeKIlUxCWLmLlXJ6TOSB4TgUCdhRgCdksxnXAGQlJfP/d+F2Xu8d1MUlPHLlpgJ3uVklFKIOwkfndpS8+0bYekG/vqljPeXUzbY6FyBJRSrN3N15aX9joW7lglEDBjQ8IElbSmlaedhcGoGywCBbeuImx+gkxPxOwHV0TOZbv0uZFPz9+wqXNOIf+tmTTCvdGW/UhhO2A/CEkeDgg5IUS04h4frSh3IV54iO1NPDJtEApMtdwunyDtMjBf3kGsv/SRto1FK0fbfZzztUOjQe3KBqTxutEjLvwbqP0CU7vhw4mTOG43x3cBpM3; 25:nieD1QjgagnSrinwd8tKhIRGeVFrQrutIXjSuXrh7k1vCoDhWAEvIouO1c43v0K8kgrm2Cup3ESeSkjSSWkZRq+EkYkGB82lPcIwsgTWtjgVmMaOaZjcjwZNDZw2W64W9+Kgj57zNaF8AAq+4qVccvB31GxpiDsc7zghNmVmUqBnwqJlQcOpxv/RBMyxZgmQ/mBWLiI8abF530MhHhvcFKuCWnUheQDQJmM+2tW32sScM4LorlYNgfyjkKl/LvxVWbGgIXjVOgyKYNCu3CwmxwfStnGhVm/WTBuD/6+X38M0Log4AoMuQmYI4DZm5HO6wEwRyXadUujD0lJQFFKuyQ== X-MS-TrafficTypeDiagnostic: BN6PR0101MB2947: X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2947; 31:/8725mCvFUOuBTBS+n363dcApsmV4nYrQfU1EVXzo83Z1AMWHKj2lqj2q1/KRm5FYLSnwQaS6Y2kq2LYj+KYNLSrprcgjHks0KKJ6PynC1jR81wU30G+oBHYl3Wy+SKyveEcIO1CS94kAGgvHNd71K0qQQDtTZYzxKvnlHRAjFV7VDb9ehjM3avhQXMOcoqZ+S1Dd2jB4iKPt3AHtlrLFf4DC66OiWabQ1WLR8zfADM=; 20:bQObMZV6tikPjvHEW8A94D9n3ZP4Hhd79mhKDpAVB47FcO13SdQd0Irp/yVoUsklk7hSLI91ocCK/E7aDSzT8n5Kfw+Msu1k0ttocqllNRbRHl3pKyCvIvxftvJpioTb3P1XJrxWrx+orMJDaxwIc7CgnBmSdBw1fBekTAUzhW5cGNV7PqcZC5FCSKuUT/DxhZ9dgg7jIPF+IptcFqpJhaeR+lKRm1CX2HT6yn6Vtx38+NQErvwgvRUkG9jfD+kvKIVKKqMabiHVB6hDuX9cDw+XIutzgBnfZiCqBARz53S19L9dS58kXzCLV1UENeUSVkg31YnUZ+DpyzuF7hyGwTyiwChUYpQXYmHykLeKqvP+bymam8Aqh80naAFN5N30IsZN4M6aZlAIOimoi2zKJNH9sRngg7VSL9rtWxdF6cAFaS+CVkF+2lJpA6qy2qGYhg+uGMLq6fr7IQpD21LunEtNuqIE/O2Wvo4gwYMOWgcVnUQTkTWRCGhh9IXJfCad2fFNl49RAOm4gGsXAR9m6EU1RQ/jTdekg/qWR7lYuE/50orI7pcxRoNhVpupW5t8uEHz3I3TCyCun9/Xsi3sn89TZK9gE9uNl0hS9B+HNR4= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2947; 4:zretF75BuX8NKciv14L9s924JBej+zC54QeCau05mqubpQOD4nZzUnkQrpugIjCPi5PAwKTdhWPsXY7wXK79L0gqz5aXleV+UtONuow+bzG4k9BlnntfM6Ql7ByFKI22jWWxJAnp9h6ap1mD/hVYIjHF87TqT6Z932BduTJvzdi0SnhW9V3iYNSy6s5TsPXElSb5n+NIAN7JMDEEdFG6y4Alqg5NoLBztca10Jfca5qAwSPdcV5uN6GBF8fr4vTYuJZ8ubFSqTl9BFDklC/ouL/wIaGeKpTrnAtJbWCOy/UfFCPeJnBxE/CTD8wR7jP/ X-Forefront-PRVS: 09144DB0F7 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjAxMDFNQjI5NDc7MjM6anJJT3dLdGVFNDk4dXl1R3NndUVOMnJM?= =?utf-8?B?eWU5YWpDUHFhcXpRSjR3a3Q5VWp1WTBLbVJ0U09sellzbzdJMkFlK2NPdkl5?= =?utf-8?B?VGgrOGJzajZSK1BvblVZY0dwUUhHN01EZ282b3hwcGdFNk5seldGQjdCcm14?= =?utf-8?B?Y0hrUngzT1hzbHpNNkwyOXNaejc1cWVvUVdZd09QWGI4aWNLUDdYUEMzbHRV?= =?utf-8?B?N29iTmhteEhaYTg2Qnl5SGtCblBVeFJiejJhMkF6dmZpRCtEMDErcSszanR6?= =?utf-8?B?bm1vRlorZjZqdGQ1NjNTemJ0b1lqTWpGZm10anpmR0JESnpkN0JiYVdGQWli?= =?utf-8?B?TnJOSXkrRTVoN2E4dGJJdG82QkRyY2p1bmMwV2F3SUJKY0xqb2FaWXJ6eUNl?= =?utf-8?B?K25NZnp5V3hkUDBFZ2RvTy9IYUJmT1VlUVlrVnRtZEFURkt2TjN5YXNhNENP?= =?utf-8?B?Y0tvaDQ5TllNc2Q5Ty9QUVZHMkJjcGpsb1FOTkp4TmMzTHZQSWcwMTlDZHh2?= =?utf-8?B?S0pyeGcvOVhWVGhEQm0wbko2dmFCVUFPcVd3K1piWkVMRHNxK3R2QnN1MURr?= =?utf-8?B?NTFoenNWVWoxUTlVb3NwVFNwcjF4ejZyMnJTTE94WTB5NGNRRmxTNklYL0t0?= =?utf-8?B?Y3cxOG5WSzhPWjU5aW4wL1JBNk5BeXo2dWo0N0x6WHVFa2Q0YjRJVi9qRGZ1?= =?utf-8?B?cGFORitsUHIyK0tvNmwyeCs0SzczSjJIcHNNRDRINUh4cU9EWllNZnZ2eW9u?= =?utf-8?B?VXpzWDhBZjB3V2xIMXp4TkpHeCtOUG9vQ3kwMWdGTFBGeVE2SnY3L2Q1ajdP?= =?utf-8?B?SThicHZDUExLRXpCbm1DNldTWDM3bGFRd2ZnV1FXODdKdzMzRVQyVHkyclZz?= =?utf-8?B?cWFxZnB2alo1OVJTK3Q4YXRzN2JVR2wrcXNTekpqaE5SbWlBYk9SZ2VKdWpP?= =?utf-8?B?aU9vZ3JlWmJJNnVVL2hna3N1WWk4NG1lTXJuRCtFTi8zTFQzSG5GUlQ0ZUUw?= =?utf-8?B?Y29jVzlKbGgvaVdIUjAyT3NFU0ppQ3BOSXhKRjlFTVp1dkN3a21rbzZReEJY?= =?utf-8?B?NFdDQ0hDV0lTVTdTaDRERHN1MXFsSVdvdWVDTm4vZy9QNGdMV3ZoMzRKWHBi?= =?utf-8?B?RDBVZ0R2SmM3b2xhSmgxdWkwdzczNTVPcGZEK2c3dUdvaFI1Qmd4WDh3VVpp?= =?utf-8?B?ZkRrTFZOek55b1hsWlVoNDZzOUxPWWNDSmkzSVZ0Q1JRcEhoUnBEUE5yWllj?= =?utf-8?B?MzNxVXAzTlVqc3c1dGQySWJKVzRSWGtrWUJqUm5TdzRCaXFzQkV0c3ZrMy8r?= =?utf-8?B?Tmw1RmcvWGs5RFNzNmVIc09zczd4ZlhxRHlKK1pKblUxclNYUzFBVTNwY1g5?= =?utf-8?B?YTR2ZFFRUEhIV3FNcmF2Vk95eGU2ak1DUGEydjdoeXVPS3pybUhFcktaUTdK?= =?utf-8?B?NkMzSHR0TkFYSnRFWU12QmwwQzhlQ29UZHV4Vm1icTAyZFdOdzg2Qmh2aVlG?= =?utf-8?B?eTdPUXI3ajJIeHExenJxTlBLSzBPUmdOSjN0TVRaVGRHbXVWY2hFZVFKWm9V?= =?utf-8?B?Y2c1MUFTclFLNkQ3d0NkLy92MURXcXRXTm4zN2lBKysyejAzV0poaUJpVlFy?= =?utf-8?B?N3hXUnBvMUFuT1p3YVQ2R0V2eUF0MUMydDlENFVwZ2h4SGpIUkRWWUVYZ1E9?= =?utf-8?Q?=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 8yTKeietVhr8HM31ghRN6X3E6k73gRMfa16LIL3jccbsOo7BbiW3NJqRcRYgRmcKOk7C6sL2mtqiT0LGdZkGcPfJTx15mNdz+7L4eYIiGh89tdksEOxKmhT2taHpxCPAXHc/EZTLKLDABfBLNx8FEoeD6SUYYAmfSGXmdvb5+RTKlHMivpcwmCeWC/OjOVarI0sVv+3okwHEjFqX4iEmXubXJUbyA0b2JQLrupvOrJW8d9GsGUbtbt0levmz7siZsHRuOZhJ+WZw+A+2sGz7C+hNuFb5C3Dfp2+F1gnEG9QFei11E+i+XrpIsFtqrjJ8Q+GQ14xoFLYFV1lRTZCTW/9K6nMMP6AL6omk19O/7S3l0nPk03/S6VD2HjPtoI3y7HWFWNl5mnVUSRS7nM77w9+hWP8ygkekNuMnU1q0bN4= X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2947; 6:7w/JQ3QzDTMcL6KOL35pNWFos3ptwRE8yV10ComIBFEJ+0wxRH6YKzOSIts5DWysC9jWY7ZhrxfQ1UNE0h2R3L2pehiwqpt5G/ndzooO74TE7Dcn9YJXZ0honcoZ9vZaToQRcoi5NVq+ISKUMIJU50D7p59+c+cl0hfd9nzC1LDHISZNJ0C0QXfpFQBtkbYcAjspF+/jn0JTYUszlJMx7VoNl8YN+O7UFkEFcCNdCrEta7F2uJTz1BMx+2gp3zndrz66qOuwXoeOJbvITPzOTVfE13ajFbf7ywmW20voAqiusvTFRTJKfHTXqr3fRm6Ybgj0jbpb5RkeSKCui2szkgYcpLNTmgeSSwzrUvYS9wnXRTxNTFwTeaXWcb5Bhmpc2nRTG2tewDIC85Np9pFVJI7IrSuuYbJv1OsbtogH9D/UTLOivzuv9nhB5qfxPGREyIfRgCqJ6QJdVXQhUqrbZw==; 5:TiRqVgfLa0eo7WgPNlq7ntqcRcsgdq3WOg4RJLwpZhZnyu0nXXyF9Qgzur+asl5Im5ushDaXgkMJr93k4Bg8v2fID8QosGOLc1mtXnPc2bstAUwjLRPtPhWztDuXmD2/DMtszX78FULf7TrbtZmLL7f8vzovImy1DgIcfKcTsGKNHUMJpyil+gF8gYawDMQG71oypV22AemLjFOh5s6vCA==; 7:IfBjedzzxUJLfg4C/EqSK6S4RgsXj2RiHpMylyvQv8dZzJguFNQVBC61inrF3gApb3euv30YZX6CaELEi/uwAAXfDbx9mPMqaT99S2fLlpb/MuBlDRJgJ0oTmAXlj7Ws+45wpfphYzCoxdj88p6ogw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2019 21:25:04.2007 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f7132d8c-b4e8-49cd-b3bf-08d6780b40c1 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR0101MB2947 Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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, 11 Jan 2019 21:25:09 -0000 On Fri, Jan 11, 2019 at 11:51:57AM +0100, JORDI PALET MARTINEZ wrote: > Hi Benjamin, > > Responses below, in-line. > > Regards, > Jordi > > > > -----Mensaje original----- > De: Benjamin Kaduk > Fecha: jueves, 10 de enero de 2019, 23:36 > Para: JORDI PALET MARTINEZ > CC: The IESG , , , > Asunto: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT) > > On Thu, Jan 10, 2019 at 05:43:32PM +0100, JORDI PALET MARTINEZ wrote: > > Hi Benjamin, > > > > Thanks again for your detailed review. > > > > I'm already working in a draft for a new version including all the nits that you mention (some already were corrected in -13). > > > > Some clarifications to some of your comments. > > > > Section 3.2 > > > > TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or > > API option to manually enable/disable each of the supported > > transition mechanisms. > > > > Do we really need to pick and name interfaces, or can we just say "MUST > > have a configuration interface"? > > > > Yes, the point here is to make sure that at least there is a GUI and CLI (or API). The idea is that the customer is able to buy a CE and later on use it in a different ISP. So, having both facilitate that, even in the case of a manual configuration required by the user. Normally DHCP-based mechanisms should do it, and also is currently very common that both are already supported, so not a big issue. > > Er, do you require both GUI and CLI, or not? The current text only > requires at least one. (But yes, I agree it's common to support both > already, so this is not likely to be a burdensome requirement.) > > Yes, the idea is "GUI and CLI" or "GUI and API" or all them. I was reading that correctly, but may be (once more) is a problem between Spanish-English ... > > What about: > "The IPv6 Transition CE Router MUST have a GUI and either a CLI or API (or both) to manually enable/disable each of the supported transition mechanisms." That says what you want, yes. > > > > Section 3.2.1 > > > > If 464XLAT is > > supported, it MUST be implemented according to [RFC6877]. [....] > > > > Do we want to consider adding "or a successor document"? > > > > I think if we do that, we could need doing that for every RFC ... that's why we have documents updating previous ones, so I don't think so. > > Well, another alternative is (as Ben suggests) to just not include this > sentence at all. Which would of course also address my point here :) > > We have this text for every transition mechanism. The transition mechanisms have "2/3" pieces. One is the transition mechanism itself, another one is what is needed in the operator network, and then what is needed in the CE. I think for clarity, even if looks like a repetition, we decided to keep using the same wording on this that was used in RFC7084. > > For example, DS-Lite is the mechanism, AFTR is the operator part, B4 is the CE part. If you look at the text (section 3.2.2), we are referring first to the overall DS-Lite, then we say that the CE must implement the B4 following what is said about that in the RFC. > > I still believe is good to keep that way. Well, this is a non-blocking comment, so I can't get in your way. -Benjamin From nobody Mon Jan 14 01:55:27 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 F256B130FC4; Mon, 14 Jan 2019 01:55:18 -0800 (PST) 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.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <154745971893.4698.6645084889774098803@ietfa.amsl.com> Date: Mon, 14 Jan 2019 01:55:18 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-14.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, 14 Jan 2019 09:55:19 -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 : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-14.txt Pages : 24 Date : 2019-01-14 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or by vendors who sell through the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is necessary because there aren't sufficient IPv4 addresses available for every possible customer/device. However, devices or applications in the customer LANs (Local Area Networks) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-14 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-14 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 Jan 14 01:57: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 CFE2D130FC4; Mon, 14 Jan 2019 01:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuPihGBCPqX8; Mon, 14 Jan 2019 01:56:59 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7528812896A; Mon, 14 Jan 2019 01:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547459816; x=1548064616; 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=SfABPpnWlhkGjd1lfhyYh+vKrujnOZ/DeRzc/1oqYWI=; b=kinefhtksbtP3 bm8LpBUdkphRTj/sjbY2alAW0McQiV0eLV3MPez1UBK76dcjWdrdKD0zE39ijv3S GKUwMuKUj2yAdEOj6jJsKZbJEKqmsFTpkAarfjGA8pa2gsvoQKap0RhxvuHuWSqm wsyNjrHLNUpRUWSizqLt7PiAQo3Chw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 14 Jan 2019 10:56:56 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 14 Jan 2019 10:56:56 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006110207.msg; Mon, 14 Jan 2019 10:56:55 +0100 X-MDRemoteIP: 2001:470:1f09:495:11dc:eed9:dd0f:218c X-MDHelo: [10.10.10.139] X-MDArrival-Date: Mon, 14 Jan 2019 10:56:55 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1917413931=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 14 Jan 2019 10:56:54 +0100 From: JORDI PALET MARTINEZ To: Benjamin Kaduk CC: , , The IESG , Message-ID: Thread-Topic: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT) References: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> <16C30688-747B-4723-BBD7-FF82FCAA6A26@consulintel.es> <20190110223633.GS28515@kduck.mit.edu> <35F9A19F-DC78-470F-B104-3BA764508D09@consulintel.es> <20190111212500.GQ28515@kduck.mit.edu> In-Reply-To: <20190111212500.GQ28515@kduck.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 Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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: Mon, 14 Jan 2019 09:57:02 -0000 Thanks Bejamin, I just uploaded a new version resolving all the discuss and comments. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Benjamin Kaduk Fecha: viernes, 11 de enero de 2019, 22:25 Para: JORDI PALET MARTINEZ CC: , = , The IESG , Asunto: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition= -ipv4aas-13: (with DISCUSS and COMMENT) On Fri, Jan 11, 2019 at 11:51:57AM +0100, JORDI PALET MARTINEZ wrote: > Hi Benjamin, >=20 > Responses below, in-line. >=20 > Regards, > Jordi > =20 > =20 >=20 > =EF=BB=BF-----Mensaje original----- > De: Benjamin Kaduk > Fecha: jueves, 10 de enero de 2019, 23:36 > Para: JORDI PALET MARTINEZ > CC: The IESG , , , > Asunto: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-tran= sition-ipv4aas-13: (with DISCUSS and COMMENT) >=20 > On Thu, Jan 10, 2019 at 05:43:32PM +0100, JORDI PALET MARTINEZ wr= ote: > > Hi Benjamin, > >=20 > > Thanks again for your detailed review. > >=20 > > I'm already working in a draft for a new version including all = the nits that you mention (some already were corrected in -13). > >=20 > > Some clarifications to some of your comments. > > =20 > > Section 3.2 > > =20 > > TRANS-2: The IPv6 Transition CE Router MUST have a GUI,= CLI and/or > > API option to manually enable/disable each of = the supported > > transition mechanisms. > > =20 > > Do we really need to pick and name interfaces, or can we ju= st say "MUST > > have a configuration interface"? > >=20 > > Yes, the point here is to make sure that at least there is a GU= I and CLI (or API). The idea is that the customer is able to buy a CE and l= ater on use it in a different ISP. So, having both facilitate that, even in= the case of a manual configuration required by the user. Normally DHCP-bas= ed mechanisms should do it, and also is currently very common that both are= already supported, so not a big issue. > =20 > Er, do you require both GUI and CLI, or not? The current text on= ly > requires at least one. (But yes, I agree it's common to support = both > already, so this is not likely to be a burdensome requirement.) > =20 > Yes, the idea is "GUI and CLI" or "GUI and API" or all them. I was re= ading that correctly, but may be (once more) is a problem between Spanish-E= nglish ... >=20 > What about: > "The IPv6 Transition CE Router MUST have a GUI and either a CLI or AP= I (or both) to manually enable/disable each of the supported transition mec= hanisms." =20 That says what you want, yes. =20 > > =20 > > Section 3.2.1 > > =20 > > If 464XLAT= is > > supported, it MUST be implemented according to [RFC6877]= . [....] > > =20 > > Do we want to consider adding "or a successor document"? > >=20 > > I think if we do that, we could need doing that for every RFC .= .. that's why we have documents updating previous ones, so I don't think so= . > =20 > Well, another alternative is (as Ben suggests) to just not includ= e this > sentence at all. Which would of course also address my point her= e :) >=20 > We have this text for every transition mechanism. The transition mech= anisms have "2/3" pieces. One is the transition mechanism itself, another o= ne is what is needed in the operator network, and then what is needed in th= e CE. I think for clarity, even if looks like a repetition, we decided to k= eep using the same wording on this that was used in RFC7084. >=20 > For example, DS-Lite is the mechanism, AFTR is the operator part, B4 = is the CE part. If you look at the text (section 3.2.2), we are referring f= irst to the overall DS-Lite, then we say that the CE must implement the B4 = following what is said about that in the RFC. >=20 > I still believe is good to keep that way. =20 Well, this is a non-blocking comment, so I can't get in your way. =20 -Benjamin =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 Jan 14 02: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 E5588130FC7; Mon, 14 Jan 2019 02:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dZHqyCV4pl8; Mon, 14 Jan 2019 02:01:54 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CD012896A; Mon, 14 Jan 2019 02:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547460111; x=1548064911; 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=lzAbLyrmlG/ZElJVTokIM4Vqc7V95OLiVK9XRCmAZvw=; b=txXjj28M5eAyB pkgiICfzsjsrWje6CAJxRyX7xRuZ2KH4Yv1Z+GTvQd1Sr4v4C0WJcX42ze2/EbYt de7syiXrnK3yiFxrSt4YPf0/aTgpEyU2h1sxc7UFIH8uNZwD6X7wu73W7rRuCie6 KtJoTFA34hh20mTAbHdxhXLiKUWie4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 14 Jan 2019 11:01:51 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 14 Jan 2019 11:01:51 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006110216.msg; Mon, 14 Jan 2019 11:01:50 +0100 X-MDRemoteIP: 2001:470:1f09:495:11dc:eed9:dd0f:218c X-MDHelo: [10.10.10.139] X-MDArrival-Date: Mon, 14 Jan 2019 11:01:50 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1917413931=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 14 Jan 2019 11:01:48 +0100 From: JORDI PALET MARTINEZ To: Ole Troan , Lorenzo Colitti CC: "v6ops@ietf.org WG" , , , The IESG , Suresh Krishnan Message-ID: <09AE4396-DFB6-4994-837B-6F18C56FC95B@consulintel.es> Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) References: <154700897323.25519.3473287235255788469.idtracker@ietfa.amsl.com> <751B33D3-09CF-447B-A61A-814CA5260308@employees.org> In-Reply-To: <751B33D3-09CF-447B-A61A-814CA5260308@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS) 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, 14 Jan 2019 10:02:01 -0000 Hi all, We just submitted a new version, which I think address all the discuss and = comments (some of them were clarifications that were provided by email resp= onses to the IESG). This included removing the reference to RFC8115 as a DHCP method to obtain = the NAT64 prefix. That means that this can only be done by PCP/RFC7225 (if available) or RFC7= 050. https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Ole Troan Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 11:22 Para: Lorenzo Colitti CC: "v6ops@ietf.org WG" , , , The IESG , JORDI PAL= ET MARTINEZ , Suresh Krishna= n Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transitio= n-ipv4aas-12: (with DISCUSS) > It *is* contradicting the standard. The standard says that the uPrefi= x64 is "to be used in SSM mode for constructing the IPv4-embedded IPv6 addr= esses representing the IPv4 multicast sources in the IPv6 domain". This doc= ument says that it should be used as a unicast NAT64 prefix. =20 I must agree with Lorenzo here. This is not the right document to specify a new NAT64 prefix discovery = mechanism. =20 Ole =20 =20 >=20 > On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ wrote: > Hi Lorenzo, >=20 > =20 >=20 > Yes, I recall that very well. The only objections where from you and = from David. >=20 > =20 >=20 > We are using a format that is not defined in RFC8115 for something el= se. It is a trick, right, but is not contradicting neither changing any sta= ndard, because the configuration of the two zeroed fields. >=20 >=20 > Regards, >=20 > Jordi >=20 > =20 >=20 > =20 >=20 > =20 >=20 > De: v6ops en nombre de Lorenzo Colitti > Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 10:55 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org WG" , , , Suresh Krishnan , The IESG > Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-tra= nsition-ipv4aas-12: (with DISCUSS) >=20 > =20 >=20 > On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ wrote: >=20 > So, in summary, implementing or not multicast support, is not related= to the implementation of RFC8115 (just a simple DHCPv6 option) which is us= ed here for discovering the NAT64 prefix and allowing the prioritization of= the transition mechanisms, avoiding updating other IETF documents and wait= ing for the IETF to approve a new standard DHCPv6 option specific for the N= AT64. >=20 > =20 >=20 > Jordi: per my recollection, IIRC the reason there is no DHCPv6 option= to specify the NAT64 prefix is that there was no consensus to define a way= to provision the NAT64 prefix via DHCPv6. (In fact, I think I remember you= presenting such an option a few IETFs ago and receiving pretty negative op= inions on it from the mike line.) If that's the case, then it's not appropr= iate to ignore that lack of consensus and essentially define such an option= anyway. >=20 > =20 >=20 > It's not even clear to me how an informational document (which this i= s) can take RFC 8115 (which is a standards track document) and redefine the= uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines uPrefix= 64 as not representing standard unicast addresses: >=20 > =20 >=20 > uPrefix64: this field identifies the IPv6 unicast prefix to be us= ed >=20 > in SSM mode for constructing the IPv4-embedded IPv6 addresses >=20 > representing the IPv4 multicast sources in the IPv6 domain. >=20 > =20 >=20 > Standards track documents have precedence over informational document= s, right? If so, then even if this informational document is published as i= s, the text will effectively be a no-op because it contradicts RFC 8115. >=20 > _______________________________________________ v6ops mailing list v6= ops@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 >=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =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 Tue Jan 15 14:32:24 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 01B38128CF3; Tue, 15 Jan 2019 14:32:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154759153599.10731.5698492684665563607.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2019 14:32:15 -0800 Archived-At: Subject: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-transition-ipv4aas-14: (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: Tue, 15 Jan 2019 22:32:17 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-14: 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-transition-ipv4aas/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. Here is my original COMMENT: == Section 1 == OLD This ensures that remote IPv4-only services continue to be accessible, from an IPv6-only Internet Service Provider access network (typically referred as WAN - Wide Area Network, even if in some cases it may be metropolitan, regional, etc.), from both, IPv4-only and IPv6-only applications or devices in the LAN side. NEW This ensures that remote IPv4-only services continue to be accessible from an IPv6-only Internet Service Provider (ISP) access network from both IPv4-only and IPv6-only applications and devices on the LAN side. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if in some cases they may be metropolitan or regional. (Then you could deleted the parenthetical "(Internet Service Providers)" in the sentence below Figure 1.) It seems odd that Figure 1 appears in Section 1 but isn't referenced in the text until Section 12. I think you need a sentence in this section to describe what is depicted in the figure or why it is there, or you need to remove the figure. s/devices or applications/devices and applications/ == Section 3.2 == s/an automated IPv6 transition mechanism provisioning/automated IPv6 transition mechanism provisioning/ s/per interface/per interface/ Would suggest dropping "(which may depend on each transition mechanism)" since it makes the sentence confusing and doesn't add anything. == Section 3.2.1 == OLD If DNS64 [RFC6147] is not used, or not trusted, as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer, then the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115], which also can be used if the service provider uses DNS64 [RFC6147]. NEW It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]. These can also be used if the service provider uses DNS64. == Section 7 == I would suggest starting this section with "At the time of this writing, ..." == Section 12 == The text that refers to Figure 1 I think is meant to refer to Figure 2. Or if not, text is needed to describe Figure 2. From nobody Tue Jan 15 23: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 61AD01310EC; Tue, 15 Jan 2019 23:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G07G8xKhUbM; Tue, 15 Jan 2019 23:50:43 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDB31310EF; Tue, 15 Jan 2019 23:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547625039; x=1548229839; 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=0Q8IJB95YE2AwSXnJh4QbLxQgwpiQrQgDHXFZzMOfSo=; b=GnmaIc8vMSJz3 HO93fOtVos0n13S5Eh4YOPYLJUBiR18OS9SJZk80xpoXh0aERCgfQVTdLjrl5vAm 42cc3LzEbb9Vkg60ZyWcgI6HRktFGOOAOncqLE+TIgHD3svkoa/iu4OTs6y5qc4+ PKpBpK6b+TIrtbmruHb7L3jF6GeOmI= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 16 Jan 2019 08:50:39 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 16 Jan 2019 08:50:39 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006112280.msg; Wed, 16 Jan 2019 08:50:38 +0100 X-MDRemoteIP: 2001:470:1f09:495:550c:ed34:c18f:960 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 16 Jan 2019 08:50:38 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19191f25e2=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 16 Jan 2019 08:50:36 +0100 From: JORDI PALET MARTINEZ To: Alissa Cooper , The IESG CC: , , Message-ID: <2FB45C37-0D5A-4EC1-842A-2E4324BD8FD0@consulintel.es> Thread-Topic: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-transition-ipv4aas-14: (with COMMENT) References: <154759153599.10731.5698492684665563607.idtracker@ietfa.amsl.com> In-Reply-To: <154759153599.10731.5698492684665563607.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-transition-ipv4aas-14: (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, 16 Jan 2019 07:50:46 -0000 Hi Alissa, Thanks! Just to confirm that your comments were addressed as well in -14. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alissa Cooper Fecha: martes, 15 de enero de 2019, 23:33 Para: The IESG CC: , = , Asunto: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-transition= -ipv4aas-14: (with COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-14: 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-transition-ipv4aas/ =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 Thanks for addressing my DISCUSS. Here is my original COMMENT: =20 =3D=3D Section 1 =3D=3D =20 OLD This ensures that remote IPv4-only services continue to be accessible, from an IPv6-only Internet Service Provider access network (typicall= y referred as WAN - Wide Area Network, even if in some cases it may be metropolitan, regional, etc.), from both, IPv4-only and IPv6-only applications or devices in the LAN side. =20 NEW This ensures that remote IPv4-only services continue to be accessible from an IPv6-only Internet Service Provider (ISP) access network fro= m both IPv4-only and IPv6-only applications and devices on the LAN side. Th= ese ISP access networks are typically referred to as Wide Area Networks (WAN= s), even if in some cases they may be metropolitan or regional. =20 (Then you could deleted the parenthetical "(Internet Service Providers)= " in the sentence below Figure 1.) =20 It seems odd that Figure 1 appears in Section 1 but isn't referenced in= the text until Section 12. I think you need a sentence in this section to d= escribe what is depicted in the figure or why it is there, or you need to remov= e the figure. =20 s/devices or applications/devices and applications/ =20 =3D=3D Section 3.2 =3D=3D =20 s/an automated IPv6 transition mechanism provisioning/automated IPv6 tr= ansition mechanism provisioning/ =20 s/per interface/per interface/ =20 Would suggest dropping "(which may depend on each transition mechanism)= " since it makes the sentence confusing and doesn't add anything. =20 =3D=3D Section 3.2.1 =3D=3D =20 OLD If DNS64 [RFC6147] is not used, or not trusted, as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer, the= n the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115], which also can be used if the service provider uses DNS64 [RFC6147]. =20 NEW It may be the case that the service provider does not use or does not t= rust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behin= d the CE) may be modified by the customer. In that case, the service provider= may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]= . These can also be used if the service provider uses DNS64. =20 =3D=3D Section 7 =3D=3D =20 I would suggest starting this section with "At the time of this writing= , ..." =20 =3D=3D Section 12 =3D=3D =20 The text that refers to Figure 1 I think is meant to refer to Figure 2.= Or if not, text is needed to describe Figure 2. =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 Jan 24 01:11: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 3646D1310CB for ; Thu, 24 Jan 2019 01:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQQu7w3zmDC2 for ; Thu, 24 Jan 2019 01:11:42 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A161310CC for ; Thu, 24 Jan 2019 01:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1548321100; x=1548925900; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=VzEEwREK9/V1YVy7t1ey4 v1Gq4tZiApnKy9VcgzQoug=; b=C/aqkR7ysUsfA7jQ+mL9Fg2O7xylp5P5b0f4E HwBze1YR7d0tXndES2yOt18YvpGEOPrp2aRZzfKi7m/Y3senbbW9jLhRXZkPH9Ad dRwO61nRtPmzP9gaML6pftxHG/jKxYFw/i0uDeF7W5ZsohuOLPke7rNsoXZK1+SM m4yajI= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 24 Jan 2019 10:11:40 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 24 Jan 2019 10:11:39 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006123104.msg for ; Thu, 24 Jan 2019 10:11:38 +0100 X-MDRemoteIP: 2001:470:1f09:495:4509:9d6:a781:b4c1 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Thu, 24 Jan 2019 10:11:38 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1927a7aef1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Thu, 24 Jan 2019 10:11:36 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: <54D2FE61-3B32-471C-81EB-658E55ACC4D0@consulintel.es> Thread-Topic: question to the WG about draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas 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, 24 Jan 2019 09:11:46 -0000 Hi all, Sorry the long email, but it needs to be explained in detail so v6ops folks can understand it and provide inputs. As part of the IESG telechat where this document was evaluated, it was raised a discuss regarding using RFC8115 in a way that introduces a "trick" to provide a DHCP option for a NAT64 prefix. After hearing the comments in the list, we decided to remove it, but we still need a way to make sure that 464XLAT/NAT64 can be prioritized as well as the other mechanisms, so the ISP has control over it. Our suggested approach was to keep using RFC8026 for all the mechanisms. RFC8026 requires a *top-level Option Request* in order to respond with the S46 option, which define the priority of the mechanisms. We didn't realize about that before because it was "intrinsically there" while we had RFC8115. Because we don't have an explicit DHCP option for configuring the NAT64, it means the option code for NAT64/464XLAT (113, which was already defined for an IPv6 /64 prefix, but we are asking IANA to include in the RFC8026 defined table just for signaling the priority) will not be provided unless the CE ask via DHCP for the configuration of other transition mechanisms. In the opinion of the document co-authos, this is fine, because precisely we expect that the CE supports several (hopefully all the 5). So, in this case (let's call this OPTION A), the behavior will be: 1) CE get the configuration parameters for all the mechanisms (including a NAT64 prefix via PCP or RFC7050, and the other 4 by means of DHCP). 2) As part of the request for DHCP configurable mechanism, the CE will ask for S46 priority. If NAT64 is available in the ISP, the S46 will also contain the 113. 3) As a result, the CE can follow RFC8026 to decide which one match the ISP preference with what the CE can "use". What is the issue? If the CE only supports 464XLAT, then the CE must be forced to anyway, ask for "another" DHCPv6 configurable mechanism and ignore that information, but use the S46 response to check if the ISP supports NAT64. Not an issue, in our opinion. If the ISP only supports 464XLAT, then is forced to anyway, respond to the DHCPv6 request for configuration options of all the other 4 mechanisms (so this will work in any case despite "what" the CE is supporting), but in the S46 response, will include only the 113, to signal that *only* supports NAT64. Again, not an issue in our opinion. It is just a matter of having some text in the document that explains this workaround because of the lack of explicit DHCPv6 configuration option for NAT64. This workaround keeps the door open to a future possible DHCPv6 option for NAT64 and we think is not contradicting RFC8026. **** While we don't think it breaks anything, RFC8026 authors believe is contradicting RFC8026 (we still don't see how or if it a minor detail in the text, that could be updated with an errata or it requires an RFC8026-bis, etc.). So the question here. Do the WG believe this is fine? Or somebody can explain if that will break anything/contradicting RFC8026? OPTION B Exclude 464XLAT from the stateless "priority" setup that allows RFC8026, by setting it on "top of it" (higher priority). So, if the NAT64 prefix is available (by means of PCP or RFC7050), the CE will just configure it, because the ISP is telling him "I've a NAT64 for you, don't care about other options". This just works, but it forces an ISP to make sure that only the customers that ISP wants to use the NAT64 are able to identify it (only in case, they have different "customer" groups with different mechanisms). If, in the future, we define a DHCP option for NAT64, it forces the ISP to not provide the NAT64 by means of PCP neither RFC7050. A configuration mistake in the ISP network regarding who is getting and what for S46, will still allow the customers to use the NAT64. OPTION C Similar to b, but having the 464XLAT/NAT64 with the *lower* priority. In this case, as well, it will work, but it forces the ISP to make sure that for those customers that the ISP wants they use the NAT64, the S46 options must not return anything, otherwise the CE will never use the 464XLAT. So a mistake with the S46 may disallow customers using the NAT64. If, in the future, we define a DHCPv6 option for NAT64, it will just work as well. Of course, in all the 3 options, there may be other things to consider, but we think it is not possible to predict all them. All them depend on "if we define in the future a DHCPv6 option for NAT64, we will need to update the firmware of the CEs to support that, so it is safe to assume that we may need to revise at that point as well RFC8026 and possibly draft-ietf-v6ops-transition-ipv4aas ...". Co-authors take: Option A is fine, unless we can understand why it is contradicting RFC8026, then option B, unless we agree to start the work to update RFC8026 to support NAT64 someway (with or without a new DHCPv6 option), in which case, option C makes more sense. Please, let us know what do you think, and specially if you see that the procedure specified as OPTION A, is fine, in which case the issue is resolved. Thanks! Regards, Jordi ********************************************** 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 Thu Jan 24 01:38: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 530DB1310E4 for ; Thu, 24 Jan 2019 01:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 dOQTIq9IwAmG for ; Thu, 24 Jan 2019 01:38:12 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF9F1310E5 for ; Thu, 24 Jan 2019 01:38:12 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 43lcXL3D3nzBrkH; Thu, 24 Jan 2019 10:38:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 43lcXL20xJzBrLc; Thu, 24 Jan 2019 10:38:10 +0100 (CET) Received: from OPEXCAUBM32.corporate.adroot.infra.ftgroup (10.114.13.48) by OPEXCLILM33.corporate.adroot.infra.ftgroup (10.114.31.58) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 24 Jan 2019 10:38:10 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Thu, 24 Jan 2019 10:38:09 +0100 From: To: JORDI PALET MARTINEZ , "v6ops@ietf.org WG" Thread-Topic: question to the WG about draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUs8ThoVfPzvg3h0yexWanHUj0i6W+I++g Date: Thu, 24 Jan 2019 09:38:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0D0F2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <54D2FE61-3B32-471C-81EB-658E55ACC4D0@consulintel.es> In-Reply-To: <54D2FE61-3B32-471C-81EB-658E55ACC4D0@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas 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, 24 Jan 2019 09:38:15 -0000 Hi Jordi,=20 The problem with option A is that the candidate list will be set by 8026 us= ing DHCP options. So, even if you return 113 in the priority list, xlat won= 't be added to the candidate list because no DHCP option for xlat is actual= ly returned. RFC8026 can be relaxed to allow for other sources to fed the c= andidate list, but that is another piece of work. One comment about options B and C: These options are not about "Exclude 464= XLAT from the stateless "priority" setup that allows RFC8026", but about re= moving the IANA text asking to add 113 to the S46 priority list. xlat can b= e added to the priority list if a dhcp option is defined for it. My take is to pick option C (with the clarification made above) for the fol= lowing reasons:=20 * If a dhcp option is defined in the future, the codepoint of that option w= ill be included in the S46 priority list and normal 8026 processing will be= followed. * If a (stale) method is still present in the network to retrieve the prefi= x by other means, the priority set by the provider in S46 priority list wil= l be followed because the default priority of xlat as set by draft-ietf-v6o= ps-transition-ipv4aas won't win.=20 Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET MA= RTINEZ > Envoy=E9=A0: jeudi 24 janvier 2019 10:12 > =C0=A0: v6ops@ietf.org WG > Objet=A0: [v6ops] question to the WG about draft-ietf-v6ops-transition-ip= v4aas >=20 > Hi all, >=20 > Sorry the long email, but it needs to be explained in detail so v6ops fol= ks > can understand it and provide inputs. >=20 > As part of the IESG telechat where this document was evaluated, it was ra= ised > a discuss regarding using RFC8115 in a way that introduces a "trick" to > provide a DHCP option for a NAT64 prefix. >=20 > After hearing the comments in the list, we decided to remove it, but we s= till > need a way to make sure that 464XLAT/NAT64 can be prioritized as well as = the > other mechanisms, so the ISP has control over it. >=20 > Our suggested approach was to keep using RFC8026 for all the mechanisms. >=20 > RFC8026 requires a *top-level Option Request* in order to respond with th= e > S46 option, which define the priority of the mechanisms. We didn't realiz= e > about that before because it was "intrinsically there" while we had RFC81= 15. >=20 > Because we don't have an explicit DHCP option for configuring the NAT64, = it > means the option code for NAT64/464XLAT (113, which was already defined f= or > an IPv6 /64 prefix, but we are asking IANA to include in the RFC8026 defi= ned > table just for signaling the priority) will not be provided unless the CE= ask > via DHCP for the configuration of other transition mechanisms. >=20 > In the opinion of the document co-authos, this is fine, because precisely= we > expect that the CE supports several (hopefully all the 5). >=20 > So, in this case (let's call this OPTION A), the behavior will be: >=20 > 1) CE get the configuration parameters for all the mechanisms (including = a > NAT64 prefix via PCP or RFC7050, and the other 4 by means of DHCP). >=20 > 2) As part of the request for DHCP configurable mechanism, the CE will as= k > for S46 priority. If NAT64 is available in the ISP, the S46 will also con= tain > the 113. >=20 > 3) As a result, the CE can follow RFC8026 to decide which one match the I= SP > preference with what the CE can "use". >=20 > What is the issue? If the CE only supports 464XLAT, then the CE must be > forced to anyway, ask for "another" DHCPv6 configurable mechanism and ign= ore > that information, but use the S46 response to check if the ISP supports > NAT64. Not an issue, in our opinion. >=20 > If the ISP only supports 464XLAT, then is forced to anyway, respond to th= e > DHCPv6 request for configuration options of all the other 4 mechanisms (s= o > this will work in any case despite "what" the CE is supporting), but in t= he > S46 response, will include only the 113, to signal that *only* supports > NAT64. Again, not an issue in our opinion. >=20 > It is just a matter of having some text in the document that explains thi= s > workaround because of the lack of explicit DHCPv6 configuration option fo= r > NAT64. >=20 > This workaround keeps the door open to a future possible DHCPv6 option fo= r > NAT64 and we think is not contradicting RFC8026. >=20 > **** While we don't think it breaks anything, RFC8026 authors believe is > contradicting RFC8026 (we still don't see how or if it a minor detail in = the > text, that could be updated with an errata or it requires an RFC8026-bis, > etc.). >=20 > So the question here. Do the WG believe this is fine? Or somebody can exp= lain > if that will break anything/contradicting RFC8026? >=20 > OPTION B > Exclude 464XLAT from the stateless "priority" setup that allows RFC8026, = by > setting it on "top of it" (higher priority). So, if the NAT64 prefix is > available (by means of PCP or RFC7050), the CE will just configure it, > because the ISP is telling him "I've a NAT64 for you, don't care about ot= her > options". >=20 > This just works, but it forces an ISP to make sure that only the customer= s > that ISP wants to use the NAT64 are able to identify it (only in case, th= ey > have different "customer" groups with different mechanisms). If, in the > future, we define a DHCP option for NAT64, it forces the ISP to not provi= de > the NAT64 by means of PCP neither RFC7050. A configuration mistake in the= ISP > network regarding who is getting and what for S46, will still allow the > customers to use the NAT64. >=20 > OPTION C > Similar to b, but having the 464XLAT/NAT64 with the *lower* priority. >=20 > In this case, as well, it will work, but it forces the ISP to make sure t= hat > for those customers that the ISP wants they use the NAT64, the S46 option= s > must not return anything, otherwise the CE will never use the 464XLAT. So= a > mistake with the S46 may disallow customers using the NAT64. If, in the > future, we define a DHCPv6 option for NAT64, it will just work as well. >=20 > Of course, in all the 3 options, there may be other things to consider, b= ut > we think it is not possible to predict all them. All them depend on "if w= e > define in the future a DHCPv6 option for NAT64, we will need to update th= e > firmware of the CEs to support that, so it is safe to assume that we may = need > to revise at that point as well RFC8026 and possibly draft-ietf-v6ops- > transition-ipv4aas ...". >=20 > Co-authors take: Option A is fine, unless we can understand why it is > contradicting RFC8026, then option B, unless we agree to start the work t= o > update RFC8026 to support NAT64 someway (with or without a new DHCPv6 > option), in which case, option C makes more sense. >=20 > Please, let us know what do you think, and specially if you see that the > procedure specified as OPTION A, is fine, in which case the issue is > resolved. >=20 > Thanks! >=20 > Regards, > Jordi >=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 disclosur= e, > 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 a= ware > 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 t= he > 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 From nobody Thu Jan 24 02:17: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 3BD931310CB for ; Thu, 24 Jan 2019 02:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 eK_sMN-1uSmH for ; Thu, 24 Jan 2019 02:17:38 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD060130F11 for ; Thu, 24 Jan 2019 02:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1548325056; x=1548929856; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=5FqOsPcdp+1xwx1aWgq/m 40D1bjUDNfOipP8SghAGMk=; b=F/wUq0BaTgW+PFAUX0OHhA3HwKq6aEWDknkdN cmK7yZbqKAMADhST/miFKsIlfoxwLoIuuvsIExKs052stysuwOXNKwAmwUGSlaf9 Etjd5Rd/B4HDsiA1tk6CVjinbh8V2f7Lj0PxXYLNkVHeDSdy+cmM31HR4QxwdflE MFkeoA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 24 Jan 2019 11:17:35 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 24 Jan 2019 11:17:35 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006123163.msg for ; Thu, 24 Jan 2019 11:17:33 +0100 X-MDRemoteIP: 2001:470:1f09:495:4509:9d6:a781:b4c1 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Thu, 24 Jan 2019 11:17:33 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1927a7aef1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Thu, 24 Jan 2019 11:17:32 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: <9E2A936A-8AA1-48DC-AE1F-964FEE9478D0@consulintel.es> Thread-Topic: [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas 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, 24 Jan 2019 10:17:40 -0000 Hi Med, The candidate list is built by the CE and matched against what the ISP is s= ending in the S46 option. If the CE supports 464XLAT and has been able to configure a NAT64 prefix, t= hen it can insert that in the list (after running the RFC8026 process). The workaround presented by option A, makes that possible without needing a= specific NAT64 DHCP option. I think it is a matter of having a clear text in the document that tells ho= w this works in both sides the CE and the ISP. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fecha: jueves, 24 de enero de 2019, 10:38 Para: JORDI PALET MARTINEZ ,= "v6ops@ietf.org WG" Asunto: Re: [v6ops] question to the WG about draft-ietf-v6ops-transition-ip= v4aas Hi Jordi,=20 =20 The problem with option A is that the candidate list will be set by 802= 6 using DHCP options. So, even if you return 113 in the priority list, xlat= won't be added to the candidate list because no DHCP option for xlat is ac= tually returned. RFC8026 can be relaxed to allow for other sources to fed t= he candidate list, but that is another piece of work. =20 One comment about options B and C: These options are not about "Exclude= 464XLAT from the stateless "priority" setup that allows RFC8026", but abou= t removing the IANA text asking to add 113 to the S46 priority list. xlat c= an be added to the priority list if a dhcp option is defined for it. =20 My take is to pick option C (with the clarification made above) for the= following reasons:=20 * If a dhcp option is defined in the future, the codepoint of that opti= on will be included in the S46 priority list and normal 8026 processing wil= l be followed. * If a (stale) method is still present in the network to retrieve the p= refix by other means, the priority set by the provider in S46 priority list= will be followed because the default priority of xlat as set by draft-ietf= -v6ops-transition-ipv4aas won't win.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET = MARTINEZ > Envoy=C3=A9 : jeudi 24 janvier 2019 10:12 > =C3=80 : v6ops@ietf.org WG > Objet : [v6ops] question to the WG about draft-ietf-v6ops-transition-= ipv4aas >=20 > Hi all, >=20 > Sorry the long email, but it needs to be explained in detail so v6ops= folks > can understand it and provide inputs. >=20 > As part of the IESG telechat where this document was evaluated, it wa= s raised > a discuss regarding using RFC8115 in a way that introduces a "trick" = to > provide a DHCP option for a NAT64 prefix. >=20 > After hearing the comments in the list, we decided to remove it, but = we still > need a way to make sure that 464XLAT/NAT64 can be prioritized as well= as the > other mechanisms, so the ISP has control over it. >=20 > Our suggested approach was to keep using RFC8026 for all the mechanis= ms. >=20 > RFC8026 requires a *top-level Option Request* in order to respond wit= h the > S46 option, which define the priority of the mechanisms. We didn't re= alize > about that before because it was "intrinsically there" while we had R= FC8115. >=20 > Because we don't have an explicit DHCP option for configuring the NAT= 64, it > means the option code for NAT64/464XLAT (113, which was already defin= ed for > an IPv6 /64 prefix, but we are asking IANA to include in the RFC8026 = defined > table just for signaling the priority) will not be provided unless th= e CE ask > via DHCP for the configuration of other transition mechanisms. >=20 > In the opinion of the document co-authos, this is fine, because preci= sely we > expect that the CE supports several (hopefully all the 5). >=20 > So, in this case (let's call this OPTION A), the behavior will be: >=20 > 1) CE get the configuration parameters for all the mechanisms (includ= ing a > NAT64 prefix via PCP or RFC7050, and the other 4 by means of DHCP). >=20 > 2) As part of the request for DHCP configurable mechanism, the CE wil= l ask > for S46 priority. If NAT64 is available in the ISP, the S46 will also= contain > the 113. >=20 > 3) As a result, the CE can follow RFC8026 to decide which one match t= he ISP > preference with what the CE can "use". >=20 > What is the issue? If the CE only supports 464XLAT, then the CE must = be > forced to anyway, ask for "another" DHCPv6 configurable mechanism and= ignore > that information, but use the S46 response to check if the ISP suppor= ts > NAT64. Not an issue, in our opinion. >=20 > If the ISP only supports 464XLAT, then is forced to anyway, respond t= o the > DHCPv6 request for configuration options of all the other 4 mechanism= s (so > this will work in any case despite "what" the CE is supporting), but = in the > S46 response, will include only the 113, to signal that *only* suppor= ts > NAT64. Again, not an issue in our opinion. >=20 > It is just a matter of having some text in the document that explains= this > workaround because of the lack of explicit DHCPv6 configuration optio= n for > NAT64. >=20 > This workaround keeps the door open to a future possible DHCPv6 optio= n for > NAT64 and we think is not contradicting RFC8026. >=20 > **** While we don't think it breaks anything, RFC8026 authors believe= is > contradicting RFC8026 (we still don't see how or if it a minor detail= in the > text, that could be updated with an errata or it requires an RFC8026-= bis, > etc.). >=20 > So the question here. Do the WG believe this is fine? Or somebody can= explain > if that will break anything/contradicting RFC8026? >=20 > OPTION B > Exclude 464XLAT from the stateless "priority" setup that allows RFC80= 26, by > setting it on "top of it" (higher priority). So, if the NAT64 prefix = is > available (by means of PCP or RFC7050), the CE will just configure it= , > because the ISP is telling him "I've a NAT64 for you, don't care abou= t other > options". >=20 > This just works, but it forces an ISP to make sure that only the cust= omers > that ISP wants to use the NAT64 are able to identify it (only in case= , they > have different "customer" groups with different mechanisms). If, in t= he > future, we define a DHCP option for NAT64, it forces the ISP to not p= rovide > the NAT64 by means of PCP neither RFC7050. A configuration mistake in= the ISP > network regarding who is getting and what for S46, will still allow t= he > customers to use the NAT64. >=20 > OPTION C > Similar to b, but having the 464XLAT/NAT64 with the *lower* priority. >=20 > In this case, as well, it will work, but it forces the ISP to make su= re that > for those customers that the ISP wants they use the NAT64, the S46 op= tions > must not return anything, otherwise the CE will never use the 464XLAT= . So a > mistake with the S46 may disallow customers using the NAT64. If, in t= he > future, we define a DHCPv6 option for NAT64, it will just work as wel= l. >=20 > Of course, in all the 3 options, there may be other things to conside= r, but > we think it is not possible to predict all them. All them depend on "= if we > define in the future a DHCPv6 option for NAT64, we will need to updat= e the > firmware of the CEs to support that, so it is safe to assume that we = may need > to revise at that point as well RFC8026 and possibly draft-ietf-v6ops= - > transition-ipv4aas ...". >=20 > Co-authors take: Option A is fine, unless we can understand why it is > contradicting RFC8026, then option B, unless we agree to start the wo= rk to > update RFC8026 to support NAT64 someway (with or without a new DHCPv6 > option), in which case, option C makes more sense. >=20 > Please, let us know what do you think, and specially if you see that = the > procedure specified as OPTION A, is fine, in which case the issue is > resolved. >=20 > Thanks! >=20 > Regards, > Jordi >=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 > 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 _______________________________________________ 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 Jan 24 02:22: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 B0618130F11 for ; Thu, 24 Jan 2019 02:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vWfl400R3pZK for ; Thu, 24 Jan 2019 02:22:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 DB6961310E5 for ; Thu, 24 Jan 2019 02:22:06 -0800 (PST) Received: from [192.168.1.228] ([80.159.240.8]) by mail.gmx.com (mrgmx101 [212.227.17.174]) with ESMTPSA (Nemesis) id 0M2XkX-1h4yJJ0tKH-00sM6C; Thu, 24 Jan 2019 11:22:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: ianfarrer@gmx.com In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0D0F2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 24 Jan 2019 11:21:58 +0100 Cc: JORDI PALET MARTINEZ , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <66FBB70D-8C8D-4B0D-ACB5-A0226402381E@gmx.com> References: <54D2FE61-3B32-471C-81EB-658E55ACC4D0@consulintel.es> <787AE7BB302AE849A7480A190F8B93302EA0D0F2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: "mohamed.boucadair" X-Mailer: Apple Mail (2.3445.102.3) X-Provags-ID: V03:K1:0BJPBQBPf1uNQro7Mm/E8XWVs33hXtXnW+8R0jrsk0P11Okc7H/ WmzQLGYXK3aJeDQeXxx6Lr2KeKiBeVgo44Dj/gYEQejMRD7soFlt59iRpBVX3mOIMcecCE2 mEVL+qXyT8rUXToHtC34E4ERDIjBZO/2VjodBh/BLwbga9CK9+e91RGtMwpXNC9Ev8EOwz9 nI3ljC9yzuyUs07h7zgTw== X-UI-Out-Filterresults: notjunk:1;V03:K0:9+KGDzuhgS4=:LgIvTZAVL6+uxCkMCjaRi3 9XdOmiSdgXDIvl7TT0ydsVxJSnUrG15oek7FK1KG7Rofge5uHEKx5oBFsBSFuM63lfolDxnM3 /U584Esuw3d7Oyink/nFP7Clkcv3+hYTAnKGf6F18aiXTTXxEargRkWBJGVDfZCUjQLyd9LDk 3Pe8fZ7/WwsUT2LfeK8iNuE6FPafP+XvzBEPR4jLCA4oXtzLRKMtwLZDV9D29/0VszToHoHtZ /iE116BwujsK0n3mBNMaYWABY7+Fb9bQ2lBAj3BVcSGRaR1XJbvYyoc9261XFSqhmevrzSf3U cgsV8AgeQOS149X4iFasLhGWKhASFFyaUyPHd5HJ6+SgoAl1MAhMrGkq16Ql/hNXl7f/uurQ2 LDEJXC9zFGzjorByEajcpD2pQ1AHpBQUBlzE8E7dVysByBhKob9Qkug1q310FG/3Se1sCLxIy wMt+2TNjdNb5H0F3d0lVMwim5LO6ubFgN9HYPNbDQKGYqIAMfIjn5UGA7MxxJxm5ABgHRzfMh LDhx2ynOX/zTb8QZIU/T5f5etMQyBd9FJZTXG8DEsaaqr9LM6RyxbBNS2xhEJIXWtW8a1Imlu f0gxgwgo+LT0wXeOJv/e3E71SFj3o3uJrr/tZLnkjd4S3AT7jbGeaZSK8Wg9OtvwMHi4/w1dT lqiECcg2lqTNqX97D1vPTue+BsahTr7EJpA0un1T6UO/n83xTa30IcIL5v4hNEuGtLhn1ZDnv Xq3R8y4nFfukzOMl5+dri9MKLmGiEOBjJYAtULgfihP8RdZ1G5aVNNo06pblhTJ2p5rNoKp1w Xu4MMWw+un2eqSwcVUpD1tbRjAWJlA0v1Yf3JfnGIZGr4Cb2areuaQdZwBb1mm7nFmA4RFHYk KHENZolytey1fwV1STX7skdl6vAXnbNw2uPxs9pEm2z7sECe+Q6lzBSFA8qBQZHnZK5Y2iFNe jwhFu7tgNLQ== Archived-At: Subject: Re: [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas 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, 24 Jan 2019 10:22:09 -0000 Hi Jordi, Thanks for summarising. My thoughts on the options: Option A Agree with Med here. RFC8026 would need to be updated to allow this. I = would also want to see some description of how the candidate list would = be created when the configuration for the mechanisms could come from = DHCPv6, PCP and/or DNS. Client behaviour needs to be deterministic for = this otherwise we=E2=80=99ve defeated the object. Option B & C Option C would be my preferred solution. It allows XLAT to be = configured, but can be over-ridden by supplying DHCPv6 config. Option B = is less flexible in this respect (to my mind at least) - e.g. if you = have XLAT with RFC7050 and you want to migrate some clients to a = different mechanism (DHCPv6 provisioned) then you=E2=80=99ll also need = to ensure that the NAT64 prefix isn=E2=80=99t resolved just for the = clients that you want to migrate, and all of the clients are capable of = the new mechanism (not always knowable if customers supply their own = devices). One thing to clear up here: If the client received an RFC8026 option 111 = containing no option codes, then this is an error and the client will = discard it. Per the RFC, it may then attempt to configure mechanisms = based on the config it has received. The only way to ensure that this = doesn=E2=80=99t happen is to not supply the client with the DHCPv6 = soffwire config. Cheers, Ian > On 24. Jan 2019, at 10:38, = wrote: >=20 > Hi Jordi,=20 >=20 > The problem with option A is that the candidate list will be set by = 8026 using DHCP options. So, even if you return 113 in the priority = list, xlat won't be added to the candidate list because no DHCP option = for xlat is actually returned. RFC8026 can be relaxed to allow for other = sources to fed the candidate list, but that is another piece of work. >=20 > One comment about options B and C: These options are not about = "Exclude 464XLAT from the stateless "priority" setup that allows = RFC8026", but about removing the IANA text asking to add 113 to the S46 = priority list. xlat can be added to the priority list if a dhcp option = is defined for it. >=20 > My take is to pick option C (with the clarification made above) for = the following reasons:=20 > * If a dhcp option is defined in the future, the codepoint of that = option will be included in the S46 priority list and normal 8026 = processing will be followed. > * If a (stale) method is still present in the network to retrieve the = prefix by other means, the priority set by the provider in S46 priority = list will be followed because the default priority of xlat as set by = draft-ietf-v6ops-transition-ipv4aas won't win.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET = MARTINEZ >> Envoy=C3=A9 : jeudi 24 janvier 2019 10:12 >> =C3=80 : v6ops@ietf.org WG >> Objet : [v6ops] question to the WG about = draft-ietf-v6ops-transition-ipv4aas >>=20 >> Hi all, >>=20 >> Sorry the long email, but it needs to be explained in detail so v6ops = folks >> can understand it and provide inputs. >>=20 >> As part of the IESG telechat where this document was evaluated, it = was raised >> a discuss regarding using RFC8115 in a way that introduces a "trick" = to >> provide a DHCP option for a NAT64 prefix. >>=20 >> After hearing the comments in the list, we decided to remove it, but = we still >> need a way to make sure that 464XLAT/NAT64 can be prioritized as well = as the >> other mechanisms, so the ISP has control over it. >>=20 >> Our suggested approach was to keep using RFC8026 for all the = mechanisms. >>=20 >> RFC8026 requires a *top-level Option Request* in order to respond = with the >> S46 option, which define the priority of the mechanisms. We didn't = realize >> about that before because it was "intrinsically there" while we had = RFC8115. >>=20 >> Because we don't have an explicit DHCP option for configuring the = NAT64, it >> means the option code for NAT64/464XLAT (113, which was already = defined for >> an IPv6 /64 prefix, but we are asking IANA to include in the RFC8026 = defined >> table just for signaling the priority) will not be provided unless = the CE ask >> via DHCP for the configuration of other transition mechanisms. >>=20 >> In the opinion of the document co-authos, this is fine, because = precisely we >> expect that the CE supports several (hopefully all the 5). >>=20 >> So, in this case (let's call this OPTION A), the behavior will be: >>=20 >> 1) CE get the configuration parameters for all the mechanisms = (including a >> NAT64 prefix via PCP or RFC7050, and the other 4 by means of DHCP). >>=20 >> 2) As part of the request for DHCP configurable mechanism, the CE = will ask >> for S46 priority. If NAT64 is available in the ISP, the S46 will also = contain >> the 113. >>=20 >> 3) As a result, the CE can follow RFC8026 to decide which one match = the ISP >> preference with what the CE can "use". >>=20 >> What is the issue? If the CE only supports 464XLAT, then the CE must = be >> forced to anyway, ask for "another" DHCPv6 configurable mechanism and = ignore >> that information, but use the S46 response to check if the ISP = supports >> NAT64. Not an issue, in our opinion. >>=20 >> If the ISP only supports 464XLAT, then is forced to anyway, respond = to the >> DHCPv6 request for configuration options of all the other 4 = mechanisms (so >> this will work in any case despite "what" the CE is supporting), but = in the >> S46 response, will include only the 113, to signal that *only* = supports >> NAT64. Again, not an issue in our opinion. >>=20 >> It is just a matter of having some text in the document that explains = this >> workaround because of the lack of explicit DHCPv6 configuration = option for >> NAT64. >>=20 >> This workaround keeps the door open to a future possible DHCPv6 = option for >> NAT64 and we think is not contradicting RFC8026. >>=20 >> **** While we don't think it breaks anything, RFC8026 authors believe = is >> contradicting RFC8026 (we still don't see how or if it a minor detail = in the >> text, that could be updated with an errata or it requires an = RFC8026-bis, >> etc.). >>=20 >> So the question here. Do the WG believe this is fine? Or somebody can = explain >> if that will break anything/contradicting RFC8026? >>=20 >> OPTION B >> Exclude 464XLAT from the stateless "priority" setup that allows = RFC8026, by >> setting it on "top of it" (higher priority). So, if the NAT64 prefix = is >> available (by means of PCP or RFC7050), the CE will just configure = it, >> because the ISP is telling him "I've a NAT64 for you, don't care = about other >> options". >>=20 >> This just works, but it forces an ISP to make sure that only the = customers >> that ISP wants to use the NAT64 are able to identify it (only in = case, they >> have different "customer" groups with different mechanisms). If, in = the >> future, we define a DHCP option for NAT64, it forces the ISP to not = provide >> the NAT64 by means of PCP neither RFC7050. A configuration mistake in = the ISP >> network regarding who is getting and what for S46, will still allow = the >> customers to use the NAT64. >>=20 >> OPTION C >> Similar to b, but having the 464XLAT/NAT64 with the *lower* priority. >>=20 >> In this case, as well, it will work, but it forces the ISP to make = sure that >> for those customers that the ISP wants they use the NAT64, the S46 = options >> must not return anything, otherwise the CE will never use the = 464XLAT. So a >> mistake with the S46 may disallow customers using the NAT64. If, in = the >> future, we define a DHCPv6 option for NAT64, it will just work as = well. >>=20 >> Of course, in all the 3 options, there may be other things to = consider, but >> we think it is not possible to predict all them. All them depend on = "if we >> define in the future a DHCPv6 option for NAT64, we will need to = update the >> firmware of the CEs to support that, so it is safe to assume that we = may need >> to revise at that point as well RFC8026 and possibly = draft-ietf-v6ops- >> transition-ipv4aas ...". >>=20 >> Co-authors take: Option A is fine, unless we can understand why it is >> contradicting RFC8026, then option B, unless we agree to start the = work to >> update RFC8026 to support NAT64 someway (with or without a new DHCPv6 >> option), in which case, option C makes more sense. >>=20 >> Please, let us know what do you think, and specially if you see that = the >> procedure specified as OPTION A, is fine, in which case the issue is >> resolved. >>=20 >> Thanks! >>=20 >> Regards, >> Jordi >>=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jan 24 09:13: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 7A2AF131258 for ; Thu, 24 Jan 2019 09:13:41 -0800 (PST) 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 V7gRmhONYaNu for ; Thu, 24 Jan 2019 09:13:38 -0800 (PST) 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 F00B013125A for ; Thu, 24 Jan 2019 09:13:37 -0800 (PST) Received: from [192.168.1.119] (host-79-121-41-152.kabelnet.hu [79.121.41.152]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x0OHDRfM040984 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 24 Jan 2019 18:13:32 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-41-152.kabelnet.hu [79.121.41.152] claimed to be [192.168.1.119] References: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org list" From: =?UTF-8?Q?Lencse_G=c3=a1bor?= X-Forwarded-Message-Id: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> Message-ID: <0a3ef70d-851e-f8ba-97d5-37186e8872f8@hit.bme.hu> Date: Thu, 24 Jan 2019 18:13:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------E53B405503DE77D5CEDF5842" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.0 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=79.121.41.152; helo=[192.168.1.119]; 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-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: Thu, 24 Jan 2019 17:13:41 -0000 This is a multi-part message in MIME format. --------------E53B405503DE77D5CEDF5842 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear v6ops Members, We have revised our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" making significant changes including: o Ian Farrer has joined us as an author. o Restructuring: the description of the five IPv4aaS technologies was moved to a separate section. o More details and figures were added to the description of the five IPv4aaS technologies. o Section titled "High-level Architectures and their Consequences" has been completely rewritten. o Several additions/clarification throughout Section titled "Detailed Analysis". o Section titled "Performance Analysis" was dropped due to lack of results yet. o Word based text ported to XML. o Further text cleanups, added text on state sync and load balancing. Additional comments inline that should be considered for future updates. We kindly request your feedback. Best regards, Gåbor Lencse -------- Tovåbbított ßzenet -------- Tårgy: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt Dåtum: Thu, 24 Jan 2019 08:25:45 -0800 Feladó: internet-drafts@ietf.org Címzett: Lee Howard , Jordi Palet Martinez , Ian Farrer , Jordi Palet , Gabor Lencse , Richard Patterson A new version of I-D, draft-lmhp-v6ops-transition-comparison-02.txt has been successfully submitted by Gabor Lencse and posted to the IETF repository. Name: draft-lmhp-v6ops-transition-comparison Revision: 02 Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS Document date: 2019-01-24 Group: Individual Submission Pages: 23 URL: https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-02.txt Status: https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ Htmlized: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison Diff: https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison-02 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 --------------E53B405503DE77D5CEDF5842 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear v6ops Members,

We have revised our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" making significant changes including:
   o  Ian Farrer has joined us as an author.

   o  Restructuring: the description of the five IPv4aaS technologies
      was moved to a separate section.

   o  More details and figures were added to the description of the five
      IPv4aaS technologies.

   o  Section titled "High-level Architectures and their Consequences"
      has been completely rewritten.

   o  Several additions/clarification throughout Section titled
      "Detailed Analysis".

   o  Section titled "Performance Analysis" was dropped due to lack of
      results yet.

   o  Word based text ported to XML.

   o  Further text cleanups, added text on state sync and load
      balancing.  Additional comments inline that should be considered
      for future updates.
We kindly request your feedback.

Best regards,

GĂĄbor Lencse

-------- TovĂĄbbĂ­tott Ăźzenet --------
TĂĄrgy: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt
DĂĄtum: Thu, 24 Jan 2019 08:25:45 -0800
FeladĂł: internet-drafts@ietf.org
CĂ­mzett: 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-02.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

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

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

--------------E53B405503DE77D5CEDF5842-- From nobody Mon Jan 28 02:27:53 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 52E2E1295D8; Mon, 28 Jan 2019 02:27:44 -0800 (PST) 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.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <154867126431.2997.5150989867958027740@ietfa.amsl.com> Date: Mon, 28 Jan 2019 02:27:44 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-15.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, 28 Jan 2019 10:27:44 -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 : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-15.txt Pages : 24 Date : 2019-01-28 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or by vendors who sell through the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is necessary because there aren't sufficient IPv4 addresses available for every possible customer/device. However, devices or applications in the customer LANs (Local Area Networks) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-15 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-15 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 Jan 28 02:31: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 9CE7E129BBF for ; Mon, 28 Jan 2019 02:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uA6Ed-Gm7D8 for ; Mon, 28 Jan 2019 02:31:12 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054891295D8 for ; Mon, 28 Jan 2019 02:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1548671470; x=1549276270; 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=JJVMhD6iUbupMvpjDnTd3ODQ7Y260IfnE/AgsFzZeJo=; b=DUIUDbfbsNVTk Tgj26bIrswzmQN3vlWBNERYNiuoWbyeM5YV8ZfTFri7hcL7AjTjZlNLYKHIeUyyB hp3QQgFwD7lusDZDG7+gqbT8RN6E5OuJyOK+ZJk31N+7vYX0glR8iyUnyb7kQs2e Ru8V/50P6TQhwgqJAEXgaXX9wFiZH4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 28 Jan 2019 11:31:10 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 28 Jan 2019 11:31:09 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006130083.msg for ; Mon, 28 Jan 2019 11:31:08 +0100 X-MDRemoteIP: 2001:470:1f09:495:e126:fd53:9c93:4d5 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Mon, 28 Jan 2019 11:31:08 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=193163b670=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Mon, 28 Jan 2019 11:31:03 +0100 From: JORDI PALET MARTINEZ To: , "mohamed.boucadair" CC: "v6ops@ietf.org WG" Message-ID: <1FA43912-4913-48C4-ABD1-6CA79A8DB031@consulintel.es> Thread-Topic: [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas References: <54D2FE61-3B32-471C-81EB-658E55ACC4D0@consulintel.es> <787AE7BB302AE849A7480A190F8B93302EA0D0F2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66FBB70D-8C8D-4B0D-ACB5-A0226402381E@gmx.com> In-Reply-To: <66FBB70D-8C8D-4B0D-ACB5-A0226402381E@gmx.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas 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, 28 Jan 2019 10:31:17 -0000 Hi all, I've discussed with my co-authors about this, and we finally, not having ot= her inputs, decided to go for option c. We have already submitted the new version: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Hopefully this resolves this final issue! Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fecha: jueves, 24 de enero de 2019, 11:22 Para: "mohamed.boucadair" CC: "v6ops@ietf.org WG" , JORDI PALET MARTINEZ Asunto: Re: [v6ops] question to the WG about draft-ietf-v6ops-transition-ip= v4aas Hi Jordi, =20 Thanks for summarising. My thoughts on the options: =20 Option A Agree with Med here. RFC8026 would need to be updated to allow this. I = would also want to see some description of how the candidate list would be = created when the configuration for the mechanisms could come from DHCPv6, P= CP and/or DNS. Client behaviour needs to be deterministic for this otherwis= e we=E2=80=99ve defeated the object. =20 Option B & C =20 Option C would be my preferred solution. It allows XLAT to be configure= d, but can be over-ridden by supplying DHCPv6 config. Option B is less flex= ible in this respect (to my mind at least) - e.g. if you have XLAT with RFC= 7050 and you want to migrate some clients to a different mechanism (DHCPv6 = provisioned) then you=E2=80=99ll also need to ensure that the NAT64 prefix = isn=E2=80=99t resolved just for the clients that you want to migrate, and a= ll of the clients are capable of the new mechanism (not always knowable if = customers supply their own devices). =20 One thing to clear up here: If the client received an RFC8026 option 11= 1 containing no option codes, then this is an error and the client will dis= card it. Per the RFC, it may then attempt to configure mechanisms based on = the config it has received. The only way to ensure that this doesn=E2=80=99= t happen is to not supply the client with the DHCPv6 soffwire config. =20 Cheers, Ian =20 =20 > On 24. Jan 2019, at 10:38, wrote: >=20 > Hi Jordi,=20 >=20 > The problem with option A is that the candidate list will be set by 8= 026 using DHCP options. So, even if you return 113 in the priority list, xl= at won't be added to the candidate list because no DHCP option for xlat is = actually returned. RFC8026 can be relaxed to allow for other sources to fed= the candidate list, but that is another piece of work. >=20 > One comment about options B and C: These options are not about "Exclu= de 464XLAT from the stateless "priority" setup that allows RFC8026", but ab= out removing the IANA text asking to add 113 to the S46 priority list. xlat= can be added to the priority list if a dhcp option is defined for it. >=20 > My take is to pick option C (with the clarification made above) for t= he following reasons:=20 > * If a dhcp option is defined in the future, the codepoint of that op= tion will be included in the S46 priority list and normal 8026 processing w= ill be followed. > * If a (stale) method is still present in the network to retrieve the= prefix by other means, the priority set by the provider in S46 priority li= st will be followed because the default priority of xlat as set by draft-ie= tf-v6ops-transition-ipv4aas won't win.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET= MARTINEZ >> Envoy=C3=A9 : jeudi 24 janvier 2019 10:12 >> =C3=80 : v6ops@ietf.org WG >> Objet : [v6ops] question to the WG about draft-ietf-v6ops-transition= -ipv4aas >>=20 >> Hi all, >>=20 >> Sorry the long email, but it needs to be explained in detail so v6op= s folks >> can understand it and provide inputs. >>=20 >> As part of the IESG telechat where this document was evaluated, it w= as raised >> a discuss regarding using RFC8115 in a way that introduces a "trick"= to >> provide a DHCP option for a NAT64 prefix. >>=20 >> After hearing the comments in the list, we decided to remove it, but= we still >> need a way to make sure that 464XLAT/NAT64 can be prioritized as wel= l as the >> other mechanisms, so the ISP has control over it. >>=20 >> Our suggested approach was to keep using RFC8026 for all the mechani= sms. >>=20 >> RFC8026 requires a *top-level Option Request* in order to respond wi= th the >> S46 option, which define the priority of the mechanisms. We didn't r= ealize >> about that before because it was "intrinsically there" while we had = RFC8115. >>=20 >> Because we don't have an explicit DHCP option for configuring the NA= T64, it >> means the option code for NAT64/464XLAT (113, which was already defi= ned for >> an IPv6 /64 prefix, but we are asking IANA to include in the RFC8026= defined >> table just for signaling the priority) will not be provided unless t= he CE ask >> via DHCP for the configuration of other transition mechanisms. >>=20 >> In the opinion of the document co-authos, this is fine, because prec= isely we >> expect that the CE supports several (hopefully all the 5). >>=20 >> So, in this case (let's call this OPTION A), the behavior will be: >>=20 >> 1) CE get the configuration parameters for all the mechanisms (inclu= ding a >> NAT64 prefix via PCP or RFC7050, and the other 4 by means of DHCP). >>=20 >> 2) As part of the request for DHCP configurable mechanism, the CE wi= ll ask >> for S46 priority. If NAT64 is available in the ISP, the S46 will als= o contain >> the 113. >>=20 >> 3) As a result, the CE can follow RFC8026 to decide which one match = the ISP >> preference with what the CE can "use". >>=20 >> What is the issue? If the CE only supports 464XLAT, then the CE must= be >> forced to anyway, ask for "another" DHCPv6 configurable mechanism an= d ignore >> that information, but use the S46 response to check if the ISP suppo= rts >> NAT64. Not an issue, in our opinion. >>=20 >> If the ISP only supports 464XLAT, then is forced to anyway, respond = to the >> DHCPv6 request for configuration options of all the other 4 mechanis= ms (so >> this will work in any case despite "what" the CE is supporting), but= in the >> S46 response, will include only the 113, to signal that *only* suppo= rts >> NAT64. Again, not an issue in our opinion. >>=20 >> It is just a matter of having some text in the document that explain= s this >> workaround because of the lack of explicit DHCPv6 configuration opti= on for >> NAT64. >>=20 >> This workaround keeps the door open to a future possible DHCPv6 opti= on for >> NAT64 and we think is not contradicting RFC8026. >>=20 >> **** While we don't think it breaks anything, RFC8026 authors believ= e is >> contradicting RFC8026 (we still don't see how or if it a minor detai= l in the >> text, that could be updated with an errata or it requires an RFC8026= -bis, >> etc.). >>=20 >> So the question here. Do the WG believe this is fine? Or somebody ca= n explain >> if that will break anything/contradicting RFC8026? >>=20 >> OPTION B >> Exclude 464XLAT from the stateless "priority" setup that allows RFC8= 026, by >> setting it on "top of it" (higher priority). So, if the NAT64 prefix= is >> available (by means of PCP or RFC7050), the CE will just configure i= t, >> because the ISP is telling him "I've a NAT64 for you, don't care abo= ut other >> options". >>=20 >> This just works, but it forces an ISP to make sure that only the cus= tomers >> that ISP wants to use the NAT64 are able to identify it (only in cas= e, they >> have different "customer" groups with different mechanisms). If, in = the >> future, we define a DHCP option for NAT64, it forces the ISP to not = provide >> the NAT64 by means of PCP neither RFC7050. A configuration mistake i= n the ISP >> network regarding who is getting and what for S46, will still allow = the >> customers to use the NAT64. >>=20 >> OPTION C >> Similar to b, but having the 464XLAT/NAT64 with the *lower* priority= . >>=20 >> In this case, as well, it will work, but it forces the ISP to make s= ure that >> for those customers that the ISP wants they use the NAT64, the S46 o= ptions >> must not return anything, otherwise the CE will never use the 464XLA= T. So a >> mistake with the S46 may disallow customers using the NAT64. If, in = the >> future, we define a DHCPv6 option for NAT64, it will just work as we= ll. >>=20 >> Of course, in all the 3 options, there may be other things to consid= er, but >> we think it is not possible to predict all them. All them depend on = "if we >> define in the future a DHCPv6 option for NAT64, we will need to upda= te the >> firmware of the CEs to support that, so it is safe to assume that we= may need >> to revise at that point as well RFC8026 and possibly draft-ietf-v6op= s- >> transition-ipv4aas ...". >>=20 >> Co-authors take: Option A is fine, unless we can understand why it i= s >> contradicting RFC8026, then option B, unless we agree to start the w= ork to >> update RFC8026 to support NAT64 someway (with or without a new DHCPv= 6 >> option), in which case, option C makes more sense. >>=20 >> Please, let us know what do you think, and specially if you see that= the >> procedure specified as OPTION A, is fine, in which case the issue is >> resolved. >>=20 >> Thanks! >>=20 >> Regards, >> Jordi >>=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 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 >> that any disclosure, copying, distribution or use of the contents of= this >> information, even if partially, including attached files, is strictl= y >> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =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 Mon Jan 28 10:05:53 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 5BE101310A0; Mon, 28 Jan 2019 10:05:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica , v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154869874636.2854.15772241410150347263.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2019 10:05:46 -0800 Archived-At: Subject: [v6ops] Suresh Krishnan's No Objection on draft-ietf-v6ops-transition-ipv4aas-15: (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: Mon, 28 Jan 2019 18:05:46 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-15: 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-transition-ipv4aas/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Tue Jan 29 11:32:16 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 0FEF7130FD9; Tue, 29 Jan 2019 11:32:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154879033305.7803.3412798236253742730.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2019 11:32:13 -0800 Archived-At: Subject: [v6ops] v6ops - New Meeting Session Request for IETF 104 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: Tue, 29 Jan 2019 19:32:13 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: 6man dhc intarea grow ipwave rtgwg softwire Second Priority: dnsop netconf netmod opsec sidrops tsvwg People who must be present: Fred Baker Ron Bonica Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jan 29 11:37: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 5D15C130FEC; Tue, 29 Jan 2019 11:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhPAO0jRWCS1; Tue, 29 Jan 2019 11:37:38 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0: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 5DD9C130FEA; Tue, 29 Jan 2019 11:37:38 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id i20so19004253otl.0; Tue, 29 Jan 2019 11:37:38 -0800 (PST) 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:reply-to:message-id :references:to; bh=TOxaGNZ+RAlbRoLbEy+t4vPIqhu/73SaqlA094NRuOE=; b=swhQ2XfI3xo0IcuDAeXk8oDo3q1n7QvXPpRuAWf4Qox/1v/4cs3ZNczodDKiwyCRDF J1DM9EOozQdFZvJZK0QJpUJ/ezaevazRQtkDNDusFoQmmXuyfdN6h1MeTYvdc8/QIiYy aK+oEsOWlY7NLLF93kWkpxjYuTPfJhukUE/X8vTN/x+FzVMWLSf6esMav3odhI6C1Kae 0ZpMwbAhM2YAalFyOP/KyH42GiWrmHE2pxJNYOvhcYkui/svxJvLhgLFavSuHzgiriSh 1CjHUVKqUfZHFl41W44sPsRspH2ui2TMyuO5EYdz5vGUDOOaS9MdBJwqzUiO3HqFROE2 23Vg== 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 :reply-to:message-id:references:to; bh=TOxaGNZ+RAlbRoLbEy+t4vPIqhu/73SaqlA094NRuOE=; b=sC4YW/uuPwegbWlyDNbdZKeGMzeq7MjMiAlvEjZuBOcylYcQTgSXJGUoDfNWawYv+9 X7cysRcexE5bj7KITieQZ2m62yumHHnFsnXttsW7dEZyHte0TH6Cp3RPowENnGT6YVCR xH6ZCfm6dxJPXyTMnlhmqY3iU0cofHvVLFJyYfy3Wcuz6oWnmgVEwa4P9Yb+JYLGDcZr OGSTY3BvetH8yj8J253XpQvhlrhXufSTMoYTRN1nj51FWqwIPCP89vyJoxe7vFHkJj/q cj8KoLP+mPZbDLCP2TlsxbGdQME4VYe4vklwdegsA1IwZ4NYBlXcwvjiFWvQqBL87Yp/ 1hzw== X-Gm-Message-State: AJcUukfto3YT/gZ2zUPJkAL/RuUR1w4uo113regmk7sJL+vEZcSUZBSf GuZU1A1UyI6FlT78O/J7ga7Knsri X-Google-Smtp-Source: ALg8bN7kwx7Eoxm8G/KP20xLheOj4hJz/W5mwkO6/s61JpkggwRamqFqwE8GSX3C8uk2AB2xdJwWxA== X-Received: by 2002:a9d:7cd9:: with SMTP id r25mr19641157otn.110.1548790657413; Tue, 29 Jan 2019 11:37:37 -0800 (PST) Received: from ?IPv6:2600:8802:5600:164::10bb? ([2600:8802:5600:164::10bb]) by smtp.gmail.com with ESMTPSA id x4sm6227722otk.37.2019.01.29.11.37.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 11:37:36 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C0C41764-694F-47DA-9417-7B243A17C0E2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.1\)) From: Fred Baker In-Reply-To: <154879033305.7803.3412798236253742730.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2019 11:37:34 -0800 Cc: Warren Kumari , V6Ops Chairs Reply-To: V6Ops Chairs Message-Id: <07F6ABEA-103C-4EC8-B877-B023FB1FA2FC@gmail.com> References: <154879033305.7803.3412798236253742730.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.3445.104.1) Archived-At: Subject: Re: [v6ops] v6ops - New Meeting Session Request for IETF 104 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, 29 Jan 2019 19:37:41 -0000 --Apple-Mail=_C0C41764-694F-47DA-9417-7B243A17C0E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have requested a slot at IETF 104. Our current planned agenda is = pretty short - a presentation by Mikael Abrahamsson on DT Terastream, = and two or three drafts that demonstrably have working group support. If you are of a mind to post a draft, the draft cut-off is in a few = weeks, and there is time for mailing list discussion to demonstrate that = your draft deserves agenda time. I have listed as conflicts to avoid the working groups that our current = authors are working in. If you would like a BOF, working group, or = research group added to that list, please advise the chairs. > On Jan 29, 2019, at 11:32 AM, IETF Meeting Session Request Tool = wrote: >=20 >=20 >=20 > A new meeting session request has just been submitted by Fred Baker, a = Chair of the v6ops working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 70 > Conflicts to Avoid: > First Priority: 6man dhc intarea grow ipwave rtgwg softwire > Second Priority: dnsop netconf netmod opsec sidrops tsvwg >=20 >=20 >=20 > People who must be present: > Fred Baker > Ron Bonica > Warren "Ace" Kumari >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_C0C41764-694F-47DA-9417-7B243A17C0E2 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+AFAlxQq34ACgkQEhdRnd2G P+BPqA//RSvkyd7853R04wQcjGrGR9f0H8dyQ7YjefH+yZxldzKplq/npBqPA2G5 +QIFnXhuiz9XjG2IuLmLXSkqUD52jkwqu5zU19QJz019WrHaHboAoD1Bwqa9p5VY YyVdl/FjLc/G3NJYttZbQtwXo9gzrWV0yQrgOLYR8DUlThvyECdD7jOUHmkmoyzC OmQMYK6TZmITsOcLRSWK6gjafFw/jtre/kUiGuzTGwa81IMqQ2bN/FO8wljO0IRh esFfDMq1byfzU3ZrPd+9IiTW6A3/qB+SYIHj9PKP15hKYfjMEPnjk9j61SkojVU5 3EJIvt2y8M59jK7Hd8Gfj68/c0ZNQviIHjMF6mJ1iJUjt/IVm+cCZE+ahXggArQs OqADfpjWOQmZwcqYoz5irkfN0HcINa3G6Yj65XLClJSkF407tzKJ7i+j0JaNYwmc Maulk9Bu9+xhI0ZGIFrp5IrFIIOZz9YNARvA5SYMA996qIZ+aJQGYXmNW5Now0y/ 8850EIO9kA8a77i1qH997WXGY3JhEWsiGSOw3FIFo+aVkp9gtDlCCfUF/MkK4Mk5 x8OA4patD9usIp1S2wmRuZu9RjMPDFO/aylCukxy0DiIpqXx75F+T2+CUyJduQU4 zSYvORd3dIH4Fm6gC41l5ZMYJKyni8CpNQ3bE2fY6ZkgqQbYHpU= =m3Qj -----END PGP SIGNATURE----- --Apple-Mail=_C0C41764-694F-47DA-9417-7B243A17C0E2-- From nobody Tue Jan 29 12:48:03 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 B8FC0130F0D for ; Tue, 29 Jan 2019 12:48:01 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFLXuW7iiTLw for ; Tue, 29 Jan 2019 12:47:56 -0800 (PST) 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 2722D130EAE for ; Tue, 29 Jan 2019 12:47:55 -0800 (PST) Received: from [192.168.1.119] (host-79-121-43-225.kabelnet.hu [79.121.43.225]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x0TKld9S000325 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 29 Jan 2019 21:47:46 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-43-225.kabelnet.hu [79.121.43.225] claimed to be [192.168.1.119] To: "v6ops@ietf.org list" References: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> <0a3ef70d-851e-f8ba-97d5-37186e8872f8@hit.bme.hu> <787AE7BB302AE849A7480A190F8B93302EA0D949@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <7291a25b-25a7-78f5-952b-6fe8b70018b5@hit.bme.hu> Date: Tue, 29 Jan 2019 21:47:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0D949@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------8B5790F5ABBEB4F727BC5512" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.0 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=79.121.43.225; helo=[192.168.1.119]; 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: Re: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-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: Tue, 29 Jan 2019 20:48:02 -0000 This is a multi-part message in MIME format. --------------8B5790F5ABBEB4F727BC5512 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Med, Thank you very much for your comments. Please, see my replies inline. 1/25/2019 9:13 AM keltezéssel, mohamed.boucadair@orange.com írta: > > Hi Gabor, > > Some quick comments on the draft: > > ·You indicate that tr69 is available for xlat provisioning, but I’m > not aware of any device model work done at BBF for xlat. The model > supports DS-Lite and MAP; I’m not sure for the other. > It will be addressed by Ian. (He has prepared the table.) > ·For YANG, RFC8512 does support CLAT/NAT64. You may update the table > accordingly. > Thank you for mentioning that. Now, I have included it into the XML source. (And also deleted RFC 6050, which was a typo, I meant RFC 6020, the definition for YANG) > ·Why DNS64 is listed in table 2? > I think, because it is often used together with 464 XLAT. (But Ian can tell, why he included it.) > ·You may add pointer to rfc6889 when discussing NAT64/xlat matters > (section 3.2) > It seems to be a good analysis. We will definitely include it. > ·“In the centralized model” is not that accurate when talking about > CGNs, because distributed CGNs are deployed to avoid risks related to > centralized models. > Of course, we wanted to refer to the first one of the following two cases: o Centralized Stateful NAPT44 (DS-Lite, 464XLAT) o Distributed Stateful NAPT44 (lw4o6, MAP-E, MAP-T) Which word would you recommend to use for that? > ·PCP is required for NAT64 (section 4.3) > Would you agree with the following change? Port Control Protocol (PCP) [RFC6877 ] provides a mechanism for a client to request an external public port from a CGN device and is supported in some DS-Lite AFTR implementations. --> Port Control Protocol (PCP) [RFC6877 ] provides a mechanism for a client to request an external public port from a CGN device*. For server operation, ***it is required* with NAT64/464XLAT, and it *is supported in some DS-Lite AFTR implementations. > ·You may add some text about dyndns issues. For solutions making use > of PCP (dslite), a proposal is described in RFC7393 > Thank you for mentioning that. We will include it, too. > ·The logging part should be update to reflect that even when A+P is > deployed, some regulation in specific countries are requiring the full > 5-uple to be logged! > Do you mean that even if it is clear that a given port range for a given public IPv4 address is statically assigned to a given subscriber (and thus no one else can use it), the ISP still must track all the activities of the user (by logging the 5-tuple)? If your answer is yes, then I have a question about the following: Stateless technologies that pre-allocate the IPv4 addresses and ports only require that copies of the active MAP rules (for MAP-E and MAP- T), or binding-table (for lw4o6) are retained along with timestamp information of when they have been active. Support tools (e.g., those used to serve data retention requests) may need to be updated to be aware of the mechanism in use (e.g., implementing the MAP algorithm so that IPv4 information can be linked to the IPv6 prefix delegated to a client). As stateless technologies do not have a centralized stateful element which customer traffic needs to pass through, so if data retention laws mandate per-session logging, there is no simple way of meeting this requirement with a stateless technology alone. Does the two statements together mean that the logging requirements of that countries may not be satisfied, when stateless technologies (e.g. MAP protocols) are used? Best regards, Gábor > > Cheers, > > Med > > *De :*v6ops [mailto:v6ops-bounces@ietf.org] *De la part de* Lencse Gábor > *Envoyé :* jeudi 24 janvier 2019 18:13 > *À :* v6ops@ietf.org list > *Objet :* [v6ops] Fwd: New Version Notification for > draft-lmhp-v6ops-transition-comparison-02.txt > > Dear v6ops Members, > > We have revised our draft "Pros and Cons of IPv6 Transition > Technologies for IPv4aaS" making significant changes including: > >    o  Ian Farrer has joined us as an author. >    o  Restructuring: the description of the five IPv4aaS technologies >       was moved to a separate section. >    o  More details and figures were added to the description of the five >       IPv4aaS technologies. >    o  Section titled "High-level Architectures and their Consequences" >       has been completely rewritten. >    o  Several additions/clarification throughout Section titled >       "Detailed Analysis". >    o  Section titled "Performance Analysis" was dropped due to lack of >       results yet. >    o  Word based text ported to XML. >    o  Further text cleanups, added text on state sync and load >       balancing.  Additional comments inline that should be considered >       for future updates. > > We kindly request your feedback. > > Best regards, > > Gábor Lencse > > -------- Továbbított üzenet -------- > > *Tárgy: * > > > > New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt > > *Dátum: * > > > > Thu, 24 Jan 2019 08:25:45 -0800 > > *Feladó: * > > > > internet-drafts@ietf.org > > *Címzett: * > > > > Lee Howard , Jordi Palet > Martinez > , Ian Farrer > , Jordi Palet > > , Gabor Lencse > , Richard Patterson > > > > > > A new version of I-D, draft-lmhp-v6ops-transition-comparison-02.txt > has been successfully submitted by Gabor Lencse and posted to the > IETF repository. > > Name: draft-lmhp-v6ops-transition-comparison > Revision: 02 > Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS > Document date: 2019-01-24 > Group: Individual Submission > Pages: 23 > URL: > https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-02.txt > Status: > https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ > Htmlized: > https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison > Diff: > https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison-02 > > 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 > --------------8B5790F5ABBEB4F727BC5512 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Med,

Thank you very much for your comments. Please, see my replies inline.

1/25/2019 9:13 AM keltezĂŠssel, mohamed.boucadair@orange.com Ă­rta:

Hi Gabor,

 

Some quick comments on the draft:

 

·         You indicate that tr69 is available for xlat provisioning, but I’m not aware of any device model work done at BBF for xlat. The model supports DS-Lite and MAP; I’m not sure for the other.


It will be addressed by Ian. (He has prepared the table.)

¡         For YANG, RFC8512 does support CLAT/NAT64. You may update the table accordingly.


Thank you for mentioning that. Now, I have included it into the XML source. (And also deleted RFC 6050, which was a typo, I meant RFC 6020, the definition for YANG)


¡         Why DNS64 is listed in table 2?


I think, because it is often used together with 464 XLAT. (But Ian can tell, why he included it.)

¡         You may add pointer to rfc6889 when discussing NAT64/xlat matters (section 3.2)


It seems to be a good analysis. We will definitely include it.

·         “In the centralized model” is not that accurate when talking about CGNs, because distributed CGNs are deployed to avoid risks related to centralized models.


Of course, we wanted to refer to the first one of the following two cases:

   o  Centralized Stateful NAPT44 (DS-Lite, 464XLAT)

   o  Distributed Stateful NAPT44 (lw4o6, MAP-E, MAP-T)
Which word would you recommend to use for that?

¡         PCP is required for NAT64 (section 4.3)


Would you agree with the following change?

   Port Control Protocol (PCP) [RFC6877] provides a mechanism for a
   client to request an external public port from a CGN device and is
   supported in some DS-Lite AFTR implementations.

-->

   Port Control Protocol (PCP) [RFC6877] provides a mechanism for a
   client to request an external public port from a CGN device. For server operation, it is required with NAT64/464XLAT, and it is
   supported in some DS-Lite AFTR implementations.

¡         You may add some text about dyndns issues. For solutions making use of PCP (dslite), a proposal is described in RFC7393


Thank you for mentioning that. We will include it, too.


¡         The logging part should be update to reflect that even when A+P is deployed, some regulation in specific countries are requiring the full 5-uple to be logged!


Do you mean that even if it is clear that a given port range for a given public IPv4 address is statically assigned to a given subscriber (and thus no one else can use it), the ISP still must track all the activities of the user (by logging the 5-tuple)?

If your answer is yes, then I have a question about the following:

   Stateless technologies that pre-allocate the IPv4 addresses and ports
   only require that copies of the active MAP rules (for MAP-E and MAP-
   T), or binding-table (for lw4o6) are retained along with timestamp
   information of when they have been active.  Support tools (e.g.,
   those used to serve data retention requests) may need to be updated
   to be aware of the mechanism in use (e.g., implementing the MAP
   algorithm so that IPv4 information can be linked to the IPv6 prefix
   delegated to a client).  As stateless technologies do not have a
   centralized stateful element which customer traffic needs to pass
   through, so if data retention laws mandate per-session logging, there
   is no simple way of meeting this requirement with a stateless
   technology alone.

Does the two statements together mean that the logging requirements of that countries may not be satisfied, when stateless technologies (e.g. MAP protocols) are used?

Best regards,

GĂĄbor


Cheers,

Med

 

De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Lencse Gåbor
EnvoyÊ : jeudi 24 janvier 2019 18:13
À : v6ops@ietf.org list
Objet : [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt

 

Dear v6ops Members,

We have revised our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" making significant changes including:

   o  Ian Farrer has joined us as an author.
 
   o  Restructuring: the description of the five IPv4aaS technologies
      was moved to a separate section.
 
   o  More details and figures were added to the description of the five
      IPv4aaS technologies.
 
   o  Section titled "High-level Architectures and their Consequences"
      has been completely rewritten.
 
   o  Several additions/clarification throughout Section titled
      "Detailed Analysis".
 
   o  Section titled "Performance Analysis" was dropped due to lack of
      results yet.
 
   o  Word based text ported to XML.
 
   o  Further text cleanups, added text on state sync and load
      balancing.  Additional comments inline that should be considered
      for future updates.

We kindly request your feedback.

Best regards,

GĂĄbor Lencse

-------- TovĂĄbbĂ­tott Ăźzenet --------

TĂĄrgy:

New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt

DĂĄtum:

Thu, 24 Jan 2019 08:25:45 -0800

FeladĂł:

internet-drafts@ietf.org

CĂ­mzett:

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-02.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

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

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


--------------8B5790F5ABBEB4F727BC5512-- From nobody Tue Jan 29 15:25: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 5261712E7C1 for ; Tue, 29 Jan 2019 15:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heX4bSHUE_lB for ; Tue, 29 Jan 2019 15:25:22 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450: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 25B82130EE2 for ; Tue, 29 Jan 2019 15:25:22 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id b14so17506587edt.6 for ; Tue, 29 Jan 2019 15:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Btw9lo8vpDxv+xTWRpyH3AYAFgLktnARNoepF0B/wIs=; b=gZpVB7rfoZdRcVQocHBPLHuwzLZfbPMdpLtLOGx7Ue9MdsADOmj2N0O8g1hhrXewwt xz+tdHpvniYACFy3ha1x+iFp3+QwsWEmQLTwWQVAehmYCHZMKk9wwMc1QV/oUZ3K5EPE StbGR6a2Z84cNynYRpCDER28+b1e3TwNVV4eD0yF9kQnUB5uKhYIUUfHReg3CAbpB7bK 6LrP2RyhrilRobYfDKeGsPQD6/CwAC9mbJ0WYgcCa4MOTrZnq3/4NsT/nrzx2mp1+oHW /+wGnZ+wTaq4O3zyIG988z2EmcnmuarWWwIe22QCQ4Eyb/6YwwgQ8onbr4k35Z+y7mcE CC9A== 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=Btw9lo8vpDxv+xTWRpyH3AYAFgLktnARNoepF0B/wIs=; b=RjT0wr469aCEOLBX49F4nnzhK8E4PoYgkEVej8b4+HwOYgP1im9gqVOCBl2SFN6CCu ABjil9fTL2BgesFO+9eaTCFSwxS35+ae1z9Lmwzxd+vDBn9ozlv736Nasn4sVVfqHtEr HCYG4zYtt23hh9UzWA/cZGVveg4EQqXRyYFc5LgisrEC6yDNeTNpAXWnYd9FRzxr/uQV P2NUlea8Q14RuZ+KvWOxuCSFRaoy7dZ96v8IOOU3Zsjn37Zi4xuBuOMXpVgMsot84Yzv PLtTgQY/3lVsdS3mnkIDRDJ5y/HtGIsSRGlXWDNQhRAWP3ExtSshOEIg9h8g+3+onZYA sxpQ== X-Gm-Message-State: AJcUukfNfbq9wHlPsOJCFiIy+y0O9gsoQIj18KrcSEIemAHq4uT11FN2 FprvAWP+sMSQMRgHgud7FMA= X-Google-Smtp-Source: ALg8bN6BqF5jQwbsYPlexqRzaA7NxXhi14uR1Y+KD42ctPFgMnEtVKzw5FLqxOR+Ba/Mt+gS+sjwNA== X-Received: by 2002:a50:b744:: with SMTP id g62mr27827647ede.14.1548804320625; Tue, 29 Jan 2019 15:25:20 -0800 (PST) Received: from ?IPv6:2600:8802:5600:164::14cf? ([2600:8802:5600:164::14cf]) by smtp.gmail.com with ESMTPSA id n10sm58478edq.33.2019.01.29.15.25.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 15:25:19 -0800 (PST) From: Fred Baker Message-Id: <2FB2E918-900C-49A9-9007-6D7160275776@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_79269553-22C3-4173-80D9-BD9BC5D8D193"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.1\)) Date: Tue, 29 Jan 2019 15:25:16 -0800 In-Reply-To: <7291a25b-25a7-78f5-952b-6fe8b70018b5@hit.bme.hu> Cc: "v6ops@ietf.org list" To: =?utf-8?Q?Lencse_G=C3=A1bor?= References: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> <0a3ef70d-851e-f8ba-97d5-37186e8872f8@hit.bme.hu> <787AE7BB302AE849A7480A190F8B93302EA0D949@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7291a25b-25a7-78f5-952b-6fe8b70018b5@hit.bme.hu> X-Mailer: Apple Mail (2.3445.104.1) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-lmhp-v6ops-transition-comparison-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: Tue, 29 Jan 2019 23:25:25 -0000 --Apple-Mail=_79269553-22C3-4173-80D9-BD9BC5D8D193 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 29, 2019, at 12:47 PM, Lencse G=C3=A1bor = wrote: >=20 >> =C2=B7 Why DNS64 is listed in table 2? >=20 > I think, because it is often used together with 464 XLAT. (But Ian can = tell, why he included it.) I'm not Ian, but I can tell you that NAT64 deployments have the option = to include it. 464XLAT deployments are likely to use other mechanisms = such as RFC 7750. = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_79269553-22C3-4173-80D9-BD9BC5D8D193 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+AFAlxQ4NwACgkQEhdRnd2G P+AD1g//eVcUunrslpVojvH8KOuEpUzSuO7CeeUvdT4IibVjyFQ5Nd1H3XYUmNEa n51XfUWv/nonAvH8tB86F0aHvTDTk5IF6hf7HKae3N9gLazcPdO/3+NCyipIihZp ZchIh9C1el+j/j3ZJBhWsfEC2TeMv12pZbYdS93FOWxv6ZetsRtItLnubc/JLjic VWqTGcU90K6ZgaSujyOoP90CV3eLLwCVIQLnrdOq1HcV7wemDY923ggN3yVhARmY TcMJ9RYVPx9J6SEHkm2YGTluvxJsxPvFITy0sMHIzIvRNQnVkv2NZa4U+uwPoF29 vLYtUAWA7fiwkO8JyK4q03FtO+mC4GqkUh/sfkZ8lfuSN4Z2Scgv0DqZIVcf2pHf tUGdLBPeK4clilwkPamj6O92Th8SlSRKgFtDEsbFrfZwxiKxe2IUGZBgWUCkg0RH K8puAN4c3umky5+FyGlrVcwk6PkhwgTSC8S30+kgOS+hBFFjjjmvUCstxw4VCwAJ GHCfXrXUGAkEAErGjSioHnfNR9MlaqW54nX9EUK896Pbpc3isw8xsyITS30y+FA9 TDeoHXpfAZHe+ZbcEBtbwRhjRXVN1qIRjcM5iu9A3iDPuCswOOuLfHXqAeHrmj0i PaBBjIFe9DlgBoi3nS4pleOLRTWk4NEdX2LaCfw8WwkBdFxlp/M= =dlqc -----END PGP SIGNATURE----- --Apple-Mail=_79269553-22C3-4173-80D9-BD9BC5D8D193-- From nobody Tue Jan 29 22:41: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 CCC68130EA4 for ; Tue, 29 Jan 2019 22:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 iVs9jGDe5muZ for ; Tue, 29 Jan 2019 22:41:01 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42383130E86 for ; Tue, 29 Jan 2019 22:41:01 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 43qDK72rLmz8sqZ; Wed, 30 Jan 2019 07:40:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 43qDK71wJVzCqkR; Wed, 30 Jan 2019 07:40:59 +0100 (CET) Received: from OPEXCAUBM7F.corporate.adroot.infra.ftgroup (10.114.13.98) by OPEXCLILM5E.corporate.adroot.infra.ftgroup (10.114.31.62) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 30 Jan 2019 07:40:58 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Wed, 30 Jan 2019 07:40:58 +0100 From: To: =?utf-8?B?TGVuY3NlIEfDoWJvcg==?= , "v6ops@ietf.org list" Thread-Topic: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt Thread-Index: AQHUuBP53myjvECE3Uu88iDsCTMnJ6XHVk6g Date: Wed, 30 Jan 2019 06:40:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0F5FD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> <0a3ef70d-851e-f8ba-97d5-37186e8872f8@hit.bme.hu> <787AE7BB302AE849A7480A190F8B93302EA0D949@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7291a25b-25a7-78f5-952b-6fe8b70018b5@hit.bme.hu> In-Reply-To: <7291a25b-25a7-78f5-952b-6fe8b70018b5@hit.bme.hu> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA0F5FDOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-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: Wed, 30 Jan 2019 06:41:05 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA0F5FDOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGVuY3NlLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDog djZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIExlbmNz ZSBHw6Fib3INCkVudm95w6kgOiBtYXJkaSAyOSBqYW52aWVyIDIwMTkgMjE6NDgNCsOAIDogdjZv cHNAaWV0Zi5vcmcgbGlzdA0KT2JqZXQgOiBSZTogW3Y2b3BzXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtbG1ocC12Nm9wcy10cmFuc2l0aW9uLWNvbXBhcmlzb24tMDIu dHh0DQoNCkRlYXIgTWVkLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRz LiBQbGVhc2UsIHNlZSBteSByZXBsaWVzIGlubGluZS4NCjEvMjUvMjAxOSA5OjEzIEFNIGtlbHRl esOpc3NlbCwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT4gw61ydGE6DQpIaSBHYWJvciwNCg0KU29tZSBxdWljayBjb21tZW50 cyBvbiB0aGUgZHJhZnQ6DQoNCg0KwrcgICAgICAgICBZb3UgaW5kaWNhdGUgdGhhdCB0cjY5IGlz IGF2YWlsYWJsZSBmb3IgeGxhdCBwcm92aXNpb25pbmcsIGJ1dCBJ4oCZbSBub3QgYXdhcmUgb2Yg YW55IGRldmljZSBtb2RlbCB3b3JrIGRvbmUgYXQgQkJGIGZvciB4bGF0LiBUaGUgbW9kZWwgc3Vw cG9ydHMgRFMtTGl0ZSBhbmQgTUFQOyBJ4oCZbSBub3Qgc3VyZSBmb3IgdGhlIG90aGVyLg0KDQpJ dCB3aWxsIGJlIGFkZHJlc3NlZCBieSBJYW4uIChIZSBoYXMgcHJlcGFyZWQgdGhlIHRhYmxlLikN CltNZWRdIE9LDQoNCg0KDQoNCsK3ICAgICAgICAgRm9yIFlBTkcsIFJGQzg1MTIgZG9lcyBzdXBw b3J0IENMQVQvTkFUNjQuIFlvdSBtYXkgdXBkYXRlIHRoZSB0YWJsZSBhY2NvcmRpbmdseS4NCg0K VGhhbmsgeW91IGZvciBtZW50aW9uaW5nIHRoYXQuIE5vdywgSSBoYXZlIGluY2x1ZGVkIGl0IGlu dG8gdGhlIFhNTCBzb3VyY2UuDQpbTWVkXSBPSy4NCg0KKEFuZCBhbHNvIGRlbGV0ZWQgUkZDIDYw NTAsIHdoaWNoIHdhcyBhIHR5cG8sIEkgbWVhbnQgUkZDIDYwMjAsIHRoZSBkZWZpbml0aW9uIGZv ciBZQU5HKQ0KW01lZF0gWW91IG1heSB0aGVuIGFkZCBhIHBvaW50ZXIgdG8gUkZDNzk1MC4NCg0K DQoNCsK3ICAgICAgICAgV2h5IEROUzY0IGlzIGxpc3RlZCBpbiB0YWJsZSAyPw0KDQpJIHRoaW5r LCBiZWNhdXNlIGl0IGlzIG9mdGVuIHVzZWQgdG9nZXRoZXIgd2l0aCA0NjQgWExBVC4gKEJ1dCBJ YW4gY2FuIHRlbGwsIHdoeSBoZSBpbmNsdWRlZCBpdC4pDQpbTWVkXSBPSywgdGhhbmtzLiBMZXTi gJlzIHdhaXQgZm9yIElhbiB0byBjbGFyaWZ5Lg0KDQoNCg0KDQrCtyAgICAgICAgIFlvdSBtYXkg YWRkIHBvaW50ZXIgdG8gcmZjNjg4OSB3aGVuIGRpc2N1c3NpbmcgTkFUNjQveGxhdCBtYXR0ZXJz IChzZWN0aW9uIDMuMikNCg0KSXQgc2VlbXMgdG8gYmUgYSBnb29kIGFuYWx5c2lzLiBXZSB3aWxs IGRlZmluaXRlbHkgaW5jbHVkZSBpdC4NCg0KDQoNCsK3ICAgICAgICAg4oCcSW4gdGhlIGNlbnRy YWxpemVkIG1vZGVs4oCdIGlzIG5vdCB0aGF0IGFjY3VyYXRlIHdoZW4gdGFsa2luZyBhYm91dCBD R05zLCBiZWNhdXNlIGRpc3RyaWJ1dGVkIENHTnMgYXJlIGRlcGxveWVkIHRvIGF2b2lkIHJpc2tz IHJlbGF0ZWQgdG8gY2VudHJhbGl6ZWQgbW9kZWxzLg0KDQpPZiBjb3Vyc2UsIHdlIHdhbnRlZCB0 byByZWZlciB0byB0aGUgZmlyc3Qgb25lIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGNhc2VzOg0KDQog ICBvICBDZW50cmFsaXplZCBTdGF0ZWZ1bCBOQVBUNDQgKERTLUxpdGUsIDQ2NFhMQVQpDQoNCg0K DQpbTWVkXSBJ4oCZbSBub3Qgc3VyZSA0NjR4bGF0IGNhbiBiZSBsaXN0ZWQgYXMg4oCcQ2VudHJh bGl6ZWQgU3RhdGVmdWwgTkFQVDQ04oCdDQoNCg0KDQogICBvICBEaXN0cmlidXRlZCBTdGF0ZWZ1 bCBOQVBUNDQgKGx3NG82LCBNQVAtRSwgTUFQLVQpDQoNCg0KV2hpY2ggd29yZCB3b3VsZCB5b3Ug cmVjb21tZW5kIHRvIHVzZSBmb3IgdGhhdD8NCg0KW01lZF0gSSB3b3VsZCBhdm9pZCBib3RoIGFu ZCB1c2Ug4oCcQStQ4oCdIHZzLiDigJxDR04tYmFzZWQgYXBwcm9hY2hlc+KAnS4gQ0dOLWJhc2Vk IGFkZHJlc3Mgc2hhcmluZyBjYW4gYmUgZGVwbG95ZWQgaW4gYm90aCBjZW50cmFsaXplZCBhbmQg ZGlzdHJpYnV0ZWQgc2NoZW1lcy4NCg0KDQrCtyAgICAgICAgIFBDUCBpcyByZXF1aXJlZCBmb3Ig TkFUNjQgKHNlY3Rpb24gNC4zKQ0KDQpXb3VsZCB5b3UgYWdyZWUgd2l0aCB0aGUgZm9sbG93aW5n IGNoYW5nZT8NCg0KICAgUG9ydCBDb250cm9sIFByb3RvY29sIChQQ1ApIFtSRkM2ODc3PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODc3Pl0gcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9y IGENCg0KICAgY2xpZW50IHRvIHJlcXVlc3QgYW4gZXh0ZXJuYWwgcHVibGljIHBvcnQgZnJvbSBh IENHTiBkZXZpY2UgYW5kIGlzDQoNCiAgIHN1cHBvcnRlZCBpbiBzb21lIERTLUxpdGUgQUZUUiBp bXBsZW1lbnRhdGlvbnMuDQoNCg0KDQotLT4NCg0KDQoNCiAgIFBvcnQgQ29udHJvbCBQcm90b2Nv bCAoUENQKSBbUkZDNjg3NzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjg3Nz5dIHBy b3ZpZGVzIGEgbWVjaGFuaXNtIGZvciBhDQoNCiAgIGNsaWVudCB0byByZXF1ZXN0IGFuIGV4dGVy bmFsIHB1YmxpYyBwb3J0IGZyb20gYSBDR04gZGV2aWNlLiBGb3Igc2VydmVyIG9wZXJhdGlvbiwg aXQgaXMgcmVxdWlyZWQgd2l0aCBOQVQ2NC80NjRYTEFULCBhbmQgaXQgaXMNCg0KICAgc3VwcG9y dGVkIGluIHNvbWUgRFMtTGl0ZSBBRlRSIGltcGxlbWVudGF0aW9ucy4NCg0KW01lZF0gV29ya3Mg Zm9yIG1lLiBUaGFuayB5b3UuDQoNCg0KDQrCtyAgICAgICAgIFlvdSBtYXkgYWRkIHNvbWUgdGV4 dCBhYm91dCBkeW5kbnMgaXNzdWVzLiBGb3Igc29sdXRpb25zIG1ha2luZyB1c2Ugb2YgUENQIChk c2xpdGUpLCBhIHByb3Bvc2FsIGlzIGRlc2NyaWJlZCBpbiBSRkM3MzkzDQoNClRoYW5rIHlvdSBm b3IgbWVudGlvbmluZyB0aGF0LiBXZSB3aWxsIGluY2x1ZGUgaXQsIHRvby4NCltNZWRdIEdyZWF0 LiBJIGFzc3VtZSB0aGUgZGlzY3Vzc2lvbiB3aWxsIGNvdmVyIGFsbCBzY2hlbWVzLg0KDQoNCsK3 ICAgICAgICAgVGhlIGxvZ2dpbmcgcGFydCBzaG91bGQgYmUgdXBkYXRlIHRvIHJlZmxlY3QgdGhh dCBldmVuIHdoZW4gQStQIGlzIGRlcGxveWVkLCBzb21lIHJlZ3VsYXRpb24gaW4gc3BlY2lmaWMg Y291bnRyaWVzIGFyZSByZXF1aXJpbmcgdGhlIGZ1bGwgNS11cGxlIHRvIGJlIGxvZ2dlZCENCg0K RG8geW91IG1lYW4gdGhhdCBldmVuIGlmIGl0IGlzIGNsZWFyIHRoYXQgYSBnaXZlbiBwb3J0IHJh bmdlIGZvciBhIGdpdmVuIHB1YmxpYyBJUHY0IGFkZHJlc3MgaXMgc3RhdGljYWxseSBhc3NpZ25l ZCB0byBhIGdpdmVuIHN1YnNjcmliZXIgKGFuZCB0aHVzIG5vIG9uZSBlbHNlIGNhbiB1c2UgaXQp LCB0aGUgSVNQIHN0aWxsIG11c3QgdHJhY2sgYWxsIHRoZSBhY3Rpdml0aWVzIG9mIHRoZSB1c2Vy IChieSBsb2dnaW5nIHRoZSA1LXR1cGxlKT8NCltNZWRdIFllcy4gUGxlYXNlIHJlZmVyIHRvIGh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc29mdHdpcmVzL2E1b3lBMjBoR1JX bFpNNkxYZmt0SllES2Nvaw0KDQpJZiB5b3VyIGFuc3dlciBpcyB5ZXMsIHRoZW4gSSBoYXZlIGEg cXVlc3Rpb24gYWJvdXQgdGhlIGZvbGxvd2luZzoNCg0KICAgU3RhdGVsZXNzIHRlY2hub2xvZ2ll cyB0aGF0IHByZS1hbGxvY2F0ZSB0aGUgSVB2NCBhZGRyZXNzZXMgYW5kIHBvcnRzDQoNCiAgIG9u bHkgcmVxdWlyZSB0aGF0IGNvcGllcyBvZiB0aGUgYWN0aXZlIE1BUCBydWxlcyAoZm9yIE1BUC1F IGFuZCBNQVAtDQoNCiAgIFQpLCBvciBiaW5kaW5nLXRhYmxlIChmb3IgbHc0bzYpIGFyZSByZXRh aW5lZCBhbG9uZyB3aXRoIHRpbWVzdGFtcA0KDQogICBpbmZvcm1hdGlvbiBvZiB3aGVuIHRoZXkg aGF2ZSBiZWVuIGFjdGl2ZS4gIFN1cHBvcnQgdG9vbHMgKGUuZy4sDQoNCiAgIHRob3NlIHVzZWQg dG8gc2VydmUgZGF0YSByZXRlbnRpb24gcmVxdWVzdHMpIG1heSBuZWVkIHRvIGJlIHVwZGF0ZWQN Cg0KICAgdG8gYmUgYXdhcmUgb2YgdGhlIG1lY2hhbmlzbSBpbiB1c2UgKGUuZy4sIGltcGxlbWVu dGluZyB0aGUgTUFQDQoNCiAgIGFsZ29yaXRobSBzbyB0aGF0IElQdjQgaW5mb3JtYXRpb24gY2Fu IGJlIGxpbmtlZCB0byB0aGUgSVB2NiBwcmVmaXgNCg0KICAgZGVsZWdhdGVkIHRvIGEgY2xpZW50 KS4gIEFzIHN0YXRlbGVzcyB0ZWNobm9sb2dpZXMgZG8gbm90IGhhdmUgYQ0KDQogICBjZW50cmFs aXplZCBzdGF0ZWZ1bCBlbGVtZW50IHdoaWNoIGN1c3RvbWVyIHRyYWZmaWMgbmVlZHMgdG8gcGFz cw0KDQogICB0aHJvdWdoLCBzbyBpZiBkYXRhIHJldGVudGlvbiBsYXdzIG1hbmRhdGUgcGVyLXNl c3Npb24gbG9nZ2luZywgdGhlcmUNCg0KICAgaXMgbm8gc2ltcGxlIHdheSBvZiBtZWV0aW5nIHRo aXMgcmVxdWlyZW1lbnQgd2l0aCBhIHN0YXRlbGVzcw0KDQogICB0ZWNobm9sb2d5IGFsb25lLg0K DQpEb2VzIHRoZSB0d28gc3RhdGVtZW50cyB0b2dldGhlciBtZWFuIHRoYXQgdGhlIGxvZ2dpbmcg cmVxdWlyZW1lbnRzIG9mIHRoYXQgY291bnRyaWVzIG1heSBub3QgYmUgc2F0aXNmaWVkLCB3aGVu IHN0YXRlbGVzcyB0ZWNobm9sb2dpZXMgKGUuZy4gTUFQIHByb3RvY29scykgYXJlIHVzZWQ/DQoN CltNZWRdIEZvciB0aGVzZSBjb3VudHJpZXMsIGEg4oCcZ2x1ZeKAnSBpcyBuZWVkZWQgYXQgQlJz Lg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KR8OhYm9yDQoNCg0KDQrCtw0KDQpDaGVlcnMsDQpNZWQN Cg0KRGUgOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQg ZGUgTGVuY3NlIEfDoWJvcg0KRW52b3nDqSA6IGpldWRpIDI0IGphbnZpZXIgMjAxOSAxODoxMw0K w4AgOiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+IGxpc3QNCk9iamV0IDog W3Y2b3BzXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG1ocC12Nm9w cy10cmFuc2l0aW9uLWNvbXBhcmlzb24tMDIudHh0DQoNCkRlYXIgdjZvcHMgTWVtYmVycywNCg0K V2UgaGF2ZSByZXZpc2VkIG91ciBkcmFmdCAiUHJvcyBhbmQgQ29ucyBvZiBJUHY2IFRyYW5zaXRp b24gVGVjaG5vbG9naWVzIGZvciBJUHY0YWFTIiBtYWtpbmcgc2lnbmlmaWNhbnQgY2hhbmdlcyBp bmNsdWRpbmc6DQoNCiAgIG8gIElhbiBGYXJyZXIgaGFzIGpvaW5lZCB1cyBhcyBhbiBhdXRob3Iu DQoNCg0KDQogICBvICBSZXN0cnVjdHVyaW5nOiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGZpdmUg SVB2NGFhUyB0ZWNobm9sb2dpZXMNCg0KICAgICAgd2FzIG1vdmVkIHRvIGEgc2VwYXJhdGUgc2Vj dGlvbi4NCg0KDQoNCiAgIG8gIE1vcmUgZGV0YWlscyBhbmQgZmlndXJlcyB3ZXJlIGFkZGVkIHRv IHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgZml2ZQ0KDQogICAgICBJUHY0YWFTIHRlY2hub2xvZ2ll cy4NCg0KDQoNCiAgIG8gIFNlY3Rpb24gdGl0bGVkICJIaWdoLWxldmVsIEFyY2hpdGVjdHVyZXMg YW5kIHRoZWlyIENvbnNlcXVlbmNlcyINCg0KICAgICAgaGFzIGJlZW4gY29tcGxldGVseSByZXdy aXR0ZW4uDQoNCg0KDQogICBvICBTZXZlcmFsIGFkZGl0aW9ucy9jbGFyaWZpY2F0aW9uIHRocm91 Z2hvdXQgU2VjdGlvbiB0aXRsZWQNCg0KICAgICAgIkRldGFpbGVkIEFuYWx5c2lzIi4NCg0KDQoN CiAgIG8gIFNlY3Rpb24gdGl0bGVkICJQZXJmb3JtYW5jZSBBbmFseXNpcyIgd2FzIGRyb3BwZWQg ZHVlIHRvIGxhY2sgb2YNCg0KICAgICAgcmVzdWx0cyB5ZXQuDQoNCg0KDQogICBvICBXb3JkIGJh c2VkIHRleHQgcG9ydGVkIHRvIFhNTC4NCg0KDQoNCiAgIG8gIEZ1cnRoZXIgdGV4dCBjbGVhbnVw cywgYWRkZWQgdGV4dCBvbiBzdGF0ZSBzeW5jIGFuZCBsb2FkDQoNCiAgICAgIGJhbGFuY2luZy4g IEFkZGl0aW9uYWwgY29tbWVudHMgaW5saW5lIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQNCg0K ICAgICAgZm9yIGZ1dHVyZSB1cGRhdGVzLg0KV2Uga2luZGx5IHJlcXVlc3QgeW91ciBmZWVkYmFj ay4NCkJlc3QgcmVnYXJkcywNCg0KR8OhYm9yIExlbmNzZQ0KDQotLS0tLS0tLSBUb3bDoWJiw610 b3R0IMO8emVuZXQgLS0tLS0tLS0NClTDoXJneToNCg0KTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1sbWhwLXY2b3BzLXRyYW5zaXRpb24tY29tcGFyaXNvbi0wMi50eHQNCg0KRMOh dHVtOg0KDQpUaHUsIDI0IEphbiAyMDE5IDA4OjI1OjQ1IC0wODAwDQoNCkZlbGFkw7M6DQoNCmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K DQpDw61temV0dDoNCg0KTGVlIEhvd2FyZCA8bGVlQGFzZ2FyZC5vcmc+PG1haWx0bzpsZWVAYXNn YXJkLm9yZz4sIEpvcmRpIFBhbGV0IE1hcnRpbmV6IDxqb3JkaS5wYWxldEB0aGVpcHY2Y29tcGFu eS5jb20+PG1haWx0bzpqb3JkaS5wYWxldEB0aGVpcHY2Y29tcGFueS5jb20+LCBJYW4gRmFycmVy IDxpYW4uZmFycmVyQHRlbGVrb20uZGU+PG1haWx0bzppYW4uZmFycmVyQHRlbGVrb20uZGU+LCBK b3JkaSBQYWxldCA8am9yZGkucGFsZXRAdGhlaXB2NmNvbXBhbnkuY29tPjxtYWlsdG86am9yZGku cGFsZXRAdGhlaXB2NmNvbXBhbnkuY29tPiwgR2Fib3IgTGVuY3NlIDxsZW5jc2VAaGl0LmJtZS5o dT48bWFpbHRvOmxlbmNzZUBoaXQuYm1lLmh1PiwgUmljaGFyZCBQYXR0ZXJzb24gPHJpY2hhcmQu cGF0dGVyc29uQHNreS51az48bWFpbHRvOnJpY2hhcmQucGF0dGVyc29uQHNreS51az4NCg0KDQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxtaHAtdjZvcHMtdHJhbnNpdGlvbi1jb21w YXJpc29uLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHYWJvciBM ZW5jc2UgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogZHJhZnQt bG1ocC12Nm9wcy10cmFuc2l0aW9uLWNvbXBhcmlzb24NClJldmlzaW9uOiAwMg0KVGl0bGU6IFBy b3MgYW5kIENvbnMgb2YgSVB2NiBUcmFuc2l0aW9uIFRlY2hub2xvZ2llcyBmb3IgSVB2NGFhUw0K RG9jdW1lbnQgZGF0ZTogMjAxOS0wMS0yNA0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6IDIzDQpVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1sbWhwLXY2b3BzLXRyYW5zaXRpb24tY29tcGFyaXNvbi0wMi50eHQNClN0YXR1czogaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG1ocC12Nm9wcy10cmFuc2l0aW9uLWNv bXBhcmlzb24vDQpIdG1saXplZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxt aHAtdjZvcHMtdHJhbnNpdGlvbi1jb21wYXJpc29uLTAyDQpIdG1saXplZDogaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1sbWhwLXY2b3BzLXRyYW5zaXRpb24tY29t cGFyaXNvbg0KRGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxt aHAtdjZvcHMtdHJhbnNpdGlvbi1jb21wYXJpc29uLTAyDQoNCkFic3RyYWN0Og0KU2V2ZXJhbCBJ UHY2IHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIGhhdmUgYmVlbiBkZXZlbG9wZWQgdG8gcHJvdmlk ZQ0KY3VzdG9tZXJzIHdpdGggSVB2NC1hcy1hLVNlcnZpY2UgKElQdjRhYVMpIGZvciBJU1BzIHdp dGggYW4gSVB2Ni1vbmx5DQphY2Nlc3MgYW5kL29yIGNvcmUgbmV0d29yay4gQWxsIHRoZXNlIHRl Y2hub2xvZ2llcyBoYXZlIHRoZWlyDQphZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzLCBhbmQg ZGVwZW5kaW5nIG9uIGV4aXN0aW5nIHRvcG9sb2d5LA0Kc2tpbGxzLCBzdHJhdGVneSBhbmQgb3Ro ZXIgcHJlZmVyZW5jZXMsIG9uZSBvZiB0aGVzZSB0ZWNobm9sb2dpZXMgbWF5DQpiZSB0aGUgbW9z dCBhcHByb3ByaWF0ZSBzb2x1dGlvbiBmb3IgYSBuZXR3b3JrIG9wZXJhdG9yLg0KDQpUaGlzIGRv Y3VtZW50IGV4YW1pbmVzIHRoZSBmaXZlIG1vc3QgcHJvbWluZW50IElQdjRhYVMgdGVjaG5vbG9n aWVzDQpjb25zaWRlcmluZyBhIG51bWJlciBvZiBkaWZmZXJlbnQgYXNwZWN0cyB0byBwcm92aWRl IG5ldHdvcmsNCm9wZXJhdG9ycyB3aXRoIGFuIGVhc3kgdG8gdXNlIHJlZmVyZW5jZSB0byBhc3Np c3QgaW4gc2VsZWN0aW5nIHRoZQ0KdGVjaG5vbG9neSB0aGF0IGJlc3Qgc3VpdHMgdGhlaXIgbmVl ZHMuDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= --_000_787AE7BB302AE849A7480A190F8B93302EA0F5FDOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrIjsNCglwYW5vc2UtMTowIDAg MCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgs IGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4t dG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdp bi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kg SFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD qWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K CWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6Ymxh Y2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTc1MjQ2MDA0NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTUwOTcyMDE0MCAtNTgyOTcxNTk2IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1 Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgTGVuY3NlLA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiB2Nm9wcyBbbWFpbHRvOnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBMZW5jc2UgR8OhYm9yPGJy Pg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDI5IGphbnZpZXIgMjAxOSAyMTo0ODxicj4N CjxiPsOAJm5ic3A7OjwvYj4gdjZvcHNAaWV0Zi5vcmcgbGlzdDxicj4NCjxiPk9iamV0Jm5ic3A7 OjwvYj4gUmU6IFt2Nm9wc10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWxtaHAtdjZvcHMtdHJhbnNpdGlvbi1jb21wYXJpc29uLTAyLnR4dDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+RGVhciBNZWQsPGJyPg0KPGJyPg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21t ZW50cy4gUGxlYXNlLCBzZWUgbXkgcmVwbGllcyBpbmxpbmUuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS8yNS8yMDE5IDk6MTMgQU0ga2VsdGV6w6lzc2VsLCA8 YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9hPiDDrXJ0YTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPkhpIEdhYm9yLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xv cjpibGFjayZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U29tZSBxdWljayBjb21tZW50cyZuYnNw O29uIHRoZSBkcmFmdDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Zb3UgaW5kaWNhdGUgdGhh dCB0cjY5IGlzIGF2YWlsYWJsZSBmb3IgeGxhdCBwcm92aXNpb25pbmcsIGJ1dCBJ4oCZbSBub3Qg YXdhcmUgb2YgYW55IGRldmljZSBtb2RlbCB3b3JrIGRvbmUgYXQgQkJGIGZvciB4bGF0LiBUaGUg bW9kZWwgc3VwcG9ydHMNCiBEUy1MaXRlIGFuZCBNQVA7IEnigJltIG5vdCBzdXJlIGZvciB0aGUg b3RoZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KSXQgd2lsbCBiZSBhZGRyZXNzZWQgYnkgSWFuLiAoSGUgaGFzIHByZXBh cmVkIHRoZSB0YWJsZS4pPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0g T0sNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Rm9yIFlBTkcsIFJGQzg1MTIg ZG9lcyBzdXBwb3J0IENMQVQvTkFUNjQuIFlvdSBtYXkgdXBkYXRlIHRoZSB0YWJsZSBhY2NvcmRp bmdseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpU aGFuayB5b3UgZm9yIG1lbnRpb25pbmcgdGhhdC4gPHNwYW4gbGFuZz0iRU4tVVMiPk5vdywgSSBo YXZlIGluY2x1ZGVkIGl0IGludG8gdGhlIFhNTCBzb3VyY2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gT0su PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+KEFuZCBhbHNvIGRlbGV0ZWQgUkZD IDYwNTAsIHdoaWNoIHdhcyBhIHR5cG8sIEkgbWVhbnQgUkZDIDYwMjAsIHRoZSBkZWZpbml0aW9u IGZvciBZQU5HKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFlvdSBtYXkgdGhlbiBhZGQgYSBwb2ludGVyIHRv IFJGQzc5NTAuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9y OmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XaHkgRE5TNjQgaXMgbGlzdGVkIGluIHRh YmxlIDI/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K SSB0aGluaywgYmVjYXVzZSBpdCBpcyBvZnRlbiB1c2VkIHRvZ2V0aGVyIHdpdGggNDY0IFhMQVQu IChCdXQgSWFuIGNhbiB0ZWxsLCB3aHkgaGUgaW5jbHVkZWQgaXQuKTxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBPSywgdGhhbmtzLiBMZXTigJlz IHdhaXQgZm9yIElhbiB0byBjbGFyaWZ5LiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5 bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPllv dSBtYXkgYWRkIHBvaW50ZXIgdG8gcmZjNjg4OSB3aGVuIGRpc2N1c3NpbmcgTkFUNjQveGxhdCBt YXR0ZXJzIChzZWN0aW9uIDMuMik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQpJdCBzZWVtcyB0byBiZSBhIGc8L3NwYW4+b29kIGFuYWx5c2lzLiBXZSB3aWxsIGRlZmluaXRl bHkgaW5jbHVkZSBpdC48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPuKAnEluIHRoZSBjZW50cmFsaXplZCBtb2RlbOKAnSBpcyBub3QgdGhhdCBhY2N1cmF0ZSB3 aGVuIHRhbGtpbmcgYWJvdXQgQ0dOcywgYmVjYXVzZSBkaXN0cmlidXRlZCBDR05zIGFyZSBkZXBs b3llZCB0byBhdm9pZCByaXNrcyByZWxhdGVkIHRvDQogY2VudHJhbGl6ZWQgbW9kZWxzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KT2YgY291cnNlLCB3ZSB3YW50ZWQgdG8gcmVmZXIgdG8gdGhlIGZp cnN0IG9uZSBvZiB0aGUgZm9sbG93aW5nIHR3byBjYXNlczo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IENlbnRyYWxpemVkIFN0YXRl ZnVsIE5BUFQ0NCAoRFMtTGl0ZSwgNDY0WExBVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPltNZWRdIEnigJltIG5vdCBzdXJlIDQ2NHhsYXQgY2FuIGJlIGxpc3RlZCBhcyDigJw8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPkNlbnRyYWxpemVkIFN0YXRlZnVsIE5BUFQ0NDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj7igJ08bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5vJm5i c3A7IERpc3RyaWJ1dGVkIFN0YXRlZnVsIE5BUFQ0NCAobHc0bzYsIE1BUC1FLCBNQVAtVCk8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldoaWNoIHdvcmQgd291bGQgeW91IHJlY29tbWVuZCB0byB1c2UgZm9yIHRoYXQ/PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+W01lZF0gSSB3b3VsZCBhdm9pZCBib3RoIGFuZCB1c2Ug4oCcQSYjNDM7 UOKAnSB2cy4g4oCcQ0dOLWJhc2VkIGFwcHJvYWNoZXPigJ0uIENHTi1iYXNlZCBhZGRyZXNzIHNo YXJpbmcgY2FuIGJlIGRlcGxveWVkIGluIGJvdGggY2VudHJhbGl6ZWQgYW5kIGRpc3RyaWJ1dGVk IHNjaGVtZXMuDQogJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5QQ1AgaXMgcmVxdWlyZWQgZm9yIE5BVDY0IChzZWN0aW9u IDQuMyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxicj4NCjwvc3Bhbj5Xb3VsZCB5b3UgYWdyZWUgd2l0aCB0aGUgZm9sbG93aW5n IGNoYW5nZT88bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFBvcnQgQ29udHJvbCBQ cm90b2NvbCAoUENQKSBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4 NzciIHRpdGxlPSImcXVvdDs0NjRYTEFUOiBDb21iaW5hdGlvbiBvZiBTdGF0ZWZ1bCBhbmQgU3Rh dGVsZXNzIFRyYW5zbGF0aW9uJnF1b3Q7Ij5SRkM2ODc3PC9hPl0gcHJvdmlkZXMgYSBtZWNoYW5p c20gZm9yIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2xpZW50IHRvIHJl cXVlc3QgYW4gZXh0ZXJuYWwgcHVibGljIHBvcnQgZnJvbSBhIENHTiBkZXZpY2UgYW5kIGlzPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHN1cHBvcnRlZCBpbiBzb21lIERTLUxp dGUgQUZUUiBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+LS0mZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFBvcnQgQ29udHJvbCBQcm90b2Nv bCAoUENQKSBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4NzciIHRp dGxlPSImcXVvdDs0NjRYTEFUOiBDb21iaW5hdGlvbiBvZiBTdGF0ZWZ1bCBhbmQgU3RhdGVsZXNz IFRyYW5zbGF0aW9uJnF1b3Q7Ij5SRkM2ODc3PC9hPl0gcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9y IGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2xpZW50IHRvIHJlcXVlc3Qg YW4gZXh0ZXJuYWwgcHVibGljIHBvcnQgZnJvbSBhIENHTiBkZXZpY2U8Yj4uIEZvciBzZXJ2ZXIg b3BlcmF0aW9uLCBpdCBpcyByZXF1aXJlZCB3aXRoIE5BVDY0LzQ2NFhMQVQsIGFuZCBpdCA8L2I+ aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3VwcG9ydGVkIGluIHNvbWUg RFMtTGl0ZSBBRlRSIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPltNZWRdIFdvcmtzIGZvciBtZS4gVGhhbmsgeW91Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPllvdSBtYXkgYWRkIHNvbWUg dGV4dCBhYm91dCBkeW5kbnMgaXNzdWVzLiBGb3Igc29sdXRpb25zIG1ha2luZyB1c2Ugb2YgUENQ IChkc2xpdGUpLCBhIHByb3Bvc2FsIGlzIGRlc2NyaWJlZCBpbiBSRkM3MzkzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhhbmsgeW91IGZvciBtZW50 aW9uaW5nIHRoYXQuIFdlIHdpbGwgaW5jbHVkZSBpdCwgdG9vLiA8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBHcmVhdC4gSSBhc3N1bWUgdGhl IGRpc2N1c3Npb24gd2lsbCBjb3ZlciBhbGwgc2NoZW1lcy4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPlRoZSBsb2dnaW5nIHBhcnQgc2hvdWxkIGJlIHVwZGF0ZSB0byByZWZsZWN0IHRo YXQgZXZlbiB3aGVuIEEmIzQzO1AgaXMgZGVwbG95ZWQsIHNvbWUgcmVndWxhdGlvbiBpbiBzcGVj aWZpYyBjb3VudHJpZXMgYXJlIHJlcXVpcmluZyB0aGUgZnVsbA0KIDUtdXBsZSB0byBiZSBsb2dn ZWQhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQo8L3NwYW4+RG8geW91IG1lYW4gdGhhdCBldmVuIGlmIGl0IGlzIGNsZWFy IHRoYXQgYSBnaXZlbiBwb3J0IHJhbmdlIGZvciBhIGdpdmVuIHB1YmxpYyBJUHY0IGFkZHJlc3Mg aXMgc3RhdGljYWxseSBhc3NpZ25lZCB0byBhIGdpdmVuIHN1YnNjcmliZXIgKGFuZCB0aHVzIG5v IG9uZSBlbHNlIGNhbiB1c2UgaXQpLCB0aGUgSVNQIHN0aWxsIG11c3QgdHJhY2sgYWxsIHRoZSBh Y3Rpdml0aWVzIG9mIHRoZSB1c2VyIChieSBsb2dnaW5nIHRoZSA1LXR1cGxlKT88c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5bTWVkXSBZZXMuIFBsZWFzZSByZWZlciB0bw0KPGEgaHJlZj0iaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zb2Z0d2lyZXMvYTVveUEyMGhHUldsWk02TFhm a3RKWURLY29rIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc29mdHdp cmVzL2E1b3lBMjBoR1JXbFpNNkxYZmt0SllES2NvazwvYT4gPC9zcGFuPg0KPHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxicj4NCklmIHlvdXIgYW5zd2VyIGlzIHllcywgdGhlbiBJIGhhdmUgYSBx dWVzdGlvbiBhYm91dCB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBTdGF0ZWxlc3MgdGVjaG5vbG9naWVzIHRo YXQgcHJlLWFsbG9jYXRlIHRoZSBJUHY0IGFkZHJlc3NlcyBhbmQgcG9ydHM8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBvbmx5IHJl cXVpcmUgdGhhdCBjb3BpZXMgb2YgdGhlIGFjdGl2ZSBNQVAgcnVsZXMgKDwvc3Bhbj5mb3IgTUFQ LUUgYW5kIE1BUC08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVCksIG9yIGJp bmRpbmctdGFibGUgKGZvciBsdzRvNikgYXJlIHJldGFpbmVkIGFsb25nIHdpdGggdGltZXN0YW1w PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIG9mIHdoZW4g dGhleSBoYXZlIGJlZW4gYWN0aXZlLiZuYnNwOyBTdXBwb3J0IHRvb2xzIChlLmcuLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aG9zZSB1c2VkIHRvIHNlcnZlIGRhdGEgcmV0 ZW50aW9uIHJlcXVlc3RzKSBtYXkgbmVlZCB0byBiZSB1cGRhdGVkPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IHRvIGJlIGF3YXJlIG9mIHRoZSBtZWNoYW5pc20gaW4gdXNlIChl LmcuLCBpbXBsZW1lbnRpbmcgdGhlIE1BUDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBhbGdvcml0aG0gc28gdGhhdCBJUHY0IGluZm9ybWF0aW9uIGNhbiBiZSBsaW5rZWQgdG8g dGhlIElQdjYgcHJlZml4PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRlbGVn YXRlZCB0byBhIGNsaWVudCkuJm5ic3A7IEFzIHN0YXRlbGVzcyB0ZWNobm9sb2dpZXMgZG8gbm90 IGhhdmUgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjZW50cmFsaXplZCBz dGF0ZWZ1bCBlbGVtZW50IHdoaWNoIGN1c3RvbWVyIHRyYWZmaWMgbmVlZHMgdG8gcGFzczxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aHJvdWdoLCBzbyBpZiBkYXRhIHJldGVu dGlvbiBsYXdzIG1hbmRhdGUgcGVyLXNlc3Npb24gbG9nZ2luZywgdGhlcmU8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaXMgbm8gc2ltcGxlIHdheSBvZiBtZWV0aW5nIHRoaXMg cmVxdWlyZW1lbnQgd2l0aCBhIHN0YXRlbGVzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyB0ZWNobm9sb2d5IGFsb25lLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpEb2VzIHRoZSB0d28gc3RhdGVtZW50cyB0b2dldGhlciBtZWFuIHRoYXQg dGhlIGxvZ2dpbmcgcmVxdWlyZW1lbnRzIG9mIHRoYXQgY291bnRyaWVzIG1heSBub3QgYmUgc2F0 aXNmaWVkLCB3aGVuIHN0YXRlbGVzcyB0ZWNobm9sb2dpZXMgKGUuZy4gTUFQIHByb3RvY29scykg YXJlIHVzZWQ/PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBGb3IgdGhlc2UgY291bnRyaWVzLCBhIOKAnGdsdWXigJ0g aXMgbmVlZGVkIGF0IEJScy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+QmVzdCByZWdhcmRz LDxicj4NCjxicj4NCkfDoWJvcjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk1l ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gdjZvcHMgWzxhIGhyZWY9Im1h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBMZW5jc2UgR8OhYm9yPGJyPg0KPGI+RW52b3nD qSZuYnNwOzo8L2I+IGpldWRpIDI0IGphbnZpZXIgMjAxOSAxODoxMzxicj4NCjxiPsOAJm5ic3A7 OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4g bGlzdDxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW3Y2b3BzXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtbG1ocC12Nm9wcy10cmFuc2l0aW9uLWNvbXBhcmlzb24tMDIu dHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciB2 Nm9wcyBNZW1iZXJzLDxicj4NCjxicj4NCldlIGhhdmUgcmV2aXNlZCBvdXIgZHJhZnQgJnF1b3Q7 UHJvcyBhbmQgQ29ucyBvZiBJUHY2IFRyYW5zaXRpb24gVGVjaG5vbG9naWVzIGZvciBJUHY0YWFT JnF1b3Q7IG1ha2luZyBzaWduaWZpY2FudCBjaGFuZ2VzIGluY2x1ZGluZzo8bzpwPjwvbzpwPjwv cD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgSWFuIEZhcnJlciBoYXMgam9pbmVkIHVzIGFz IGFuIGF1dGhvci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBSZXN0cnVjdHVyaW5nOiB0aGUgZGVzY3JpcHRp b24gb2YgdGhlIGZpdmUgSVB2NGFhUyB0ZWNobm9sb2dpZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2FzIG1vdmVkIHRvIGEgc2VwYXJhdGUg c2VjdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBNb3JlIGRldGFpbHMgYW5kIGZpZ3VyZXMgd2VyZSBh ZGRlZCB0byB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGZpdmU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVB2NGFhUyB0ZWNobm9sb2dpZXMuPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IG8mbmJzcDsgU2VjdGlvbiB0aXRsZWQgJnF1b3Q7SGlnaC1sZXZlbCBBcmNoaXRlY3R1 cmVzIGFuZCB0aGVpciBDb25zZXF1ZW5jZXMmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGFzIGJlZW4gY29tcGxldGVseSByZXdyaXR0 ZW4uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgU2V2ZXJhbCBhZGRpdGlvbnMvY2xhcmlmaWNhdGlvbiB0aHJv dWdob3V0IFNlY3Rpb24gdGl0bGVkPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0RldGFpbGVkIEFuYWx5c2lzJnF1b3Q7LjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBvJm5ic3A7IFNlY3Rpb24gdGl0bGVkICZxdW90O1BlcmZvcm1hbmNlIEFuYWx5c2lzJnF1b3Q7 IHdhcyBkcm9wcGVkIGR1ZSB0byBsYWNrIG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3VsdHMgeWV0LjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFdv cmQgYmFzZWQgdGV4dCBwb3J0ZWQgdG8gWE1MLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvJm5ic3A7IEZ1cnRoZXIgdGV4 dCBjbGVhbnVwcywgYWRkZWQgdGV4dCBvbiBzdGF0ZSBzeW5jIGFuZCBsb2FkPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJhbGFuY2luZy4mbmJz cDsgQWRkaXRpb25hbCBjb21tZW50cyBpbmxpbmUgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3Ig ZnV0dXJlIHVwZGF0ZXMuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+V2Uga2luZGx5IHJlcXVlc3QgeW91ciBmZWVkYmFj ay48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2Fy ZHMsPGJyPg0KPGJyPg0KR8OhYm9yIExlbmNzZTxicj4NCjxicj4NCi0tLS0tLS0tIFRvdsOhYmLD rXRvdHQgw7x6ZW5ldCAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4N Cjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0 eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Uw6FyZ3k6IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG1ocC12Nm9wcy10cmFu c2l0aW9uLWNvbXBhcmlzb24tMDIudHh0PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFs aWduOnJpZ2h0Ij48Yj5Ew6F0dW06IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRodSwg MjQgSmFuIDIwMTkgMDg6MjU6NDUgLTA4MDA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQt YWxpZ246cmlnaHQiPjxiPkZlbGFkw7M6IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3Jh cD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxi PkPDrW16ZXR0OiA8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZWUgSG93YXJkIDxhIGhy ZWY9Im1haWx0bzpsZWVAYXNnYXJkLm9yZyI+Jmx0O2xlZUBhc2dhcmQub3JnJmd0OzwvYT4sIEpv cmRpIFBhbGV0IE1hcnRpbmV6DQo8YSBocmVmPSJtYWlsdG86am9yZGkucGFsZXRAdGhlaXB2NmNv bXBhbnkuY29tIj4mbHQ7am9yZGkucGFsZXRAdGhlaXB2NmNvbXBhbnkuY29tJmd0OzwvYT4sIElh biBGYXJyZXINCjxhIGhyZWY9Im1haWx0bzppYW4uZmFycmVyQHRlbGVrb20uZGUiPiZsdDtpYW4u ZmFycmVyQHRlbGVrb20uZGUmZ3Q7PC9hPiwgSm9yZGkgUGFsZXQgPGEgaHJlZj0ibWFpbHRvOmpv cmRpLnBhbGV0QHRoZWlwdjZjb21wYW55LmNvbSI+DQombHQ7am9yZGkucGFsZXRAdGhlaXB2NmNv bXBhbnkuY29tJmd0OzwvYT4sIEdhYm9yIExlbmNzZSA8YSBocmVmPSJtYWlsdG86bGVuY3NlQGhp dC5ibWUuaHUiPg0KJmx0O2xlbmNzZUBoaXQuYm1lLmh1Jmd0OzwvYT4sIFJpY2hhcmQgUGF0dGVy c29uIDxhIGhyZWY9Im1haWx0bzpyaWNoYXJkLnBhdHRlcnNvbkBza3kudWsiPg0KJmx0O3JpY2hh cmQucGF0dGVyc29uQHNreS51ayZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbG1ocC12Nm9wcy10cmFuc2l0aW9uLWNvbXBhcmlzb24tMDIudHh0PGJyPg0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHYWJvciBMZW5jc2UgYW5kIHBvc3RlZCB0byB0aGU8 YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTogZHJhZnQtbG1ocC12Nm9wcy10 cmFuc2l0aW9uLWNvbXBhcmlzb248YnI+DQpSZXZpc2lvbjogMDI8YnI+DQpUaXRsZTogUHJvcyBh bmQgQ29ucyBvZiBJUHY2IFRyYW5zaXRpb24gVGVjaG5vbG9naWVzIGZvciBJUHY0YWFTPGJyPg0K RG9jdW1lbnQgZGF0ZTogMjAxOS0wMS0yNDxicj4NCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Np b248YnI+DQpQYWdlczogMjM8YnI+DQpVUkw6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sbWhwLXY2b3BzLXRyYW5zaXRpb24tY29tcGFyaXNvbi0w Mi50eHQiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxtaHAt djZvcHMtdHJhbnNpdGlvbi1jb21wYXJpc29uLTAyLnR4dDwvYT48YnI+DQpTdGF0dXM6IDxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxtaHAtdjZvcHMtdHJh bnNpdGlvbi1jb21wYXJpc29uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1sbWhwLXY2b3BzLXRyYW5zaXRpb24tY29tcGFyaXNvbi88L2E+PGJyPg0KSHRtbGl6ZWQ6 IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sbWhwLXY2b3BzLXRy YW5zaXRpb24tY29tcGFyaXNvbi0wMiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbG1ocC12Nm9wcy10cmFuc2l0aW9uLWNvbXBhcmlzb24tMDI8L2E+PGJyPg0KSHRtbGl6ZWQ6 IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbG1o cC12Nm9wcy10cmFuc2l0aW9uLWNvbXBhcmlzb24iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1sbWhwLXY2b3BzLXRyYW5zaXRpb24tY29tcGFyaXNvbjwvYT48 YnI+DQpEaWZmOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtbG1ocC12Nm9wcy10cmFuc2l0aW9uLWNvbXBhcmlzb24tMDIiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxtaHAtdjZvcHMtdHJhbnNpdGlvbi1jb21wYXJpc29u LTAyPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NClNldmVyYWwgSVB2NiB0cmFuc2l0aW9u IHRlY2hub2xvZ2llcyBoYXZlIGJlZW4gZGV2ZWxvcGVkIHRvIHByb3ZpZGU8YnI+DQpjdXN0b21l cnMgd2l0aCBJUHY0LWFzLWEtU2VydmljZSAoSVB2NGFhUykgZm9yIElTUHMgd2l0aCBhbiBJUHY2 LW9ubHk8YnI+DQphY2Nlc3MgYW5kL29yIGNvcmUgbmV0d29yay4gQWxsIHRoZXNlIHRlY2hub2xv Z2llcyBoYXZlIHRoZWlyPGJyPg0KYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcywgYW5kIGRl cGVuZGluZyBvbiBleGlzdGluZyB0b3BvbG9neSw8YnI+DQpza2lsbHMsIHN0cmF0ZWd5IGFuZCBv dGhlciBwcmVmZXJlbmNlcywgb25lIG9mIHRoZXNlIHRlY2hub2xvZ2llcyBtYXk8YnI+DQpiZSB0 aGUgbW9zdCBhcHByb3ByaWF0ZSBzb2x1dGlvbiBmb3IgYSBuZXR3b3JrIG9wZXJhdG9yLjxicj4N Cjxicj4NClRoaXMgZG9jdW1lbnQgZXhhbWluZXMgdGhlIGZpdmUgbW9zdCBwcm9taW5lbnQgSVB2 NGFhUyB0ZWNobm9sb2dpZXM8YnI+DQpjb25zaWRlcmluZyBhIG51bWJlciBvZiBkaWZmZXJlbnQg YXNwZWN0cyB0byBwcm92aWRlIG5ldHdvcms8YnI+DQpvcGVyYXRvcnMgd2l0aCBhbiBlYXN5IHRv IHVzZSByZWZlcmVuY2UgdG8gYXNzaXN0IGluIHNlbGVjdGluZyB0aGU8YnI+DQp0ZWNobm9sb2d5 IHRoYXQgYmVzdCBzdWl0cyB0aGVpciBuZWVkcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNy ZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_787AE7BB302AE849A7480A190F8B93302EA0F5FDOPEXCAUBMA2corp_-- From nobody Wed Jan 30 02:16: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 08D1C130F3E for ; Wed, 30 Jan 2019 02:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHMdOrrOxVyt for ; Wed, 30 Jan 2019 02:16:12 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCBC130F3A for ; Wed, 30 Jan 2019 02:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Iv+bGVqPjid5yZgRTPF/PuLbhsXr7foHR1BqOMHMXmM=; b=AnvpB11ILLgY29L4TGT2Oq6+I240anqlooL/cYHzu94kLzzNI6E9tlpOGkIhNYiO0xvX9HLR/sLjRFvCVgdQwq7LLMbPyqQuFe8B9jRgvtN7Dt99i+dSfv67iyRu78tl3EG51tXS8IbRKDvV2lMQNPKT57C4VxYRNl/uFMeU78A= Received: from DB7PR07MB4795.eurprd07.prod.outlook.com (52.135.141.153) by DB7PR07MB5596.eurprd07.prod.outlook.com (20.178.43.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.12; Wed, 30 Jan 2019 10:16:08 +0000 Received: from DB7PR07MB4795.eurprd07.prod.outlook.com ([fe80::c43e:f439:da1b:46c5]) by DB7PR07MB4795.eurprd07.prod.outlook.com ([fe80::c43e:f439:da1b:46c5%4]) with mapi id 15.20.1580.017; Wed, 30 Jan 2019 10:16:08 +0000 From: tom petch To: "v6ops@ietf.org" , =?utf-8?B?TGVuY3NlIEfDoWJvcg==?= Thread-Topic: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt Thread-Index: AQHUuITRI7IS2fzpdUSpsaU/80Tu6w== Date: Wed, 30 Jan 2019 10:16:08 +0000 Message-ID: <014401d4b884$a93677e0$4001a8c0@gateway.2wire.net> References: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> <0a3ef70d-851e-f8ba-97d5-37186e8872f8@hit.bme.hu> <787AE7BB302AE849A7480A190F8B93302EA0D949@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7291a25b-25a7-78f5-952b-6fe8b70018b5@hit.bme.hu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0018.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::30) To DB7PR07MB4795.eurprd07.prod.outlook.com (2603:10a6:5:3c::25) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.184] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB5596; 6:lJzWzR4xlDBpd6I8aCpGz5h+8GMGugIcmuqE51YGU+K1QfedDUpyJOlzATLh/O1xwpzoJHQIog33Bn+NAFPOdGsu/I2aCyyo/kExJY4RumsbgRO8TyJBypV+z3Monyb6f7thoTNVRt/dIGTmcKMJV4brlvvnZj5+EyjYyxqmtLGbFBke+8Z2azBZ8/Y9KJj8lZSt+C9uAfY02ruu+kNe/eV7Xo4hARai+pjAH0uEvDIds78qG7SjaCBeji0kn5dOx04q96csrCQOIywG4ZDlLYOuYoZZQbjFU9/J3dCYufeWIl/o3q7qSYHMRPMWM8NstCXBUxQI9DuymcGOCvuXsMRXSmSWGFOyvAlYio1Xp7t17tVf/F+gprPMg8UT57o8Xyc5Bn3Ba/oCim6trhuRaq+rg8TZCcmW7PEHcsxIYNSeDn9G8ELl+H9PC2Zcj3aMR33dDzE/rw6Um/xorUHY3g==; 5:PkDZBdOvlbCBWc9QEWrKEjkNRlx32KsWaBdu2QzZGBRLN7Q1LRb9T5WFBjz1vIXpjMlkUTTN4Gl26wLQ76rIqDfe/50AWvc0bo+vfF9Qeu4DeT9SwAobNki8twIMoOZB71O1rsjsIih9YV4WoL1lBiCZJF+/ucmhrUYmZitrKTqodWTapBP5QgerEZcxxXWh0yjFHLnxJG1/smQ5fNkKdA==; 7:GNQYRlBuKOoWiF9ZdePIW67brfvbdL54QpN+6EJ3+EZcYAkDl4qMjnFLnZBe8Ynbc8MyY6Nlxk5Yt5T1P08sx1si6bzyyFMovgJ+3gz95d45iHZvkG0d+DWLIwSTvwNpW2glskBPl01M9OI6mFUnaw== x-ms-office365-filtering-correlation-id: 69a633d6-01f9-40a6-c537-08d6869bf3a6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7193020); SRVR:DB7PR07MB5596; x-ms-traffictypediagnostic: DB7PR07MB5596: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(136003)(346002)(13464003)(189003)(199004)(66066001)(4720700003)(81156014)(305945005)(345774005)(105586002)(3846002)(256004)(14444005)(6116002)(6436002)(81166006)(66574012)(6306002)(86152003)(6512007)(9686003)(478600001)(8676002)(25786009)(44736005)(50226002)(6486002)(61296003)(97736004)(62236002)(561944003)(71200400001)(966005)(71190400001)(8936002)(44716002)(316002)(86362001)(102836004)(99286004)(2501003)(1556002)(110136005)(186003)(229853002)(93886005)(6506007)(26005)(14454004)(106356001)(81686011)(386003)(6246003)(14496001)(76176011)(52116002)(486006)(446003)(84392002)(81816011)(15650500001)(476003)(68736007)(2906002)(33896004)(7736002)(53936002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5596; H:DB7PR07MB4795.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: U1mRT9zN6cdc57mu5JBw16lfzvgXBBWTZuKiLybywieIveqpY0ZCFnzr+fIH7rUgKJaykW/KhT+UX8FEyKVTfMCx4T8OSCSXn3L4lXXrI96zn+Koyv4K/0Fr25cY3ZlmZBpHgKa7DLRJhBe0TV9R/vodW/BOthajzdlccQirG7bBtdErB/trMCn56VwEUj/ct9Ri4eaWDngAn4IzR4mg6hUQTdUwIQBLczDss6HpzaPfVW35ZD51lMNCHjF0Jfdf8b6l+DrorEcm8GPgJRqjkpay8wTtHkbw+AhzvusmsqLp2hjMy8NaKP8/DSslqebg2qtZfPy4sUW5Nqn3SwkLSSGwEPSQKuayHbK6x6e46M8hvAzq+aj2lJKR1Mgq0Bg7aScIa2qNsgJcGTYkZA8tR/rNxdlvrNqHvylWfIRxTHg= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69a633d6-01f9-40a6-c537-08d6869bf3a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 10:16:08.2647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5596 Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-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: Wed, 30 Jan 2019 10:16:16 -0000 VG9wIHBvc3Rpbmcgb25lIG1pbm9yIHBvaW50Lg0KDQpZQU5HIGlzIFJGQzc5NTAgdW5sZXNzIHlv dSBwYXJ0aWN1bGFybHkgd2FudCB0aGUgcHJldmlvdXMgdmVyc2lvbi4NCg0KVG9tIFBldGNoDQoN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkxlbmNzZSBHw6Fib3IiIDxs ZW5jc2VAaGl0LmJtZS5odT4NClRvOiA8djZvcHNAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDI5LCAyMDE5IDg6NDcgUE0NCg0KDQo+IERlYXIgTWVkLA0KPg0KPiBUaGFuayB5b3Ug dmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2UsIHNlZSBteSByZXBsaWVzIGlubGlu ZS4NCj4NCj4gMS8yNS8yMDE5IDk6MTMgQU0ga2VsdGV6w6lzc2VsLCBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIMOtcnRhOg0KPiA+DQo+ID4gSGkgR2Fib3IsDQo+ID4NCj4gPiBTb21lIHF1 aWNrIGNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCj4gPg0KPiA+IMK3WW91IGluZGljYXRlIHRoYXQg dHI2OSBpcyBhdmFpbGFibGUgZm9yIHhsYXQgcHJvdmlzaW9uaW5nLCBidXQgSeKAmW0NCj4gPiBu b3QgYXdhcmUgb2YgYW55IGRldmljZSBtb2RlbCB3b3JrIGRvbmUgYXQgQkJGIGZvciB4bGF0LiBU aGUgbW9kZWwNCj4gPiBzdXBwb3J0cyBEUy1MaXRlIGFuZCBNQVA7IEnigJltIG5vdCBzdXJlIGZv ciB0aGUgb3RoZXIuDQo+ID4NCj4NCj4gSXQgd2lsbCBiZSBhZGRyZXNzZWQgYnkgSWFuLiAoSGUg aGFzIHByZXBhcmVkIHRoZSB0YWJsZS4pDQo+DQo+ID4gwrdGb3IgWUFORywgUkZDODUxMiBkb2Vz IHN1cHBvcnQgQ0xBVC9OQVQ2NC4gWW91IG1heSB1cGRhdGUgdGhlIHRhYmxlDQo+ID4gYWNjb3Jk aW5nbHkuDQo+ID4NCj4NCj4gVGhhbmsgeW91IGZvciBtZW50aW9uaW5nIHRoYXQuIE5vdywgSSBo YXZlIGluY2x1ZGVkIGl0IGludG8gdGhlIFhNTA0KPiBzb3VyY2UuIChBbmQgYWxzbyBkZWxldGVk IFJGQyA2MDUwLCB3aGljaCB3YXMgYSB0eXBvLCBJIG1lYW50IFJGQw0KNjAyMCwNCj4gdGhlIGRl ZmluaXRpb24gZm9yIFlBTkcpDQo+DQo+DQo+ID4gwrdXaHkgRE5TNjQgaXMgbGlzdGVkIGluIHRh YmxlIDI/DQo+ID4NCj4NCj4gSSB0aGluaywgYmVjYXVzZSBpdCBpcyBvZnRlbiB1c2VkIHRvZ2V0 aGVyIHdpdGggNDY0IFhMQVQuIChCdXQgSWFuIGNhbg0KPiB0ZWxsLCB3aHkgaGUgaW5jbHVkZWQg aXQuKQ0KPg0KPiA+IMK3WW91IG1heSBhZGQgcG9pbnRlciB0byByZmM2ODg5IHdoZW4gZGlzY3Vz c2luZyBOQVQ2NC94bGF0IG1hdHRlcnMNCj4gPiAoc2VjdGlvbiAzLjIpDQo+ID4NCj4NCj4gSXQg c2VlbXMgdG8gYmUgYSBnb29kIGFuYWx5c2lzLiBXZSB3aWxsIGRlZmluaXRlbHkgaW5jbHVkZSBp dC4NCj4NCj4gPiDCt+KAnEluIHRoZSBjZW50cmFsaXplZCBtb2RlbOKAnSBpcyBub3QgdGhhdCBh Y2N1cmF0ZSB3aGVuIHRhbGtpbmcgYWJvdXQNCj4gPiBDR05zLCBiZWNhdXNlIGRpc3RyaWJ1dGVk IENHTnMgYXJlIGRlcGxveWVkIHRvIGF2b2lkIHJpc2tzIHJlbGF0ZWQNCnRvDQo+ID4gY2VudHJh bGl6ZWQgbW9kZWxzLg0KPiA+DQo+DQo+IE9mIGNvdXJzZSwgd2Ugd2FudGVkIHRvIHJlZmVyIHRv IHRoZSBmaXJzdCBvbmUgb2YgdGhlIGZvbGxvd2luZyB0d28NCmNhc2VzOg0KPg0KPiAgICAgbyAg Q2VudHJhbGl6ZWQgU3RhdGVmdWwgTkFQVDQ0IChEUy1MaXRlLCA0NjRYTEFUKQ0KPg0KPiAgICAg byAgRGlzdHJpYnV0ZWQgU3RhdGVmdWwgTkFQVDQ0IChsdzRvNiwgTUFQLUUsIE1BUC1UKQ0KPg0K Pg0KPiBXaGljaCB3b3JkIHdvdWxkIHlvdSByZWNvbW1lbmQgdG8gdXNlIGZvciB0aGF0Pw0KPg0K PiA+IMK3UENQIGlzIHJlcXVpcmVkIGZvciBOQVQ2NCAoc2VjdGlvbiA0LjMpDQo+ID4NCj4NCj4g V291bGQgeW91IGFncmVlIHdpdGggdGhlIGZvbGxvd2luZyBjaGFuZ2U/DQo+DQo+ICAgICBQb3J0 IENvbnRyb2wgUHJvdG9jb2wgKFBDUCkgW1JGQzY4NzcNCjxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjg3Nz5dIHByb3ZpZGVzIGEgbWVjaGFuaXNtIGZvciBhDQo+ICAgICBjbGllbnQg dG8gcmVxdWVzdCBhbiBleHRlcm5hbCBwdWJsaWMgcG9ydCBmcm9tIGEgQ0dOIGRldmljZSBhbmQg aXMNCj4gICAgIHN1cHBvcnRlZCBpbiBzb21lIERTLUxpdGUgQUZUUiBpbXBsZW1lbnRhdGlvbnMu DQo+DQo+IC0tPg0KPg0KPiAgICAgUG9ydCBDb250cm9sIFByb3RvY29sIChQQ1ApIFtSRkM2ODc3 DQo8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4Nzc+XSBwcm92aWRlcyBhIG1lY2hh bmlzbSBmb3IgYQ0KPiAgICAgY2xpZW50IHRvIHJlcXVlc3QgYW4gZXh0ZXJuYWwgcHVibGljIHBv cnQgZnJvbSBhIENHTiBkZXZpY2UqLiBGb3INCnNlcnZlciBvcGVyYXRpb24sICoqKml0IGlzIHJl cXVpcmVkKiB3aXRoIE5BVDY0LzQ2NFhMQVQsIGFuZCBpdCAqaXMNCj4gICAgIHN1cHBvcnRlZCBp biBzb21lIERTLUxpdGUgQUZUUiBpbXBsZW1lbnRhdGlvbnMuDQo+DQo+DQo+ID4gwrdZb3UgbWF5 IGFkZCBzb21lIHRleHQgYWJvdXQgZHluZG5zIGlzc3Vlcy4gRm9yIHNvbHV0aW9ucyBtYWtpbmcg dXNlDQo+ID4gb2YgUENQIChkc2xpdGUpLCBhIHByb3Bvc2FsIGlzIGRlc2NyaWJlZCBpbiBSRkM3 MzkzDQo+ID4NCj4NCj4gVGhhbmsgeW91IGZvciBtZW50aW9uaW5nIHRoYXQuIFdlIHdpbGwgaW5j bHVkZSBpdCwgdG9vLg0KPg0KPg0KPiA+IMK3VGhlIGxvZ2dpbmcgcGFydCBzaG91bGQgYmUgdXBk YXRlIHRvIHJlZmxlY3QgdGhhdCBldmVuIHdoZW4gQStQIGlzDQo+ID4gZGVwbG95ZWQsIHNvbWUg cmVndWxhdGlvbiBpbiBzcGVjaWZpYyBjb3VudHJpZXMgYXJlIHJlcXVpcmluZyB0aGUNCmZ1bGwN Cj4gPiA1LXVwbGUgdG8gYmUgbG9nZ2VkIQ0KPiA+DQo+DQo+IERvIHlvdSBtZWFuIHRoYXQgZXZl biBpZiBpdCBpcyBjbGVhciB0aGF0IGEgZ2l2ZW4gcG9ydCByYW5nZSBmb3IgYQ0KZ2l2ZW4NCj4g cHVibGljIElQdjQgYWRkcmVzcyBpcyBzdGF0aWNhbGx5IGFzc2lnbmVkIHRvIGEgZ2l2ZW4gc3Vi c2NyaWJlciAoYW5kDQo+IHRodXMgbm8gb25lIGVsc2UgY2FuIHVzZSBpdCksIHRoZSBJU1Agc3Rp bGwgbXVzdCB0cmFjayBhbGwgdGhlDQo+IGFjdGl2aXRpZXMgb2YgdGhlIHVzZXIgKGJ5IGxvZ2dp bmcgdGhlIDUtdHVwbGUpPw0KPg0KPiBJZiB5b3VyIGFuc3dlciBpcyB5ZXMsIHRoZW4gSSBoYXZl IGEgcXVlc3Rpb24gYWJvdXQgdGhlIGZvbGxvd2luZzoNCj4NCj4gICAgIFN0YXRlbGVzcyB0ZWNo bm9sb2dpZXMgdGhhdCBwcmUtYWxsb2NhdGUgdGhlIElQdjQgYWRkcmVzc2VzIGFuZA0KcG9ydHMN Cj4gICAgIG9ubHkgcmVxdWlyZSB0aGF0IGNvcGllcyBvZiB0aGUgYWN0aXZlIE1BUCBydWxlcyAo Zm9yIE1BUC1FIGFuZA0KTUFQLQ0KPiAgICAgVCksIG9yIGJpbmRpbmctdGFibGUgKGZvciBsdzRv NikgYXJlIHJldGFpbmVkIGFsb25nIHdpdGggdGltZXN0YW1wDQo+ICAgICBpbmZvcm1hdGlvbiBv ZiB3aGVuIHRoZXkgaGF2ZSBiZWVuIGFjdGl2ZS4gIFN1cHBvcnQgdG9vbHMgKGUuZy4sDQo+ICAg ICB0aG9zZSB1c2VkIHRvIHNlcnZlIGRhdGEgcmV0ZW50aW9uIHJlcXVlc3RzKSBtYXkgbmVlZCB0 byBiZQ0KdXBkYXRlZA0KPiAgICAgdG8gYmUgYXdhcmUgb2YgdGhlIG1lY2hhbmlzbSBpbiB1c2Ug KGUuZy4sIGltcGxlbWVudGluZyB0aGUgTUFQDQo+ICAgICBhbGdvcml0aG0gc28gdGhhdCBJUHY0 IGluZm9ybWF0aW9uIGNhbiBiZSBsaW5rZWQgdG8gdGhlIElQdjYNCnByZWZpeA0KPiAgICAgZGVs ZWdhdGVkIHRvIGEgY2xpZW50KS4gIEFzIHN0YXRlbGVzcyB0ZWNobm9sb2dpZXMgZG8gbm90IGhh dmUgYQ0KPiAgICAgY2VudHJhbGl6ZWQgc3RhdGVmdWwgZWxlbWVudCB3aGljaCBjdXN0b21lciB0 cmFmZmljIG5lZWRzIHRvIHBhc3MNCj4gICAgIHRocm91Z2gsIHNvIGlmIGRhdGEgcmV0ZW50aW9u IGxhd3MgbWFuZGF0ZSBwZXItc2Vzc2lvbiBsb2dnaW5nLA0KdGhlcmUNCj4gICAgIGlzIG5vIHNp bXBsZSB3YXkgb2YgbWVldGluZyB0aGlzIHJlcXVpcmVtZW50IHdpdGggYSBzdGF0ZWxlc3MNCj4g ICAgIHRlY2hub2xvZ3kgYWxvbmUuDQo+DQo+DQo+IERvZXMgdGhlIHR3byBzdGF0ZW1lbnRzIHRv Z2V0aGVyIG1lYW4gdGhhdCB0aGUgbG9nZ2luZyByZXF1aXJlbWVudHMgb2YNCj4gdGhhdCBjb3Vu dHJpZXMgbWF5IG5vdCBiZSBzYXRpc2ZpZWQsIHdoZW4gc3RhdGVsZXNzIHRlY2hub2xvZ2llcyAo ZS5nLg0KPiBNQVAgcHJvdG9jb2xzKSBhcmUgdXNlZD8NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0K PiBHw6Fib3INCj4NCj4gPg0KPiA+IENoZWVycywNCj4gPg0KPiA+IE1lZA0KPiA+DQo+ID4gKkRl IDoqdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSAqRGUgbGEgcGFydCBkZSog TGVuY3NlDQpHw6Fib3INCj4gPiAqRW52b3nDqSA6KiBqZXVkaSAyNCBqYW52aWVyIDIwMTkgMTg6 MTMNCj4gPiAqw4AgOiogdjZvcHNAaWV0Zi5vcmcgbGlzdA0KPiA+ICpPYmpldCA6KiBbdjZvcHNd IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LWxtaHAtdjZvcHMt dHJhbnNpdGlvbi1jb21wYXJpc29uLTAyLnR4dA0KPiA+DQo+ID4gRGVhciB2Nm9wcyBNZW1iZXJz LA0KPiA+DQo+ID4gV2UgaGF2ZSByZXZpc2VkIG91ciBkcmFmdCAiUHJvcyBhbmQgQ29ucyBvZiBJ UHY2IFRyYW5zaXRpb24NCj4gPiBUZWNobm9sb2dpZXMgZm9yIElQdjRhYVMiIG1ha2luZyBzaWdu aWZpY2FudCBjaGFuZ2VzIGluY2x1ZGluZzoNCj4gPg0KPiA+ICBvIElhbiBGYXJyZXIgaGFzIGpv aW5lZCB1cyBhcyBhbiBhdXRob3IuDQo+ID4gIG8gUmVzdHJ1Y3R1cmluZzogdGhlIGRlc2NyaXB0 aW9uIG9mIHRoZSBmaXZlIElQdjRhYVMgdGVjaG5vbG9naWVzDQo+ID4gIHdhcyBtb3ZlZCB0byBh IHNlcGFyYXRlIHNlY3Rpb24uDQo+ID4gIG8gTW9yZSBkZXRhaWxzIGFuZCBmaWd1cmVzIHdlcmUg YWRkZWQgdG8gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZQ0KZml2ZQ0KPiA+ICBJUHY0YWFTIHRlY2hu b2xvZ2llcy4NCj4gPiAgbyBTZWN0aW9uIHRpdGxlZCAiSGlnaC1sZXZlbCBBcmNoaXRlY3R1cmVz IGFuZCB0aGVpciBDb25zZXF1ZW5jZXMiDQo+ID4gIGhhcyBiZWVuIGNvbXBsZXRlbHkgcmV3cml0 dGVuLg0KPiA+ICBvIFNldmVyYWwgYWRkaXRpb25zL2NsYXJpZmljYXRpb24gdGhyb3VnaG91dCBT ZWN0aW9uIHRpdGxlZA0KPiA+ICAiRGV0YWlsZWQgQW5hbHlzaXMiLg0KPiA+ICBvIFNlY3Rpb24g dGl0bGVkICJQZXJmb3JtYW5jZSBBbmFseXNpcyIgd2FzIGRyb3BwZWQgZHVlIHRvIGxhY2sgb2YN Cj4gPiAgcmVzdWx0cyB5ZXQuDQo+ID4gIG8gV29yZCBiYXNlZCB0ZXh0IHBvcnRlZCB0byBYTUwu DQo+ID4gIG8gRnVydGhlciB0ZXh0IGNsZWFudXBzLCBhZGRlZCB0ZXh0IG9uIHN0YXRlIHN5bmMg YW5kIGxvYWQNCj4gPiAgYmFsYW5jaW5nLiBBZGRpdGlvbmFsIGNvbW1lbnRzIGlubGluZSB0aGF0 IHNob3VsZCBiZSBjb25zaWRlcmVkDQo+ID4gIGZvciBmdXR1cmUgdXBkYXRlcy4NCj4gPg0KPiA+ IFdlIGtpbmRseSByZXF1ZXN0IHlvdXIgZmVlZGJhY2suDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMs DQo+ID4NCj4gPiBHw6Fib3IgTGVuY3NlDQo+ID4NCj4gPiAtLS0tLS0tLSBUb3bDoWJiw610b3R0 IMO8emVuZXQgLS0tLS0tLS0NCj4gPg0KPiA+ICpUw6FyZ3k6ICoNCj4gPg0KPiA+DQo+ID4NCj4g PiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQpkcmFmdC1sbWhwLXY2b3BzLXRyYW5zaXRp b24tY29tcGFyaXNvbi0wMi50eHQNCj4gPg0KPiA+ICpEw6F0dW06ICoNCj4gPg0KPiA+DQo+ID4N Cj4gPiBUaHUsIDI0IEphbiAyMDE5IDA4OjI1OjQ1IC0wODAwDQo+ID4NCj4gPiAqRmVsYWTDszog Kg0KPiA+DQo+ID4NCj4gPg0KPiA+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gPg0KPiA+ICpDw61temV0dDogKg0KPiA+DQo+ID4N Cj4gPg0KPiA+IExlZSBIb3dhcmQgPGxlZUBhc2dhcmQub3JnPiA8bWFpbHRvOmxlZUBhc2dhcmQu b3JnPiwgSm9yZGkgUGFsZXQNCj4gPiBNYXJ0aW5leiA8am9yZGkucGFsZXRAdGhlaXB2NmNvbXBh bnkuY29tPg0KPiA+IDxtYWlsdG86am9yZGkucGFsZXRAdGhlaXB2NmNvbXBhbnkuY29tPiwgSWFu IEZhcnJlcg0KPiA+IDxpYW4uZmFycmVyQHRlbGVrb20uZGU+IDxtYWlsdG86aWFuLmZhcnJlckB0 ZWxla29tLmRlPiwgSm9yZGkgUGFsZXQNCj4gPiA8am9yZGkucGFsZXRAdGhlaXB2NmNvbXBhbnku Y29tPg0KPiA+IDxtYWlsdG86am9yZGkucGFsZXRAdGhlaXB2NmNvbXBhbnkuY29tPiwgR2Fib3Ig TGVuY3NlDQo+ID4gPGxlbmNzZUBoaXQuYm1lLmh1PiA8bWFpbHRvOmxlbmNzZUBoaXQuYm1lLmh1 PiwgUmljaGFyZCBQYXR0ZXJzb24NCj4gPiA8cmljaGFyZC5wYXR0ZXJzb25Ac2t5LnVrPiA8bWFp bHRvOnJpY2hhcmQucGF0dGVyc29uQHNreS51az4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sbWhwLXY2b3BzLXRyYW5zaXRpb24tY29tcGFyaXNv bi0wMi50eHQNCj4gPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdhYm9yIExl bmNzZSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5h bWU6IGRyYWZ0LWxtaHAtdjZvcHMtdHJhbnNpdGlvbi1jb21wYXJpc29uDQo+ID4gUmV2aXNpb246 IDAyDQo+ID4gVGl0bGU6IFByb3MgYW5kIENvbnMgb2YgSVB2NiBUcmFuc2l0aW9uIFRlY2hub2xv Z2llcyBmb3IgSVB2NGFhUw0KPiA+IERvY3VtZW50IGRhdGU6IDIwMTktMDEtMjQNCj4gPiBHcm91 cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gUGFnZXM6IDIzDQo+ID4gVVJMOg0KPiA+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbG1ocC12Nm9wcy10cmFu c2l0aW9uLWNvbXBhcmkNCnNvbi0wMi50eHQNCj4gPiBTdGF0dXM6DQo+ID4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxtaHAtdjZvcHMtdHJhbnNpdGlvbi1jb21wYXJp c29uLw0KPiA+IEh0bWxpemVkOg0KPiA+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbG1ocC12Nm9wcy10cmFuc2l0aW9uLWNvbXBhcmlzb24tMDINCj4gPiBIdG1saXplZDoNCj4g Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1sbWhwLXY2b3Bz LXRyYW5zaXRpb24tY29tcGFyDQppc29uDQo+ID4gRGlmZjoNCj4gPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxtaHAtdjZvcHMtdHJhbnNpdGlvbi1jb21wYXJpc29u DQotMDINCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+IFNldmVyYWwgSVB2NiB0cmFuc2l0aW9uIHRl Y2hub2xvZ2llcyBoYXZlIGJlZW4gZGV2ZWxvcGVkIHRvIHByb3ZpZGUNCj4gPiBjdXN0b21lcnMg d2l0aCBJUHY0LWFzLWEtU2VydmljZSAoSVB2NGFhUykgZm9yIElTUHMgd2l0aCBhbg0KSVB2Ni1v bmx5DQo+ID4gYWNjZXNzIGFuZC9vciBjb3JlIG5ldHdvcmsuIEFsbCB0aGVzZSB0ZWNobm9sb2dp ZXMgaGF2ZSB0aGVpcg0KPiA+IGFkdmFudGFnZXMgYW5kIGRpc2FkdmFudGFnZXMsIGFuZCBkZXBl bmRpbmcgb24gZXhpc3RpbmcgdG9wb2xvZ3ksDQo+ID4gc2tpbGxzLCBzdHJhdGVneSBhbmQgb3Ro ZXIgcHJlZmVyZW5jZXMsIG9uZSBvZiB0aGVzZSB0ZWNobm9sb2dpZXMNCm1heQ0KPiA+IGJlIHRo ZSBtb3N0IGFwcHJvcHJpYXRlIHNvbHV0aW9uIGZvciBhIG5ldHdvcmsgb3BlcmF0b3IuDQo+ID4N Cj4gPiBUaGlzIGRvY3VtZW50IGV4YW1pbmVzIHRoZSBmaXZlIG1vc3QgcHJvbWluZW50IElQdjRh YVMgdGVjaG5vbG9naWVzDQo+ID4gY29uc2lkZXJpbmcgYSBudW1iZXIgb2YgZGlmZmVyZW50IGFz cGVjdHMgdG8gcHJvdmlkZSBuZXR3b3JrDQo+ID4gb3BlcmF0b3JzIHdpdGggYW4gZWFzeSB0byB1 c2UgcmVmZXJlbmNlIHRvIGFzc2lzdCBpbiBzZWxlY3RpbmcgdGhlDQo+ID4gdGVjaG5vbG9neSB0 aGF0IGJlc3Qgc3VpdHMgdGhlaXIgbmVlZHMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YN Cj4gPiBzdWJtaXNzaW9uDQo+ID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+IFRoZSBJRVRGIFNlY3Jl dGFyaWF0DQo+ID4NCj4NCj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tDQoNCg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBt YWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wcw0KPg0KDQo= From nobody Wed Jan 30 03:01: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 46E92130F59 for ; Wed, 30 Jan 2019 03:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=helix-net-nz.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 EUhembWPqphp for ; Wed, 30 Jan 2019 03:01:28 -0800 (PST) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 8F819130F3C for ; Wed, 30 Jan 2019 03:01:28 -0800 (PST) Received: by mail-yb1-xb35.google.com with SMTP id 7so352210ybp.13 for ; Wed, 30 Jan 2019 03:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X4PxHGNTalkeVUFE5AJXWJIHNBoHi7rWgjikfuX3kqE=; b=ZlrYlYXiBUSs5LS7BuCYDuEKLXHH9CMhJYt8WDqRIUN8w0+gLSbYLYyowjlOka4KZu 0u5ooPJfY8HVJLIpgtcErjPz3B0HjFyzlxrwuDrGSL3gWHI/OoBa3tEXQ1jzROr3lxO7 7Movg+lBfsb0Ri8zvJyuQvLB74mUNsyZEC3PZSePNriqGAXq8F4Y90qy3M4f6Ax/X9RW TGG67p0Bw15Icm3NSv65AnptoU4MKfuErTFS20soaYXsmYwkZwWyuIki7Z3W/hqfoUqg u6WVJrOM/U2WZR6qiDutEZGvq6UoR9AKnV2vqp2z9LgLZa8jD0TyUUQD29+GbA1BWeIL m+9g== 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=X4PxHGNTalkeVUFE5AJXWJIHNBoHi7rWgjikfuX3kqE=; b=elDATw7lIMWXSzUT6RB8XlEGQAn/eVOCr2kYxS4nmS5EnS7ipuhds7NLNqEhoalZbl U40DTfu2VdLUG4f0agTOjie70SkZ8U7T+SsY7FTvuhIhJh8nj2R1lw7v/lux+fR+MVXZ t2DfHvBXa81LhyPjlw/h/n5+TYOiG1dmCIW10O5WtaRgT6+yR+VCpl5GZbTkS79dXnm9 Ua3bfOVBQRBC4ySQPHs6jBvoOl4kc0ao3P/iVPag768iTlWYtMprQpZ6Fjn04+CCOj1P Es7HtlEzGmfVmGiNuqFLQ8QpdaeyFooJXIygA3DIkihX/grihXlpa0PGPJAfOssZuGRu kbJg== X-Gm-Message-State: AHQUAuZh9ICaWIkVWBwNXIJgbLpa5mdwixpl5CqIajXGErRDQ8Db/y9k UmgUqSw/2vU0giqayANJIiegsgtdvqA= X-Google-Smtp-Source: AHgI3IZE6r+m0LiJOuqGXL8CTM3Z1AKB2dgoEtl9TL1pO00UHaF/usGWDvwUn4o7kaQQMu6GqGbeRQ== X-Received: by 2002:a25:8242:: with SMTP id d2mr8927268ybn.507.1548846087688; Wed, 30 Jan 2019 03:01:27 -0800 (PST) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id n16sm507432ywn.31.2019.01.30.03.01.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 03:01:26 -0800 (PST) Received: by mail-yb1-f173.google.com with SMTP id l20so9331011ybl.9 for ; Wed, 30 Jan 2019 03:01:26 -0800 (PST) X-Received: by 2002:a25:9001:: with SMTP id s1mr27567412ybl.493.1548846086430; Wed, 30 Jan 2019 03:01:26 -0800 (PST) MIME-Version: 1.0 References: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> <0a3ef70d-851e-f8ba-97d5-37186e8872f8@hit.bme.hu> <787AE7BB302AE849A7480A190F8B93302EA0D949@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7291a25b-25a7-78f5-952b-6fe8b70018b5@hit.bme.hu> <787AE7BB302AE849A7480A190F8B93302EA0F5FD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0F5FD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Richard Patterson Date: Wed, 30 Jan 2019 11:01:15 +0000 X-Gmail-Original-Message-ID: Message-ID: To: mohamed.boucadair@orange.com Cc: =?UTF-8?Q?Lencse_G=C3=A1bor?= , "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000cb29070580aad4e6" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-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: Wed, 30 Jan 2019 11:01:31 -0000 --000000000000cb29070580aad4e6 Content-Type: text/plain; charset="UTF-8" Hi Med, On Wed, 30 Jan 2019 at 06:41, wrote: > The logging part should be update to reflect that even when A+P > is deployed, some regulation in specific countries are requiring the full > 5-uple to be logged! > I believe that we have already covered this concern with the following statement in section 3.3, do you agree? However, it is also worth noting that if the data retention regulatory requirements in force mandate per-flow logging, then a centralised NAPT44 model may be the only way to meet this requirement. Or would you prefer if we add another similar statement within the logging section as well? -Rich --000000000000cb29070580aad4e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,


On Wed, 30 Jan 2019 = at 06:41, <mohamed.bouca= dair@orange.com> wrote:

=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0= The logging part should be update to reflect that even when A+P is deployed= , some regulation in specific countries are requiring the full 5-uple to be logged!


I believe that we have already covered this concern with the follow= ing statement in section 3.3, do you agree?

   However, it is also worth =
noting that if the data retention
   regulatory requirements in force mandate per-flow logging, then a
   centralised NAPT44 model may be the only way to meet this
   requirement.

Or would you prefer if we ad= d another similar statement within the logging section as well?
<= br>
-Rich=C2=A0
--000000000000cb29070580aad4e6-- From nobody Wed Jan 30 05:21: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 004F81311E8 for ; Wed, 30 Jan 2019 05:21:54 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 MoNNUb4nIKE2 for ; Wed, 30 Jan 2019 05:21:52 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB394130F66 for ; Wed, 30 Jan 2019 05:21:51 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 43qPCf1VQjzBsGh; Wed, 30 Jan 2019 14:21:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 43qPCf0qcmzCqk7; Wed, 30 Jan 2019 14:21:50 +0100 (CET) Received: from OPEXCAUBM23.corporate.adroot.infra.ftgroup (10.114.13.73) by OPEXCLILM6F.corporate.adroot.infra.ftgroup (10.114.31.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 30 Jan 2019 14:21:49 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([fe80::9108:27dc:3496:8db3%21]) with mapi id 14.03.0415.000; Wed, 30 Jan 2019 14:21:49 +0100 From: To: Richard Patterson CC: =?utf-8?B?TGVuY3NlIEfDoWJvcg==?= , "v6ops@ietf.org list" Thread-Topic: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt Thread-Index: AQHUuIsoX4mnlOyQdkCCA5oeDIw+L6XHyF0Q Date: Wed, 30 Jan 2019 13:21:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0F7EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154834714560.29243.6650395366451478724.idtracker@ietfa.amsl.com> <0a3ef70d-851e-f8ba-97d5-37186e8872f8@hit.bme.hu> <787AE7BB302AE849A7480A190F8B93302EA0D949@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7291a25b-25a7-78f5-952b-6fe8b70018b5@hit.bme.hu> <787AE7BB302AE849A7480A190F8B93302EA0F5FD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA0F7EFOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-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: Wed, 30 Jan 2019 13:21:54 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA0F7EFOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwNCg0KSSBwcmVmZXIgdG8gaGF2ZSB0aGUgZGlzY3Vzc2lvbiBpbmNsdWRlZCBp biBvbmUgc2luZ2xlIHBsYWNlOiBTZWN0aW9uIDQuNy4NCg0KSSBhbHNvIHN1Z2dlc3QgdGhhdCBs b2dnaW5nIHNlY3Rpb24gaW5jbHVkZXMgYSBkaXNjdXNzaW9uIGFib3V0IGRldGVybWluaXN0aWMg TkFUIChmb3IgQ0dOcyk6ICBSRkMgNzQyMi4NCg0KVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQN Cg0KRGUgOiBSaWNoYXJkIFBhdHRlcnNvbiBbbWFpbHRvOnJpY2hhcmRAaGVsaXgubmV0Lm56XQ0K RW52b3nDqSA6IG1lcmNyZWRpIDMwIGphbnZpZXIgMjAxOSAxMjowMQ0Kw4AgOiBCT1VDQURBSVIg TW9oYW1lZCBUR0kvT0xODQpDYyA6IExlbmNzZSBHw6Fib3I7IHY2b3BzQGlldGYub3JnIGxpc3QN Ck9iamV0IDogUmU6IFt2Nm9wc10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWxtaHAtdjZvcHMtdHJhbnNpdGlvbi1jb21wYXJpc29uLTAyLnR4dA0KDQpIaSBNZWQsDQoN Cg0KT24gV2VkLCAzMCBKYW4gMjAxOSBhdCAwNjo0MSwgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCg0KICAg ICAgICAgVGhlIGxvZ2dpbmcgcGFydCBzaG91bGQgYmUgdXBkYXRlIHRvIHJlZmxlY3QgdGhhdCBl dmVuIHdoZW4gQStQIGlzIGRlcGxveWVkLCBzb21lIHJlZ3VsYXRpb24gaW4gc3BlY2lmaWMgY291 bnRyaWVzIGFyZSByZXF1aXJpbmcgdGhlIGZ1bGwgNS11cGxlIHRvIGJlIGxvZ2dlZCENCg0KSSBi ZWxpZXZlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGNvdmVyZWQgdGhpcyBjb25jZXJuIHdpdGggdGhl IGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAzLjMsIGRvIHlvdSBhZ3JlZT8NCg0KDQog ICBIb3dldmVyLCBpdCBpcyBhbHNvIHdvcnRoIG5vdGluZyB0aGF0IGlmIHRoZSBkYXRhIHJldGVu dGlvbg0KDQogICByZWd1bGF0b3J5IHJlcXVpcmVtZW50cyBpbiBmb3JjZSBtYW5kYXRlIHBlci1m bG93IGxvZ2dpbmcsIHRoZW4gYQ0KDQogICBjZW50cmFsaXNlZCBOQVBUNDQgbW9kZWwgbWF5IGJl IHRoZSBvbmx5IHdheSB0byBtZWV0IHRoaXMNCg0KICAgcmVxdWlyZW1lbnQuDQoNCk9yIHdvdWxk IHlvdSBwcmVmZXIgaWYgd2UgYWRkIGFub3RoZXIgc2ltaWxhciBzdGF0ZW1lbnQgd2l0aGluIHRo ZSBsb2dnaW5nIHNlY3Rpb24gYXMgd2VsbD8NCg0KLVJpY2gNCg== --_000_787AE7BB302AE849A7480A190F8B93302EA0F7EFOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyBcO2NvbG9yXDpibGFjayI7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNt Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6 MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5nbWFpbC1tMjc1NDYyMDcx NzIxNjEyODAxNW1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0yNzU0NjIwNzE3MjE2MTI4MDE1 bXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0yNzU0NjIwNzE3MjE2MTI4MDE1bXNvbGlzdHBh cmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzI3NTQ2MjA3MTcyMTYxMjgwMTVtc29s aXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhU TUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lm b3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpGUjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQt d2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjczOTA1NjE3MTsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1MDM4ODQ4 MzIgMjAxMDgwODI0NCA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMw MSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgUmljaGFyZCwNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgcHJlZmVyIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24g aW5jbHVkZWQgaW4gb25lIHNpbmdsZSBwbGFjZTogU2VjdGlvbiA0LjcuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SSBhbHNvIHN1Z2dlc3QgdGhh dCBsb2dnaW5nIHNlY3Rpb24gaW5jbHVkZXMgYSBkaXNjdXNzaW9uIGFib3V0IGRldGVybWluaXN0 aWMgTkFUIChmb3IgQ0dOcyk6DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJGQyA3NDIyLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rIHlvdS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gUmljaGFyZCBQYXR0ZXJzb24gW21haWx0bzpyaWNoYXJkQGhlbGl4Lm5ldC5uel0N Cjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAzMCBqYW52aWVyIDIwMTkgMTI6 MDE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE48YnI+DQo8 Yj5DYyZuYnNwOzo8L2I+IExlbmNzZSBHw6Fib3I7IHY2b3BzQGlldGYub3JnIGxpc3Q8YnI+DQo8 Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbdjZvcHNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1sbWhwLXY2b3BzLXRyYW5zaXRpb24tY29tcGFyaXNvbi0wMi50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIE1lZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCAzMCBKYW4gMjAxOSBhdCAwNjo0MSwgJmx0OzxhIGhyZWY9 Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iZ21h aWwtbTI3NTQ2MjA3MTcyMTYxMjgwMTVtc29saXN0cGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6YmxhY2smcXVvdDsiPlRoZSBsb2dn aW5nIHBhcnQgc2hvdWxkIGJlIHVwZGF0ZSB0byByZWZsZWN0IHRoYXQgZXZlbiB3aGVuDQogQSYj NDM7UCBpcyBkZXBsb3llZCwgc29tZSByZWd1bGF0aW9uIGluIHNwZWNpZmljIGNvdW50cmllcyBh cmUgcmVxdWlyaW5nIHRoZSBmdWxsIDUtdXBsZSB0byBiZSBsb2dnZWQhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGNvdmVy ZWQgdGhpcyBjb25jZXJuIHdpdGggdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAz LjMsIGRvIHlvdSBhZ3JlZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBz dHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IEhvd2V2ZXIsIGl0IGlzIGFsc28gd29ydGggbm90aW5nIHRoYXQgaWYgdGhlIGRhdGEg cmV0ZW50aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzIGluIGZvcmNlIG1h bmRhdGUgcGVyLWZsb3cgbG9nZ2luZywgdGhlbiBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNlbnRyYWxpc2VkIE5B UFQ0NCBtb2RlbCBtYXkgYmUgdGhlIG9ubHkgd2F5IHRvIG1lZXQgdGhpczxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBy ZXF1aXJlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T3Igd291bGQgeW91IHByZWZlciBpZiB3ZSBhZGQgYW5vdGhlciBz aW1pbGFyIHN0YXRlbWVudCB3aXRoaW4gdGhlIGxvZ2dpbmcgc2VjdGlvbiBhcyB3ZWxsPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tUmljaCZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93302EA0F7EFOPEXCAUBMA2corp_-- From nobody Thu Jan 31 03:01:03 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 B0E30130ED1; Thu, 31 Jan 2019 03:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UnQTvlj4Ump; Thu, 31 Jan 2019 03:00:44 -0800 (PST) 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 4F85B130EBB; Thu, 31 Jan 2019 03:00:44 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 C045C83959; Thu, 31 Jan 2019 12:00:39 +0100 (CET) To: "6man@ietf.org" <6man@ietf.org>, 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== Message-ID: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> Date: Thu, 31 Jan 2019 08:00:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 11:00:49 -0000 Folks, We have posted a new I-D discussing a problem that can arise in typical deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and advertises a prefix on the LAN side. Our draft is available at: https://tools.ietf.org/html/draft-gont-6man-slaac-renum The Abstract is: A very common IPv6 deployment scenario is that in which a CPE employs DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one prefix from within the leased prefix is advertised on a local network via SLAAC. In scenarios where e.g. the CPE crashes and reboots, nodes on the local network continue using outdated prefixes which result in connectivity problems. This document analyzes this problem scenario, and proposes workarounds. Any comments will be welcome. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 03:40: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 D0F3F130ED1; Thu, 31 Jan 2019 03:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6IzDTWPaKZC; Thu, 31 Jan 2019 03:40:52 -0800 (PST) Received: from zm-out-02.forthnet.gr (zm-out-02.forthnet.gr [194.219.0.14]) (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 E7E7C1274D0; Thu, 31 Jan 2019 03:40:51 -0800 (PST) Received: from zm-in-02.cloud.forthnet.prv (zm-in-02.cloud.forthnet.prv [10.24.31.16]) by zm-out-02.forthnet.gr (Postfix) with ESMTP id AD872121EF0; Thu, 31 Jan 2019 13:40:49 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTP id A401F120DFA; Thu, 31 Jan 2019 13:40:49 +0200 (EET) X-DSPAM-Result: Spam Authentication-Results: zm-in-02.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-02.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-02.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id xiXrSAeAcMgw; Thu, 31 Jan 2019 13:40:48 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTP id B0555120E01; Thu, 31 Jan 2019 13:40:48 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-02.cloud.forthnet.prv B0555120E01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1548934848; bh=13yHgRmjY6ARMgr0ywQgh1u5Xo04xZo0Zuo1f1RSE3Y=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; b=6pdzn5TOktpw0U9BLrAKhBV4+wiRLZhxVYrmphMVUXiPlHD7e81VRTVctcuFc2vyM 3mK3B4nGZUtXYOneh4RlzncsUlg5JGQc9taJ5YudNOkDV0xvENNTC4AiT3tob0fTat XmSNRjMRGR4CcNONafOY+Ex5YpHw2L9QSuiAXRwU= X-Virus-Scanned: amavisd-new at zm-in-02.cloud.forthnet.prv Received: from zm-in-02.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-02.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id NvwisB9LUjuI; Thu, 31 Jan 2019 13:40:48 +0200 (EET) Received: from [IPv6:2a02:2148:82:6000:d047:28fc:68ca:40e9] (unknown [IPv6:2a02:2148:82:6000:d047:28fc:68ca:40e9]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTPA id 7EF4E120DFA; Thu, 31 Jan 2019 13:40:48 +0200 (EET) To: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> From: Tassos Chatzithomaoglou Openpgp: preference=signencrypt Autocrypt: addr=achatz@forthnet.gr; prefer-encrypt=mutual; keydata= xsFNBFxJmLkBEAC2Ias6RaA3HmSOGgwZtUtz9+AuwUCCJSr5sjYwSOK0B62dSoci9TlvRA1b e2qo7iFg2epfhBm1Gn95VKwg54GREE8ewE03LYPpewhsB+UrA5UgDJ6zaHMSPepuYhalYmLJ tTdZkWBDnS86/lMVzeAQ+Mb0QL7porRASb6fUbIkNDGV3HWZrVvfJo+2fVooY3E3HqM5wkOX V1vwa5yqaB6JPcYkMzo3xVfWNQRBJO4aVAnxG8WKzSR/PihQwavoRrVTfxCvtuUgM1UsaLq/ oX+D51AF4rOvN/WH9gI2Zk/Uy0s0rE+563Ve/Z0lT/3UZn7CCRA+1A4NAll9wlr5hRop3PYJ L3UuFN+nlpXZc4Wbs8W3sU8UPCetAUcdLYJXDErr18MtNrc7y7DF9aqjlY0CgswC+hedrgwM VrTrLlB9Av7QsPdjORZOTR4jZZaaqJGOmLeKLhEi4qy3SD/l2IeHvPGV/AB4nFAzFPEYuHj3 pIZEuw1TJudmJRYqyKzaTpo9tTTywh8GmNBp2F+32F7/Ky5/riWyKpsjJ1uPLTeyXtUXYDmr rfSD+j4qU7f72Zk2ilv4l62bhe4hfhgmMCiQ3HNmje3DZSpbvVKXpxz5LFv6P9If09YVRz3W 5s7DDxH7XcrYUwIlgsrmTeK+MxFO84wBX7E10iC3Ew4hskBKCQARAQABzSxUYXNzb3MgQ2hh dHppdGhvbWFvZ2xvdSA8YWNoYXR6QGZvcnRobmV0LmdyPsLBlAQTAQgAPhYhBFTwl+JuVVqT 44Sw4bCYY8me4pWnBQJcSZi5AhsjBQkB6m4ABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJ ELCYY8me4pWnIWAP/14keqWC4PT0+0D1C+GTD4LIoZo8191j86+0h0yrH86MzM+shH0Fq7UG qPkSoYvCMimuiF0QaBJHG2J3OL6f9FQPdoeJsDEctz6BuO4xyXMWnrjo9xfExwG9vUKNcA2p nhDNRLmLf+wfUsVa1ojiiTS3avv+n2nuq0iT0NnKn9VhQ6QOKo376IbBsyu5dolUH6Grnt4s FVhFkAN140F0gczCfXklSWGcUCqs+MT7u8PLGpPWM3gIRse3bdphA49nO0+Qr/6PxwQieaOI oSroOgN2Z8SM2WtJTasO0/RtlmkZEYuAFfpD/PTRlUGKzQMUqbVdjYT73IhvjnBPrIzQ9Z3i HBXctYSTGXROXtt9lMMIixvaMEio87lcBP6DHjrniIpZo1ry0OUTfWgax24tLkmaqh3Ngihf oXAxiIWNgjkxzRFqmlzKtmYZVBiW69Su1oS4uhdcBrGBdEcmYy79b2ZX1joxS+ft9uqjMRt5 dtoGFDj55LRQsIXn+qfDkWVNkDVT7y6a3QQIsgFqT606Ra/LskGtB46xhvzSinygA7MLB6qT +7izQMOr3rTzehPn4mV28wyM5WeOGIu4nAjgZd50rY416/QZElSIt/qCpyZNJh9WYeTwuht8 k4pfeNaplgdoaXd32IDcMEx62+mCmMfR5Suk16jsdxEVZHXT2mQ+zsFNBFxJmLkBEAC+KNEN VrbUD65l9JkhzfZ61Xhhu284T99muussueFLsDRgJi7YmNXXETTKuFcxlInrwXo+V/Y7l5du IEAuPcI5/0Cz3ugPB1xx/M2ekJSbRhqve+Rr3hs/cmwYhy4jYVTgwpjfKUdUqH6lRE1GGEUk m6CwXQeBgWy4QfFz3v+sJwKZZ0NKb50kqTTavUsIS2iv3uDrrJ+0CQopGrn6rNH9+ofBtgwY QMZ2JRVF2Rd45PFW8Zg8IsNIhftLcabdHELuMY1xrGANcihZacp0i8uGwUtn03Jv1qxCJst1 x25p+ntbL08ktWY4P2LKT/YwtJEpQrBWEwMAMgBM2dpyx72mM28F+sUqMTS0/5P/wgMIuszf 2RxjhFmFgDqrMnR2K+q9QBkMfSXbBWe6jGPrpvLiz7dKDbl3Z3RCs4wEUGARVQ+oOHiArzTJ 7gnigd+aGb+2Rir8PTuIOp9PSuuYlAEpobXU0mLRPB+snFT92yrhmcm2QQHeoklNLIpVVOHA 09ZGuL3R4PzsgntUsXVKcL9nE+BIF3M6/A+32pcwAaVBzAipVCogo/nRAlLnLk0OroY/HWmm xv+2QSgPfeeoEvdBCI+xipYQpEX9cG9qJ1f4KyUSOh9KyNfeRQZ23esIwI0R+LjcLMH9sSrM DyH6Mial+VbQWldvI9/Ja9KSRZpWjQARAQABwsF8BBgBCAAmFiEEVPCX4m5VWpPjhLDhsJhj yZ7ilacFAlxJmLkCGwwFCQHqbgAACgkQsJhjyZ7ilafqiQ/+IOK2872s5dZQpd42jabOFFFT qHZb+DEUmSGEBmVKuhLFdl8TFcdXT8IDlIGn4NWPTWaLQrt7OPmIla3RW2VW1SDW6D7iphRZ Qck/61v/kW5NpJzkX5vt/puF+DDOPQJbH/qw6ysgtX/BT3vbfqcbmuLDI4rSW5xg/ZrDD2Vz Nu3Ou1BbPZ7ZXJwRjiKlJc4T/Vtyed7GlRq3AW+g/c4e96h54xCUD27Gq5QdSP3n3ZRNaicm 8SF2pwh5FgmqX15l9yQTGtnhuD+KhrPSzcqQvCz6JYkaixGE9oLV2D+pjpAL7Lm3R0Ohl8BS ogty4sO5fZjnUEjd0rq2jbe7EaanBTLTbFmFSXBsqCWMTHmzxLjia9FoUUIaP66ic8jgtZ1Z oRWQaWpe6fXaytX4HykH2XYTLWzJQPMYSHnsSKBVjktsm1GzobpqxHwcnqLffVpnfPUvzfyb vubfQG0wN91y9KA6yOCKAbSFhsYPpYS5iydFaF1zyHhgqHs52vVP6RzgdCb2DlPnkZpvoyYu GZuT1ujl5V4mDUJ37H8P297LJm/j6sgQPoZxgYC5c8mhX6zdW9cReGC6L3yydT6X0XHtRiJ3 BkqRdzeqF/NeYUTEa4MnMJogSUDwc4Um39jqAiE2y0crCwTQQ/iJKk4E2Vz+kVVIHLOo21XF 0HiN5LjEtNE= Organization: Forthnet Message-ID: <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> Date: Thu, 31 Jan 2019 13:40:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> Content-Type: multipart/alternative; boundary="------------AD87EA3CF0F73C80B1DC2C78" Content-Language: English & Greek Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 11:40:56 -0000 This is a multi-part message in MIME format. --------------AD87EA3CF0F73C80B1DC2C78 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Isn't that handled by L-13 of RFC7084? L-13:=C2=A0 If the delegated prefix changes, i.e., the current prefix is =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 replaced with a ne= w prefix without any overlapping time =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 period, then the I= Pv6 CE router MUST immediately advertise the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 old prefix with a = Preferred Lifetime of zero and a Valid =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lifetime of either= a) zero or b) the lower of the current =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Valid Lifetime and= two hours (which must be decremented in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 real time) in a Ro= uter Advertisement message as described in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 5.5.3, (e)= of [RFC4862]. -- Tassos Fernando Gont wrote on 31/1/2019 1:00 =CE=BC=CE=BC: > Folks, > > We have posted a new I-D discussing a problem that can arise in typical > deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and > advertises a prefix on the LAN side. > > Our draft is available at: > https://tools.ietf.org/html/draft-gont-6man-slaac-renum > > > The Abstract is: > A very common IPv6 deployment scenario is that in which a CPE employ= s > DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one > prefix from within the leased prefix is advertised on a local networ= k > via SLAAC. In scenarios where e.g. the CPE crashes and reboots, > nodes on the local network continue using outdated prefixes which > result in connectivity problems. This document analyzes this proble= m > scenario, and proposes workarounds. > > Any comments will be welcome. > > Thanks! > > Cheers, --------------AD87EA3CF0F73C80B1DC2C78 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Isn't that handled by L-13 of RFC7084?

L-13:=C2=A0 If the delegated prefix changes= , i.e., the current prefix is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 replaced w= ith a new prefix without any overlapping time
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 period, th= en the IPv6 CE router MUST immediately advertise the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 old prefix= with a Preferred Lifetime of zero and a Valid
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lifetime o= f either a) zero or b) the lower of the current
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Valid Life= time and two hours (which must be decremented in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 real time)= in a Router Advertisement message as described in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 5.= 5.3, (e) of [RFC4862].

--
Tassos
Fernando Gont wrote on 31/1/2019 1:00 =CE=BC=CE=BC:
Folks,

We have posted a new I-D discussing a problem that can arise in typical
deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and
advertises a prefix on the LAN side.

Our draft is available at:
https://tools.ietf.org/html/draft-gont-6man-sl=
aac-renum


The Abstract is:
   A very common IPv6 deployment scenario is that in which a CPE employs
   DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one
   prefix from within the leased prefix is advertised on a local network
   via SLAAC.  In scenarios where e.g. the CPE crashes and reboots,
   nodes on the local network continue using outdated prefixes which
   result in connectivity problems.  This document analyzes this problem
   scenario, and proposes workarounds.

Any comments will be welcome.

Thanks!

Cheers,

--------------AD87EA3CF0F73C80B1DC2C78-- From nobody Thu Jan 31 03:44: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 CFF12130ED1; Thu, 31 Jan 2019 03:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.054 X-Spam-Level: X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk38GA8Ic0JZ; Thu, 31 Jan 2019 03:44:04 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5BB1274D0; Thu, 31 Jan 2019 03:44:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2296; q=dns/txt; s=iport; t=1548935043; x=1550144643; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Uo61zhgg8S9PjQ6ggLeqwHdGiEOf7VK3axgb8jWzHUE=; b=gmObw/UOdOUdD7A0we5PW+GFBdGAeuDhafjv9IRL4YmLXHS+fWcQ9V1y FVJpySHQDQZ3dRQHOXIT2aUBeZJE9VjeuwpDE6pNrMmkWeogPFCmUKJcA xtPw8E6Yvdwk8TONcJsCUxkFBC6Oy/BuMtyteFfFHJouJapPAZ8Ep3loY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAC83lJc/4cNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNngQMnhAOIGo1bJZgOgXsLAQEYC4R?= =?us-ascii?q?JAheCdiI0CQ0BAwEBAgEBAm0cDIVKAQEBAQIBAQEhEToLBQsCAQgOCgICJgI?= =?us-ascii?q?CAiULFRACBA4FgyIBgXkID6xSgS+FQ4RqBYELizUXgX+BOAwTghc1gx4BAQO?= =?us-ascii?q?BXoMJMYImAol1mGwJAoctiwYZkjyHO4gSjAACERSBJx84gVZwFTsqAYJBix2?= =?us-ascii?q?FP0ExkA0BAQ?= X-IronPort-AV: E=Sophos;i="5.56,544,1539648000"; d="scan'208";a="234117661" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2019 11:44:02 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x0VBi2wW011493 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Jan 2019 11:44:02 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Jan 2019 05:44:01 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1395.000; Thu, 31 Jan 2019 05:44:01 -0600 From: "Bernie Volz (volz)" To: Fernando Gont CC: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Thread-Topic: A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUuVRHsX2ODcKgIE2mzdLv788KEqXJQdxf Date: Thu, 31 Jan 2019 11:44:01 +0000 Message-ID: <225BBDDB-A6B5-4395-A1F6-B8C3AAC83B26@cisco.com> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> In-Reply-To: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 11:44:06 -0000 UGVyaGFwcyBpdCBpcyBhIG5vbiBpc3N1ZSwgYnV0IHdoYXQgaGFwcGVucyBpZiBtdWx0aXBsZSBS QXMgYXJlIHNlbnQgYXMgdGhlcmUgaXMgdG9vIG11Y2ggaW4gb25lIHRvIHNlbmQgYXMgYSBzaW5n bGUgUkEgKGdpdmVuIE1UVSBhbmQgYXZvaWRpbmcgZnJhZ21lbnRhdGlvbik/IEFuZCB3aGlsZSBw ZXJoYXBzIGZvciB0aGUgdGFyZ2V0IG1hcmtldCB0aGlzIGlzbuKAmXQgbGlrZWx5LCBhcyBob3N0 cyBtYXkgbmVlZCB0byBvcGVyYXRlIGluIG1vcmUgY29tcGxleCBuZXR3b3JrcyAuLi4NCg0KLSBC ZXJuaWUNCg0KPiBPbiBKYW4gMzEsIDIwMTksIGF0IDY6MDEgQU0sIEZlcm5hbmRvIEdvbnQgPGZn b250QHNpNm5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBGb2xrcywNCj4gDQo+IFdlIGhhdmUg cG9zdGVkIGEgbmV3IEktRCBkaXNjdXNzaW5nIGEgcHJvYmxlbSB0aGF0IGNhbiBhcmlzZSBpbiB0 eXBpY2FsDQo+IGRlcGxveW1lbnQgc2NlbmFyaW9zIHdoZXJlIHRoZSBDUEUgb2J0YWlucyBhIHBy ZWZpeCB2aWEgREhDUHY2LVBEIGFuZA0KPiBhZHZlcnRpc2VzIGEgcHJlZml4IG9uIHRoZSBMQU4g c2lkZS4NCj4gDQo+IE91ciBkcmFmdCBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1nb250LTZtYW4tc2xhYWMtcmVudW0NCj4gDQo+IA0KPiBUaGUg QWJzdHJhY3QgaXM6DQo+ICAgQSB2ZXJ5IGNvbW1vbiBJUHY2IGRlcGxveW1lbnQgc2NlbmFyaW8g aXMgdGhhdCBpbiB3aGljaCBhIENQRSBlbXBsb3lzDQo+ICAgREhDUHY2IFByZWZpeCBEZWxlZ2F0 aW9uIHRvIG9idGFpbiBhbiBJUHY2IHByZWZpeCwgYW5kIGF0IGxlYXN0IG9uZQ0KPiAgIHByZWZp eCBmcm9tIHdpdGhpbiB0aGUgbGVhc2VkIHByZWZpeCBpcyBhZHZlcnRpc2VkIG9uIGEgbG9jYWwg bmV0d29yaw0KPiAgIHZpYSBTTEFBQy4gIEluIHNjZW5hcmlvcyB3aGVyZSBlLmcuIHRoZSBDUEUg Y3Jhc2hlcyBhbmQgcmVib290cywNCj4gICBub2RlcyBvbiB0aGUgbG9jYWwgbmV0d29yayBjb250 aW51ZSB1c2luZyBvdXRkYXRlZCBwcmVmaXhlcyB3aGljaA0KPiAgIHJlc3VsdCBpbiBjb25uZWN0 aXZpdHkgcHJvYmxlbXMuICBUaGlzIGRvY3VtZW50IGFuYWx5emVzIHRoaXMgcHJvYmxlbQ0KPiAg IHNjZW5hcmlvLCBhbmQgcHJvcG9zZXMgd29ya2Fyb3VuZHMuDQo+IA0KPiBBbnkgY29tbWVudHMg d2lsbCBiZSB3ZWxjb21lLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gQ2hlZXJzLA0KPiAtLSANCj4g RmVybmFuZG8gR29udA0KPiBTSTYgTmV0d29ya3MNCj4gZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jr cy5jb20NCj4gUEdQIEZpbmdlcnByaW50OiA2NjY2IDMxQzYgRDQ4NCA2M0IyIDhGQjEgRTNDNCBB RTI1IDBENTUgMUQ0RSA3NDkyDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRG IElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1p bmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Thu Jan 31 03:47: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 ECC77130ED1; Thu, 31 Jan 2019 03:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-gpAI5fX_cA; Thu, 31 Jan 2019 03:47:40 -0800 (PST) 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 9C01E1274D0; Thu, 31 Jan 2019 03:47:40 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 949D7B3; Thu, 31 Jan 2019 12:47:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1548935258; bh=z4w10F1/CGobCo1JDHNYRWXy4f0HNGVwKsWfUMDqhHs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lfQL//Uid2ysHwuMAvJ2fIIfByIWizBrr8ChTUi5HmvT4JlrQKOcVTgHjQZm0evPc +w5IRf6v7N3da9yL+HSM464jNqU6dCNTTMYPo780XZY68xRfa37iwflqsgDPh8Gp+f iOMaombFiXsc0u2g74uDm4zxvcpWjx1vKgWaw+WI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9274EB2; Thu, 31 Jan 2019 12:47:38 +0100 (CET) Date: Thu, 31 Jan 2019 12:47:38 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations In-Reply-To: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> Message-ID: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.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] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 11:47:43 -0000 On Thu, 31 Jan 2019, Fernando Gont wrote: > Any comments will be welcome. " o A CPE MUST record, on stable storage, the list of prefixes being advertised on each LAN segment." This is not always doable as some devices have very small flash with no write-leveling, so doing this generally might ruin the flash cells on some devices. This above requirement will drive cost, especially in the low end market of HGWs. * Any prefixes that were previously advertised via SLAAC, but that are not currently intended for address configuration, MUST be advertised with a PIO option with the "A" bit set to 1 and the "Valid Lifetime" and a "Preferred Lifetime" set to 0. Doesn't RFC7084 already say this? L-13. Another comment, typically the lifetime of the LAN PIO is capped at the DHCPv6-PD WAN lease time. I couldn't find this requirement in RFC7084, but I only searched for "lifetime". Anyhow, Openwrt does this and might be good to mention. When the new prefix is received it'll most likely have a higher preferred and valid lifetime, so hosts should use the new prefix just by means of them preferring the higher preferred lifetime of that PIO. So the problem is a bit less than you write in the draft. So while I am generally sympathetic to this draft and what it tries to achieve (especially the part where it ties the router announcing something to what it's later announcing, and lack of something means it's implicitly zero preferred time for that), we need to figure out a few more things first. RFC7084 was informational which made it fairly easy to get through, now you're proposing a standards track document so we need to make sure everything works. Changing all hosts is a big thing. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 31 03:47: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 D45C9130F0E; Thu, 31 Jan 2019 03:47:50 -0800 (PST) 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, MIME_QP_LONG_LINE=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 Yq4KTLEJpMS3; Thu, 31 Jan 2019 03:47:48 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AAA130ED1; Thu, 31 Jan 2019 03:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1548935265; x=1549540065; 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=WOmzK7cUn34fMOYH77ylprRVvlTgyWbotV YrJQ0Z72g=; b=IqZf0d55TgOqjkTeg3Y16k56FV+l4TfPHxTkT9K5EfrdMWLahH DDh1Z2apRgUayc5XyiVoSBcNMgc/iCGZMbNDAfA1Hv7ZPFg4EXNdmM/IDrvGeFqP j0hjTkYIXsGTmge8Lfbmr8jLEui45jF7eKJ/eB/QuBKhW1nvB8RxUMxxE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 31 Jan 2019 12:47:45 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 31 Jan 2019 12:47:45 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006135442.msg; Thu, 31 Jan 2019 12:47:44 +0100 X-MDRemoteIP: 2001:470:1f09:495:8509:9a05:69aa:b8d0 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 31 Jan 2019 12:47:44 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=193435552d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Thu, 31 Jan 2019 12:47:39 +0100 From: JORDI PALET MARTINEZ To: Tassos Chatzithomaoglou , Fernando Gont , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Message-ID: <89D1444F-6A1B-489C-A1F8-2A6422D109A3@consulintel.es> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> In-Reply-To: <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3631783659_1252660024" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 11:47:54 -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_3631783659_1252660024 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The problem is that if the router has been rebooted (example, power outage)= , then it doesn=E2=80=99t know what was the previous or new prefix (if it h= as changed). =20 So, even if the router follows RFC7084, it will not be able to =E2=80=9Crec= ognize=E2=80=9D the change, unless the prefixes are =E2=80=9Cstored=E2=80= =9D in flash or other stable storage. =20 I=E2=80=99ve seen only one vendor doing that. Regards, Jordi =20 =20 =20 De: ipv6 en nombre de Tassos Chatzithomaoglou Organizaci=C3=B3n: Forthnet Fecha: jueves, 31 de enero de 2019, 12:41 Para: Fernando Gont , "6man@ietf.org" <6man@ietf.org= >, IPv6 Operations Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios =20 Isn't that handled by L-13 of RFC7084? L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of either a) zero or b) the lower of the current Valid Lifetime and two hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]. -- Tassos =20 Fernando Gont wrote on 31/1/2019 1:00 =CE=BC=CE=BC: Folks, =20 We have posted a new I-D discussing a problem that can arise in typical deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and advertises a prefix on the LAN side. =20 Our draft is available at: https://tools.ietf.org/html/draft-gont-6man-slaac-renum =20 =20 The Abstract is: =C2=A0=C2=A0 A very common IPv6 deployment scenario is that in which a CPE = employs =C2=A0=C2=A0 DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at leas= t one =C2=A0=C2=A0 prefix from within the leased prefix is advertised on a local = network =C2=A0=C2=A0 via SLAAC.=C2=A0 In scenarios where e.g. the CPE crashes and r= eboots, =C2=A0=C2=A0 nodes on the local network continue using outdated prefixes wh= ich =C2=A0=C2=A0 result in connectivity problems.=C2=A0 This document analyzes = this problem =C2=A0=C2=A0 scenario, and proposes workarounds. =20 Any comments will be welcome. =20 Thanks! =20 Cheers, -------------------------------------------------------------------- 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_3631783659_1252660024 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

The problem is that if the router has been r= ebooted (example, power outage), then it doesn=E2=80=99t know what was the = previous or new prefix (if it has changed).

 

So, even if the r= outer follows RFC7084, it will not be able to =E2=80=9Crecognize=E2=80=9D t= he change, unless the prefixes are =E2=80=9Cstored=E2=80=9D in flash or oth= er stable storage.

 

I=E2=80=99ve seen only one vendor doing that= .


Regards,

Jordi

&= nbsp;

 

 

De: ipv6 <= ipv6-bounces@ietf.org> en nombre de Tassos Chatzithomaoglou <achatz@f= orthnet.gr>
Organizaci=C3=B3n: Forthnet
Fecha: jueve= s, 31 de enero de 2019, 12:41
Para: Fernando Gont <fgont@si6ne= tworks.com>, "6man@ietf.org" <6man@ietf.org>, IPv6 Opera= tions <v6ops@ietf.org>
Asunto: Re: [v6ops] A common problem= with SLAAC in "renumbering" scenarios

 

Isn't that handled by L-13 of RFC70= 84?

L-13:  If the delega= ted prefix changes, i.e., the current prefix is
    =       replaced with a new prefix without any overl= apping time
          perio= d, then the IPv6 CE router MUST immediately advertise the
  &n= bsp;       old prefix with a Preferred Lifeti= me of zero and a Valid
        &= nbsp; Lifetime of either a) zero or b) the lower of the current
 &n= bsp;        Valid Lifetime and two hours= (which must be decremented in
       = ;   real time) in a Router Advertisement message as described in<= br>          Section 5.5.3, (e= ) of [RFC4862].

--
Tassos
 

Fernando Gont wrote on 31/1/2019 1:00 =CE=BC=CE= =BC:

Folks,
 
We have posted a new I-D discussing a problem that can arise in typi=
cal
deployment scenarios =
where the CPE obtains a prefix via DHCPv6-PD and
advertises a prefix on the LAN s=
ide.
 
Our draft is available at:<=
/pre>
https://tools.ietf.org/html/draft-gont-6man=
-slaac-renum
&nb=
sp;
 
The Abstract is:
=C2=A0=C2=A0 A very common IPv6 deployment scenario=
 is that in which a CPE employs
=C2=A0=C2=A0 DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and =
at least one
=C2=A0=C2=A0=
 prefix from within the leased prefix is advertised on a local network=

=C2=A0=C2=A0 via SLAAC.=C2=A0=
 In scenarios where e.g. the CPE crashes and reboots,
=C2=A0=C2=A0 nodes on the local network contin=
ue using outdated prefixes which
=C2=A0=C2=A0 result in connectivity problems.=C2=A0 This document a=
nalyzes this problem
=C2=
=A0=C2=A0 scenario, and proposes workarounds.
 
Any comments will be welcome.
 
Thanks!
 
Cheers,


-----------------------------= --------------------------------------- IETF IPv6 working group mailing lis= t ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listi= nfo/ipv6 ------------------------------------------------------------------= --


**********************************************<= br> 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_3631783659_1252660024-- From nobody Thu Jan 31 03:57: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 38301130EBB; Thu, 31 Jan 2019 03:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 qwiBqINxB13v; Thu, 31 Jan 2019 03:57:14 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60A41274D0; Thu, 31 Jan 2019 03:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1548935831; x=1549540631; 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=bWOqNW6JU+Ft1cpGD7Be9Y/OSWIoEiEkl8mOFtCA198=; b=ZATWALKQH1PfP Y65IkfE9QhSrWB4hK3IwQVUHyVRydEXUgAwquBFlTFt8RoLk634tXqnPqTiL62lh LI+DHvHIrXKQpaL7bjMQxkUAxAWDJFBvGMgIb8DXPNeqMZ8ckQ49rPp7hldXp2VI WCNMBl5nN/pgL4djmmhKia7v+q5tXk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 31 Jan 2019 12:57:11 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 31 Jan 2019 12:57:10 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006135457.msg; Thu, 31 Jan 2019 12:57:09 +0100 X-MDRemoteIP: 2001:470:1f09:495:8509:9a05:69aa:b8d0 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 31 Jan 2019 12:57:09 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=193435552d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Thu, 31 Jan 2019 12:57:06 +0100 From: JORDI PALET MARTINEZ To: Mikael Abrahamsson , Fernando Gont CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: Thread-Topic: A common problem with SLAAC in "renumbering" scenarios References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.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] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 11:57:16 -0000 Exactly, this is the reason why 99% of the CEs don't save this data in the = flash, because it is prone to creating troubles and bringing the CE to a "b= rick" state. I've seen that several times, having for example statistics written in the = internal router flash, easily will break the router, or at least needed a f= actory reset or something similar. Alternatively using a "good quality" USB= stick to save this kind of data, avoids the problem (most of the time, bec= ause from time to time I've got also good USBs being damaged after some mon= ths of usage). I think for example, RIPE Atlas get the same problem from time to time, so = the USBs get wrong. Sometimes reformatting is sufficient, but not always. Mandating that in low cost CEs will mean CEs are no longer "low cost", unle= ss new "safe" opensource ways to keep the flash are available and can be in= cluded in new firmware releases. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ipv6 en nombre de Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Fecha: jueves, 31 de enero de 2019, 12:48 Para: Fernando Gont CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Asunto: Re: A common problem with SLAAC in "renumbering" scenarios On Thu, 31 Jan 2019, Fernando Gont wrote: =20 > Any comments will be welcome. =20 " o A CPE MUST record, on stable storage, the list of prefixes being advertised on each LAN segment." =20 This is not always doable as some devices have very small flash with no= =20 write-leveling, so doing this generally might ruin the flash cells on s= ome=20 devices. This above requirement will drive cost, especially in the low = end=20 market of HGWs. =20 * Any prefixes that were previously advertised via SLAAC, but that are not currently intended for address configuration, MU= ST be advertised with a PIO option with the "A" bit set to 1 and the "Valid Lifetime" and a "Preferred Lifetime" set to 0. =20 Doesn't RFC7084 already say this? L-13. =20 Another comment, typically the lifetime of the LAN PIO is capped at the= =20 DHCPv6-PD WAN lease time. I couldn't find this requirement in RFC7084, = but=20 I only searched for "lifetime". Anyhow, Openwrt does this and might be= =20 good to mention. =20 When the new prefix is received it'll most likely have a higher preferr= ed=20 and valid lifetime, so hosts should use the new prefix just by means of= =20 them preferring the higher preferred lifetime of that PIO. So the probl= em=20 is a bit less than you write in the draft. =20 So while I am generally sympathetic to this draft and what it tries to= =20 achieve (especially the part where it ties the router announcing someth= ing=20 to what it's later announcing, and lack of something means it's implici= tly=20 zero preferred time for that), we need to figure out a few more things= =20 first. RFC7084 was informational which made it fairly easy to get throu= gh,=20 now you're proposing a standards track document so we need to make sure= =20 everything works. Changing all hosts is a big thing. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =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 Thu Jan 31 04:04: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 59CFB130EBB; Thu, 31 Jan 2019 04:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 X8JDvZcv36_R; Thu, 31 Jan 2019 04:04:22 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::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 36E221274D0; Thu, 31 Jan 2019 04:04:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id E19B64A; Thu, 31 Jan 2019 13:04:19 +0100 (CET) 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=1548936258; bh=vZ0S6/CS8baWnIMFlhn +PLh/oLx2hwXtlB4D5iDlG8A=; b=CrlaswmnanJ8r/YOYnwk+2XyHaJw0xyfuQO hHXIBfiAMDKrnfPZddw44wpwViMj7ABWrj4iYHYA0pssuuqxDTENo1sS84/2X2Tx 8dE4yOpQnxNVqORBQRVLnR/RPRgCGtW307bCTlymqauYpfaP0ePBqMhMpoAXxy/K 8CYl93G4= 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 LM2JZr6HzHQR; Thu, 31 Jan 2019 13:04:18 +0100 (CET) Received: from [IPv6:2a02:a213:a300:ce80::10] (unknown [IPv6:2a02:a213:a300:ce80::10]) (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 BFFD349; Thu, 31 Jan 2019 13:04:17 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1EA89B89-27E2-459F-8833-1E6ADEF6BD99"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 31 Jan 2019 13:04:16 +0100 In-Reply-To: Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> To: Mikael Abrahamsson References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 12:04:25 -0000 --Apple-Mail=_1EA89B89-27E2-459F-8833-1E6ADEF6BD99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > " o A CPE MUST record, on stable storage, the list of prefixes = being > advertised on each LAN segment." >=20 > This is not always doable as some devices have very small flash with = no write-leveling, so doing this generally might ruin the flash cells on = some devices. This above requirement will drive cost, especially in the = low end market of HGWs. A flash cell is at least capable of 1000 to 3000 erase/write cycles. = Even if the prefix would change every single day that gives a lifetime = of 3 to 9 years. And prefixes shouldn't change that often anyway. When = looking at more realistic estimates line a change on average once a week = you'l get to 20 years. Seems more than enough for low end extra cheap = devices. I don't see this driving cost up, except for spending a few = hours on properly engineering this. Cheers, Sander --Apple-Mail=_1EA89B89-27E2-459F-8833-1E6ADEF6BD99 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----- iQEzBAEBCAAdFiEE9VC3eloaasvH0nE1oC0DsP4kE7kFAlxS5EAACgkQoC0DsP4k E7kILQf/Q5z/BT6OTyyc5w7JihkGgG9dblxf3lk2Utn46OQkCreHAESYvI83T+3M Y5DhNM6p9p+J176/rJVY6oIJlNJn4B/JnOEyBHjriQnvVRirGmB4BcH4EMD1Q7fT QwQnAyoHa17Bl1Bp6ykDfg/0EMDzzCY3AtSlik98VKf0y+/jkPw/ZAPdXPJpX71R 6BK3lYH9R96itoyGPvAGdtXOPqQVvGWwgcXHpZF9SnR1KjLAPJTGdoGAG3Sx0RZo kudreVK001cUohQGsaQOgB0R89tAFxxhZ/5QCHWdyQlDDaY7bylYsXuvy0coKFQ3 Hay8lJ0YrLHS22StCbSBtvR6zgMtLQ== =scUZ -----END PGP SIGNATURE----- --Apple-Mail=_1EA89B89-27E2-459F-8833-1E6ADEF6BD99-- From nobody Thu Jan 31 04:12: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 BD525130EE0; Thu, 31 Jan 2019 04:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfItnJxnZ2xr; Thu, 31 Jan 2019 04:12:19 -0800 (PST) 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 5AF17130F65; Thu, 31 Jan 2019 04:12:19 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 AC3AF84507; Thu, 31 Jan 2019 13:12:06 +0100 (CET) To: Mikael Abrahamsson Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@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: <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> Date: Thu, 31 Jan 2019 09:11:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 12:12:28 -0000 On 31/1/19 08:47, Mikael Abrahamsson wrote: > On Thu, 31 Jan 2019, Fernando Gont wrote: > >> Any comments will be welcome. > > "   o  A CPE MUST record, on stable storage, the list of prefixes being >       advertised on each LAN segment." > > This is not always doable as some devices have very small flash with no > write-leveling, so doing this generally might ruin the flash cells on > some devices. This above requirement will drive cost, especially in the > low end market of HGWs. I agree 100% percent, for exact reason you point out. In fact, we discussed whether making this a SHOULD, MUST, or not having any normative language about this one at all. Our reasoning was that CPEs not implementing this would simply not claim compliance with this spec. Me, I agree with you that CPEs wouldn't do this in practice, and also that the place to solve this is on the host side -- for robustness reasons. Any proposal on how to address your comment? -- Include the reasoning above? s/MUST/SHOULD/? Remove any normative language for this one? > >       *  Any prefixes that were previously advertised via SLAAC, but >          that are not currently intended for address configuration, MUST >          be advertised with a PIO option with the "A" bit set to 1 and >          the "Valid Lifetime" and a "Preferred Lifetime" set to 0. > > Doesn't RFC7084 already say this? L-13. Yes, and we missed this (thanks!). -- that said, we added this bullet for completeness sake. The case we care about in this doc is the reboot scenario. > Another comment, typically the lifetime of the LAN PIO is capped at the > DHCPv6-PD WAN lease time. I couldn't find this requirement in RFC7084, > but I only searched for "lifetime". Anyhow, Openwrt does this and might > be good to mention. Very good point. Will do in the next rev. > When the new prefix is received it'll most likely have a higher > preferred and valid lifetime, so hosts should use the new prefix just by > means of them preferring the higher preferred lifetime of that PIO. So > the problem is a bit less than you write in the draft. Nothing in the spec says preference is related to the "Preferred Lifetime" timer. i.e., an address is preferred, or it is not... FWIW, this problem came to my radar as a result of an ISP asking for help on how to address this. > So while I am generally sympathetic to this draft and what it tries to > achieve (especially the part where it ties the router announcing > something to what it's later announcing, and lack of something means > it's implicitly zero preferred time for that), we need to figure out a > few more things first. RFC7084 was informational which made it fairly > easy to get through, now you're proposing a standards track document so > we need to make sure everything works. Changing all hosts is a big thing. FWIW, I personally think the way to go is the host-side fix. You do want hosts to get smarter about this, and obviously cannot rely on the CPE to solve this for you. While one might get away with an Informational document that specifies this -- v6ops has done this for RA-related stuff, I think the best and proper way to do it is with a std track document. But, of course, the point of posting the I-D is to see what other folks think.... Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 04:12: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 BC15D131041; Thu, 31 Jan 2019 04:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjAXnoZtdiAh; Thu, 31 Jan 2019 04:12:34 -0800 (PST) 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 E3EA4131023; Thu, 31 Jan 2019 04:12:33 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B5AD7B3; Thu, 31 Jan 2019 13:12:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1548936751; bh=7ocGnQIoXipVhXz7UsNmOWwJlop9Qc1hlVXpJ99sEYY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ca/a8/VyLYcfECz7Ytpbt3o8hhqdBhv4av2oTKeHaGfra+vy4/6y11jdtQ3IqLdgG EiY0z0h19RqtJYe2gmHPxJ2IF3FL0kWJKNjOvSbQUgnHHnudkDpRNcbHWswMqYBDLW ueMkiXv06JASwSvT48qIdnT1HhFlxXXHnAJnkvo8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B3C94B0; Thu, 31 Jan 2019 13:12:31 +0100 (CET) Date: Thu, 31 Jan 2019 13:12:31 +0100 (CET) From: Mikael Abrahamsson To: Sander Steffann cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> In-Reply-To: Message-ID: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.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] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 12:12:40 -0000 On Thu, 31 Jan 2019, Sander Steffann wrote: > A flash cell is at least capable of 1000 to 3000 erase/write cycles. > Even if the prefix would change every single day that gives a lifetime > of 3 to 9 years. And prefixes shouldn't change that often anyway. When > looking at more realistic estimates line a change on average once a week > you'l get to 20 years. Seems more than enough for low end extra cheap > devices. I don't see this driving cost up, except for spending a few > hours on properly engineering this. There are places where they flap your WAN (PPPoE session for instance) every day to renumber you. I have personally experienced this. So it might be possible to do what you're saying but only writing partial information of the prefix, so skip writing lifetimes, and just keep the actual prefix. This is not what a typical DHCP server/client does today, it re-writes the file every time the lease is renewed so it knows about it. Some kind of compromise might be where a "hint" file is written and the only time this is re-written is when the prefix is changed. OpenWrt today stores most volatile things in /tmp which is just /tmpfs. This has the added disadvantage that after a reboot the LAN lease file is empty. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 31 04:13: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 B7AFB130F2B; Thu, 31 Jan 2019 04:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGFweq2dbSK7; Thu, 31 Jan 2019 04:13:23 -0800 (PST) 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 46DDC130FFC; Thu, 31 Jan 2019 04:13:23 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 564388250A; Thu, 31 Jan 2019 13:13:19 +0100 (CET) To: Tassos Chatzithomaoglou , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> 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: <76ea7b13-888c-a978-9fd7-cc8387169215@si6networks.com> Date: Thu, 31 Jan 2019 09:13:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 12:13:34 -0000 On 31/1/19 08:40, Tassos Chatzithomaoglou wrote: > Isn't that handled by L-13 of RFC7084? > > L-13:  If the delegated prefix changes, i.e., the current prefix is >           replaced with a new prefix without any overlapping time >           period, then the IPv6 CE router MUST immediately advertise the >           old prefix with a Preferred Lifetime of zero and a Valid >           Lifetime of either a) zero or b) the lower of the current >           Valid Lifetime and two hours (which must be decremented in >           real time) in a Router Advertisement message as described in >           Section 5.5.3, (e) of [RFC4862]. Yes, we missed this REQ, and will update our doc accordingly. HOwever, this bullet was included for completeness sake. The case we care and are trying to address here is that in which the CPE reboots. Thanks! Cheers, Fernando -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 04:18: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 BEB8F130ED9; Thu, 31 Jan 2019 04:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhuhZjH7X5-u; Thu, 31 Jan 2019 04:18:39 -0800 (PST) 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 F1DDF130ED6; Thu, 31 Jan 2019 04:18:38 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 475C080517; Thu, 31 Jan 2019 13:18:35 +0100 (CET) To: JORDI PALET MARTINEZ , Mikael Abrahamsson Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@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: <360e3a32-e039-cd26-3634-bf3f4c744cdf@si6networks.com> Date: Thu, 31 Jan 2019 09:18:26 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 12:18:42 -0000 On 31/1/19 08:57, JORDI PALET MARTINEZ wrote: > Exactly, this is the reason why 99% of the CEs don't save this data in the flash, because it is prone to creating troubles and bringing the CE to a "brick" state. > > I've seen that several times, having for example statistics written in the internal router flash, easily will break the router, Yes, this has been my point while discussing these issues while working on the I-D. > or at least needed a factory reset or something similar. Alternatively using a "good quality" USB stick to save this kind of data, avoids the problem >(most of the time, because from time to time I've got also good USBs being damaged after some months of usage). Same here. I run a lot of Raspberry Pis for measurement purposes, and quite often the SD cards get damaged. > > I think for example, RIPE Atlas get the same problem from time to time, so the USBs get wrong. Sometimes reformatting is sufficient, but not always. > > Mandating that in low cost CEs will mean CEs are no longer "low cost", unless new "safe" opensource ways to keep the flash are available and can be included in new firmware releases. FWIW, i don't think mandating this is the way to go. We were not sure whether to make this a MUST (and then CPEs might claim whether they comply with this spec or not), a SHOULD, or have no normative language. I guess we could elaborate a bit more about the CPEs, discuss why it may not be feasible to do this, and s/MUST/SHOULD/. What do you think? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 04:21: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 7BFF0130ED9; Thu, 31 Jan 2019 04:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCpiMTivD_-v; Thu, 31 Jan 2019 04:21:47 -0800 (PST) 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 ACC60130EBB; Thu, 31 Jan 2019 04:21:46 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 DFEE682EC5; Thu, 31 Jan 2019 13:21:42 +0100 (CET) To: Sander Steffann , Mikael Abrahamsson Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@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: <44fda109-c84b-4b30-f15b-a8f2a083342c@si6networks.com> Date: Thu, 31 Jan 2019 09:21:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 12:21:49 -0000 On 31/1/19 09:04, Sander Steffann wrote: >> " o A CPE MUST record, on stable storage, the list of prefixes being >> advertised on each LAN segment." >> >> This is not always doable as some devices have very small flash with no write-leveling, so doing this generally might ruin the flash cells on some devices. This above requirement will drive cost, especially in the low end market of HGWs. > > A flash cell is at least capable of 1000 to 3000 erase/write cycles. Even if the prefix would change every single day that gives a lifetime of 3 to 9 years. And prefixes shouldn't change that often anyway. When looking at more realistic estimates line a change on average once a week you'l get to 20 years. Seems more than enough for low end extra cheap devices. I don't see this driving cost up, except for spending a few hours on properly engineering this. You don't really know where these boxes are going to be deployed. I know of several places where you do experience electric outages several times a week. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 04:54: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 67530130EE5; Thu, 31 Jan 2019 04:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tqBdqFnaYynz; Thu, 31 Jan 2019 04:54:04 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::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 82093130EDA; Thu, 31 Jan 2019 04:54:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 415734B; Thu, 31 Jan 2019 13:54:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1548939240; bh=poNuF5ME4P5npN3urJcYVyN3533ISAmaR/FNWcPDNnY=; b=p qQWtqA+90+ZBoJShKBoIwixWCVyAnbQPyFyjRNQx+5dbTmH8wp5tr6vuBH5G12OM /IJTzXyYLAIRC49KPTchiEWG3BXHxmwF/JXBKMBA/g6V2DGUb57z4VpsHWNzPflu 1Hp2LQ+Ck2l88BZZvM1Gmuyvepsgi0AgeK9cct6Zqo= 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 ya_tgBNUWx7w; Thu, 31 Jan 2019 13:54:00 +0100 (CET) Received: from [IPv6:2a02:a213:a300:ce80:642e:e602:1bc4:1829] (unknown [IPv6:2a02:a213:a300:ce80:642e:e602:1bc4:1829]) (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 D8FB74A; Thu, 31 Jan 2019 13:53:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann X-Mailer: iPhone Mail (16C101) In-Reply-To: <44fda109-c84b-4b30-f15b-a8f2a083342c@si6networks.com> Date: Thu, 31 Jan 2019 13:53:59 +0100 Cc: Mikael Abrahamsson , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <44fda109-c84b-4b30-f15b-a8f2a083342c@si6networks.com> To: Fernando Gont Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 12:54:06 -0000 Hi Fernando, > You don't really know where these boxes are going to be deployed. I know > of several places where you do experience electric outages several times a= week. That doesn't require a write until the connection comes back with a differen= t prefix. The "bit of engineering" I mentioned does have to include a bit of= code to only write the new prefix once it has been replaced by something el= se. Cheers, Sander= From nobody Thu Jan 31 05:16: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 B82CD129508; Thu, 31 Jan 2019 05:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 KB0L99711_IZ; Thu, 31 Jan 2019 05:15:55 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EE7128CB7; Thu, 31 Jan 2019 05:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1548940550; x=1549545350; 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=bKRBLqvoE2nHV/mel1oAEcMT7u4Y2zr41zItPIi4ieM=; b=U3jBMXBfQPPNW +LXczx8HGYYENYA9bbt+wDvl5UT4k1HexnjaY41EJRQNvDMl7ZHuL/CkDsCbVESQ gb6KbKfxhHbq2h1dIHUr3xVCtmGcdwCopdeZFUaC5lkagauSp1H7oqgZAtuKX1qv urxF/mtVOgJbWgWvaA5MjDYhCjYrBY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 31 Jan 2019 14:15:50 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 31 Jan 2019 14:15:50 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006135551.msg; Thu, 31 Jan 2019 14:15:50 +0100 X-MDRemoteIP: 2001:470:1f09:495:8509:9a05:69aa:b8d0 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 31 Jan 2019 14:15:50 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=193435552d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Thu, 31 Jan 2019 14:15:49 +0100 From: JORDI PALET MARTINEZ To: Fernando Gont , Sander Steffann , Mikael Abrahamsson CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: <703A71D6-0A13-4CCD-B64E-C87DB903AD21@consulintel.es> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <44fda109-c84b-4b30-f15b-a8f2a083342c@si6networks.com> In-Reply-To: <44fda109-c84b-4b30-f15b-a8f2a083342c@si6networks.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 13:15:58 -0000 Several times a day in many places! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fernando Gont Fecha: jueves, 31 de enero de 2019, 13:22 Para: Sander Steffann , Mikael Abrahamsson CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios On 31/1/19 09:04, Sander Steffann wrote: >> " o A CPE MUST record, on stable storage, the list of prefixes be= ing >> advertised on each LAN segment." >> >> This is not always doable as some devices have very small flash with= no write-leveling, so doing this generally might ruin the flash cells on s= ome devices. This above requirement will drive cost, especially in the low = end market of HGWs. >=20 > A flash cell is at least capable of 1000 to 3000 erase/write cycles. = Even if the prefix would change every single day that gives a lifetime of 3= to 9 years. And prefixes shouldn't change that often anyway. When looking = at more realistic estimates line a change on average once a week you'l get = to 20 years. Seems more than enough for low end extra cheap devices. I don'= t see this driving cost up, except for spending a few hours on properly eng= ineering this. =20 You don't really know where these boxes are going to be deployed. I kno= w of several places where you do experience electric outages several time= s a week. =20 --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 =20 =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 Thu Jan 31 05:25:07 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 56D17129508; Thu, 31 Jan 2019 05:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 8qZLhaWEoOw4; Thu, 31 Jan 2019 05:24:58 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDCE128CB7; Thu, 31 Jan 2019 05:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1548941096; x=1549545896; 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=49GRcBs2vPtN1xrKgJ0dX4FCixxdahV5wNzjHuRkodA=; b=b/xvXHCHCnr4h +i+nnR1/9M8O9C5Sgk4OvG5x5GkOWqU4YqvA936cSnbCbT8q2Ghcec2yzoTyOF/G v0B/3wvWfO3Gj0Rz5RDI4t2qR/2s4srn7WYWH7J+AW+j006RXFhquYhspcsH4p5V bCR7WkViZ80j7YDFgrEc4U/g4iuhus= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 31 Jan 2019 14:24:56 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 31 Jan 2019 14:24:55 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006135564.msg; Thu, 31 Jan 2019 14:24:55 +0100 X-MDRemoteIP: 2001:470:1f09:495:8509:9a05:69aa:b8d0 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 31 Jan 2019 14:24:55 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=193435552d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Thu, 31 Jan 2019 14:24:55 +0100 From: JORDI PALET MARTINEZ To: Fernando Gont , Mikael Abrahamsson CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: Thread-Topic: A common problem with SLAAC in "renumbering" scenarios References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <360e3a32-e039-cd26-3634-bf3f4c744cdf@si6networks.com> In-Reply-To: <360e3a32-e039-cd26-3634-bf3f4c744cdf@si6networks.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 13:25:01 -0000 If the problem is no really about increasing the hardware cost, but proper = engineering, as Sander suggested, to manage how to write info in the flash,= and a CE, even if it has several power outages per day, can last for more = than 5 years, I think is fine to go for MUST. So, in the worst case a CE that get a power outage or whatever else, averag= e 2 times a day, give, for a flash with 3.000 cycles, between 4-5 years CE = lifetime, which I think in most of the case will be sufficient. I'm sure that this can be improved not just with better flash, but with tec= hniques to better manage the flash, file system, etc. My concern is why many routers get corrupted when "saving" data in the flas= h if there is a power outage in the middle of the operation. I'm convinced = it is again about proper engineering. I guess this is the same problem for IoT devices when being update OTA, etc= ., so sure it is solved, but it is not being applied to Linux filesystems i= n routers? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fernando Gont Fecha: jueves, 31 de enero de 2019, 13:18 Para: JORDI PALET MARTINEZ , Mikael Abrahamsson= CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Asunto: Re: A common problem with SLAAC in "renumbering" scenarios On 31/1/19 08:57, JORDI PALET MARTINEZ wrote: > Exactly, this is the reason why 99% of the CEs don't save this data i= n the flash, because it is prone to creating troubles and bringing the CE t= o a "brick" state. >=20 > I've seen that several times, having for example statistics written i= n the internal router flash, easily will break the router,=20 =20 Yes, this has been my point while discussing these issues while working on the I-D. =20 =20 > or at least needed a factory reset or something similar. Alternativel= y using a "good quality" USB stick to save this kind of data, avoids the pr= oblem=20 >(most of the time, because from time to time I've got also good USBs being damaged after some months of usage). =20 Same here. I run a lot of Raspberry Pis for measurement purposes, and quite often the SD cards get damaged. =20 =20 >=20 > I think for example, RIPE Atlas get the same problem from time to tim= e, so the USBs get wrong. Sometimes reformatting is sufficient, but not alw= ays. >=20 > Mandating that in low cost CEs will mean CEs are no longer "low cost"= , unless new "safe" opensource ways to keep the flash are available and can= be included in new firmware releases. =20 FWIW, i don't think mandating this is the way to go. We were not sure whether to make this a MUST (and then CPEs might claim whether they comply with this spec or not), a SHOULD, or have no normative language. =20 I guess we could elaborate a bit more about the CPEs, discuss why it ma= y not be feasible to do this, and s/MUST/SHOULD/. What do you think? =20 Thanks! =20 Cheers, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 =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 Thu Jan 31 05:43: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 9838D1295D8; Thu, 31 Jan 2019 05:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3HN3Bd4eYa3; Thu, 31 Jan 2019 05:43:40 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F221128CB7; Thu, 31 Jan 2019 05:43:40 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1gpCcz-0000FlC; Thu, 31 Jan 2019 14:43:37 +0100 Message-Id: To: ipv6@ietf.org Cc: IPv6 Operations From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> In-reply-to: Your message of "Thu, 31 Jan 2019 12:47:38 +0100 (CET) ." Date: Thu, 31 Jan 2019 14:43:37 +0100 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 13:43:43 -0000 >So while I am generally sympathetic to this draft and what it tries to >achieve (especially the part where it ties the router announcing something >to what it's later announcing, and lack of something means it's implicitly >zero preferred time for that), we need to figure out a few more things >first. RFC7084 was informational which made it fairly easy to get through, >now you're proposing a standards track document so we need to make sure >everything works. Changing all hosts is a big thing. I think changing host behavior is good in this case if we can make hosts more robust. I prefer the network to do the right thing, but reality is that that will not always happen, so it is good to have robust hosts. That said, I don't like playing games with the valid lifetime. Changes to preferred lifetime are relatively benign, setting the valid lifetime of a prefix to zero may have more serious consequences. I think the algorithm can be simplified to: - When a RA is received that contains a PIO with the A bit set, then set the preferred lifetime to zero for all addresses derived from prefixes that were announced by the same router and that are not covered by the current RA. In extreme cases this may cause the preferred lifetime to ping-pong. But that just causes source address selection to become more random, which should be fine. From nobody Thu Jan 31 05:52: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 A696A129508 for ; Thu, 31 Jan 2019 05:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 fq7FQhsknnpe for ; Thu, 31 Jan 2019 05:51:46 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 D98E1130F2B for ; Thu, 31 Jan 2019 05:51:44 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id e12so1297477ybn.10 for ; Thu, 31 Jan 2019 05:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oiGu15fFT508c341d7efDROSCFxjIusS4SdcI1BALLk=; b=wp8Ms/5AIeoe1J3N0/xbFnADe7o0tjb9aweTQ4hzTJWbpwR7fpxK3splC1GEnrRkJJ IwaRr72KyABe2Z7kE2xiV1osEyvzEseleSStz/5UOhi5kQamzLdygLiy+gXcWfkJvaAJ ON49YomEtRhp23kikBLDHen9MP5G3ps/qinuKvFeZQ4Szv7tmHKfIkBhL5hSP0/hpTHZ iZQM+8Q8AQQSbpU1r2LDC43KrZThtOCfpFKWkOjmA3qyhulaYtJ32tzo2gRVqA02bley ctfkk8ctidiIp/sP1mN4Ws9cb98seDvzvVFsy5GTnSN5sPVa4YpyWj1IsAiqyg9m8hAf FXvg== 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=oiGu15fFT508c341d7efDROSCFxjIusS4SdcI1BALLk=; b=pCSzLQb0rcjjdzDzvhe//SjLQwIzj4NSd/l83jpeGB5msw5RjwuEkDtiWfQyhJCbkN WOFBP9ZhAE8d4uCxVGLQrmqucMyPSWWZu7PrXJJdJIryVXy9ftzKmzwFBuKBEs0MQK4b GXfbxwKTJr9q8qpS2Vskiu9QJT7xLkk+BWTTeOOPX4x8jEX0rN1RTMKF210vd97cCPQz vHmbmIVKiu/BavnGDBECqavP7nT8iwP29z1bgqglRiJvg+nJCB8koasT65wDW2xRQC7d BKJI9zamFkz15E2C7XOvWDJwAWzbOxherVMGcS7rh4cpjOrPL/hvz1h9OQyx/8FfVEx7 MHfQ== X-Gm-Message-State: AHQUAub9CdRtV+gYejkPM1gYUStrZ5cGiy1G0yNYiG9Tvh2FVwgc8VSH hkf5fKnnTrrYWojYI/8JA690+g== X-Google-Smtp-Source: AHgI3IbBPrMBkyCHS7UhiSaiMgYVQDQRDmVzF+XEpBIehkCY8XnQrCYFOM6l2s6Qnp/wyNRNLkcEOA== X-Received: by 2002:a25:508f:: with SMTP id e137mr21110950ybb.397.1548942703974; Thu, 31 Jan 2019 05:51:43 -0800 (PST) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id z37sm1739539ywj.3.2019.01.31.05.51.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jan 2019 05:51:43 -0800 (PST) Received: by mail-yb1-f173.google.com with SMTP id y13so1307579ybr.7; Thu, 31 Jan 2019 05:51:43 -0800 (PST) X-Received: by 2002:a25:cd47:: with SMTP id d68mr32359899ybf.90.1548942702946; Thu, 31 Jan 2019 05:51:42 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <76ea7b13-888c-a978-9fd7-cc8387169215@si6networks.com> In-Reply-To: <76ea7b13-888c-a978-9fd7-cc8387169215@si6networks.com> From: Richard Patterson Date: Thu, 31 Jan 2019 13:51:31 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: Tassos Chatzithomaoglou , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 13:51:54 -0000 On Thu, 31 Jan 2019 at 12:15, Fernando Gont wrote: > > On 31/1/19 08:40, Tassos Chatzithomaoglou wrote: > > Isn't that handled by L-13 of RFC7084? > > > > L-13: If the delegated prefix changes, i.e., the current prefix is > > replaced with a new prefix without any overlapping time > > period, then the IPv6 CE router MUST immediately advertise the > > old prefix with a Preferred Lifetime of zero and a Valid > > Lifetime of either a) zero or b) the lower of the current > > Valid Lifetime and two hours (which must be decremented in > > real time) in a Router Advertisement message as described in > > Section 5.5.3, (e) of [RFC4862]. > > Yes, we missed this REQ, and will update our doc accordingly. HOwever, > this bullet was included for completeness sake. The case we care and are > trying to address here is that in which the CPE reboots. I think this requirement already resolves the CPE-side of things, and the rest I believe, is solved server-side? If the CPE is hard rebooted, it hasn't sent a Release, so I'd expect the lease-state to be kept server-side, and re-offered if the DUID+MAC binding is the same when the CPE reconnects. Although, during soft reboots, I have often seen CPEs sending a Release, telling the servers to relinquish the lease. Perhaps we should discuss the benefits/detriments of doing this? From nobody Thu Jan 31 06:23:07 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 2878D129508; Thu, 31 Jan 2019 06:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbTb0PXDaz93; Thu, 31 Jan 2019 06:23:04 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FF2128CB7; Thu, 31 Jan 2019 06:23:04 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 84ECDB2; Thu, 31 Jan 2019 15:23:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1548944580; bh=TDng/gPt1J5g8yZez6R2gQL50JX4Zr2fphGTyICCuI4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=h8UpKxxqE2TW5JkJtYzxmBkEqZe47O84HGUitIjDdBtM7gQsUIAChfHbxDvH9f17i K58u/4RsI3MUIzDaooVwa5X9kKiGZlLa3T3cuozFIp0tahUNeJbTgIBFUJ1WVANtBr blJK6o1EZwQpYzcfTr+dSo3DbqG2vVAM053cmCJs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 82BAEB0; Thu, 31 Jan 2019 15:23:00 +0100 (CET) Date: Thu, 31 Jan 2019 15:23:00 +0100 (CET) From: Mikael Abrahamsson To: Richard Patterson cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> In-Reply-To: Message-ID: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <76ea7b13-888c-a978-9fd7-cc8387169215@si6networks.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] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 14:23:06 -0000 On Thu, 31 Jan 2019, Richard Patterson wrote: > I think this requirement already resolves the CPE-side of things, and > the rest I believe, is solved server-side? > If the CPE is hard rebooted, it hasn't sent a Release, so I'd expect > the lease-state to be kept server-side, and re-offered if the DUID+MAC > binding is the same when the CPE reconnects. > > Although, during soft reboots, I have often seen CPEs sending a > Release, telling the servers to relinquish the lease. Perhaps we > should discuss the benefits/detriments of doing this? This is a good point. On our HGWs we disabled ever sending release just to try to always give the same prefix to the customer. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 31 08: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 71EDF128D52 for ; Thu, 31 Jan 2019 08:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gdlm5lY17WAu for ; Thu, 31 Jan 2019 08:26:07 -0800 (PST) Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.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 18822127AC2 for ; Thu, 31 Jan 2019 08:26:06 -0800 (PST) Received: from tuli.elion.ee ([194.126.117.170] helo=[10.65.57.99]) by valgus.lanparty.ee with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gpFAA-0002KM-Qj for v6ops@ietf.org; Thu, 31 Jan 2019 18:26:03 +0200 To: v6ops@ietf.org References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> From: Tarko Tikan Message-ID: Date: Thu, 31 Jan 2019 18:26:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 194.126.117.170 X-SA-Exim-Mail-From: tarko@lanparty.ee X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 16:26:10 -0000 hey, > Isn't that handled by L-13 of RFC7084? > > L-13:  If the delegated prefix changes, i.e., the current prefix is >           replaced with a new prefix without any overlapping time >           period, then the IPv6 CE router MUST immediately advertise the >           old prefix with a Preferred Lifetime of zero and a Valid >           Lifetime of either a) zero or b) the lower of the current >           Valid Lifetime and two hours (which must be decremented in >           real time) in a Router Advertisement message as described in >           Section 5.5.3, (e) of [RFC4862]. Correct but this does not handle the CPE reboot scenario where old prefix information is not stored over reboot (but it does work great if prefix changes without reboot). In reality we have not found the reboot to be a big problem as for most residential/SOHO customers the same CPE provides wired LAN ports and wifi. Both will be disconnected during reboot and this information is visible to OS and OSes will stop using the prefix on those interfaces due to that anyway. -- tarko From nobody Thu Jan 31 08:37: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 D2DAC12D84C for ; Thu, 31 Jan 2019 08:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7iF5lpei42l for ; Thu, 31 Jan 2019 08:37:51 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C7212D4F0 for ; Thu, 31 Jan 2019 08:37:50 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1gpFLa-0000FyC; Thu, 31 Jan 2019 17:37:50 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> In-reply-to: Your message of "Thu, 31 Jan 2019 18:26:02 +0200 ." Date: Thu, 31 Jan 2019 17:37:49 +0100 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 16:37:53 -0000 > In reality we have not found the reboot to be a big problem as for > most residential/SOHO customers the same CPE provides wired LAN > ports and wifi. Both will be disconnected during reboot and this > information is visible to OS and OSes will stop using the prefix > on those interfaces due to that anyway. There is always the possibility that someone uses a switch or a wifi repeater. In addition, VMs (on a laptop) can be connected using a software bridge on the host. Simple setups will be fine, but it may be worth solving this problem. From nobody Thu Jan 31 08:42: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 C8B6C130E0A for ; Thu, 31 Jan 2019 08:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKl9yhHDNsXm for ; Thu, 31 Jan 2019 08:42:38 -0800 (PST) Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.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 9106F130E6B for ; Thu, 31 Jan 2019 08:42:38 -0800 (PST) Received: from tuli.elion.ee ([194.126.117.170] helo=[10.65.57.99]) by valgus.lanparty.ee with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gpFQC-0002Mj-Bs; Thu, 31 Jan 2019 18:42:36 +0200 To: Philip Homburg , v6ops@ietf.org References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> From: Tarko Tikan Message-ID: <9da736fc-032f-1466-f90f-5d346e73a1aa@lanparty.ee> Date: Thu, 31 Jan 2019 18:42:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 194.126.117.170 X-SA-Exim-Mail-From: tarko@lanparty.ee X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 16:42:40 -0000 hey, > There is always the possibility that someone uses a switch or a wifi > repeater. > > In addition, VMs (on a laptop) can be connected using a software bridge on > the host. > > Simple setups will be fine, but it may be worth solving this problem. Sure, don't get me wrong, I'm not saying it's an non-issue that is not worth solving. Everyone would win if we could iron out another corner case. Like with everything, we have to balance different factors. Considering how many problems (many) we have had due to flash wear/issues in the CPEs, and also considering the lack of issues (none) due to additional switches/equipment, I'd say the solution is not storing the prefix information to flash. -- tarko From nobody Thu Jan 31 09:50: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 062DF1277D2 for ; Thu, 31 Jan 2019 09:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 7M_s0Sjwvk49 for ; Thu, 31 Jan 2019 09:49:55 -0800 (PST) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 B542F124BE5 for ; Thu, 31 Jan 2019 09:49:55 -0800 (PST) Received: by mail-yb1-xb31.google.com with SMTP id n6so1645180ybg.8 for ; Thu, 31 Jan 2019 09:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fh74kfq8y6S39OY3+mp0fcXtmQ9CL6tWLsUFy+fzFYA=; b=iNRaocaXneGKJkfe/D/dCPvMHxc8cUwJ8UQIaNc7I8JGcmnHuIn5PtSf+2Ke60sBTY HfrllW30BOp2v/iWk0kUTD/WRXYa2uNqy/4S4Ep/7gxsou51BhnBALUnf0AYaTnLnz/B DHPTfSIo9jHnc4p1SHx7q3WYoe8hZjDnz9noTAvlNve9L9tpn76+GwKi04TT/aHbjIug qjQddPgLx0O2qyHJ3Q7g/rljnuyikVtE3Y+66h5AlQtcndkIbwqqGeUL60eSRBnlZWZC 4UiIBqV1rHxfuoDG0jjVCqi7Sy3+blbAkxJnd75qHD+4fThB3rFsCz1PkQmmmuqfYpb7 Ei3w== 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=Fh74kfq8y6S39OY3+mp0fcXtmQ9CL6tWLsUFy+fzFYA=; b=kwdYAZKnKgrpPfYSAdLgXPHDpUU+RevYw0cIDe9XtXOhp3IM1Lsnw7vkcxti34NgXR 2PzO33hw9rYd1m00rHgt9g++6HG7nJXbDsmHp0EX45avOl6Nlbd5p3veIdnkW4XgC/xh 4O5sO/o4L6qQpQd1vbcULiPLKwQWVOEzu1ukxKdU4jS9kLGdmaDUyFKkEPbWrqyCv2Kz 4PTAFH6nEdSh1fiyPdnqwpjSkmjP6d3Ag9aIevpz7+DhhVcs9I33djzOKpRrGIkDcoRp xZHbJPzKXsf5jEJi2ylVo6wVgeIVlW8S2Hn0XR/xx5KLLGCSYR0MjW6x4HMrw6GK0u9r co0Q== X-Gm-Message-State: AJcUukeFmamHptZsBJntXDfGuGeVSJGUaxhrbZgA+jsMFi7xvPbs0c36 BLHfSV2/9Ms6ihuctJ8qpYdFEjqM6VQ= X-Google-Smtp-Source: ALg8bN7OJuzMSQB2hQX+sUkHztvIF84N8MjRSfsA41/CbDaxqsdjnWKYPaqABRnwxERWILPTMVJHnA== X-Received: by 2002:a25:ca86:: with SMTP id a128mr34761747ybg.244.1548956994624; Thu, 31 Jan 2019 09:49:54 -0800 (PST) Received: from mail-yw1-f48.google.com (mail-yw1-f48.google.com. [209.85.161.48]) by smtp.gmail.com with ESMTPSA id g84sm5806886ywg.9.2019.01.31.09.49.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jan 2019 09:49:53 -0800 (PST) Received: by mail-yw1-f48.google.com with SMTP id h193so1617432ywc.4; Thu, 31 Jan 2019 09:49:53 -0800 (PST) X-Received: by 2002:a81:350f:: with SMTP id c15mr34613209ywa.232.1548956993614; Thu, 31 Jan 2019 09:49:53 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <76ea7b13-888c-a978-9fd7-cc8387169215@si6networks.com> In-Reply-To: From: Richard Patterson Date: Thu, 31 Jan 2019 17:49:40 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Mikael Abrahamsson Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 17:49:58 -0000 On Thu, 31 Jan 2019 at 14:23, Mikael Abrahamsson wrote: > This is a good point. On our HGWs we disabled ever sending release just to > try to always give the same prefix to the customer. Likewise for soft reboots, but we still send a Release if the user specifically clicks the "Disconnect" button in the UI, just in case they do wish to change prefixes. From nobody Thu Jan 31 12:04: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 621BE130EBC; Thu, 31 Jan 2019 12:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDnjK68Og4Zt; Thu, 31 Jan 2019 12:04:25 -0800 (PST) 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 25743130EBA; Thu, 31 Jan 2019 12:04:25 -0800 (PST) Received: from [10.22.5.132] (unknown [200.61.187.100]) (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 E5B0084475; Thu, 31 Jan 2019 21:04:15 +0100 (CET) To: JORDI PALET MARTINEZ , Mikael Abrahamsson Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <360e3a32-e039-cd26-3634-bf3f4c744cdf@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: Date: Thu, 31 Jan 2019 16:15:19 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 20:04:29 -0000 On 31/1/19 10:24, JORDI PALET MARTINEZ wrote: > If the problem is no really about increasing the hardware cost, but proper engineering, as Sander suggested, to manage how to write info in the flash, and a CE, even if it has several power outages per day, can last for more than 5 years, I think is fine to go for MUST. I'm fine either way. That said, I still use some CPEs older than 5 years, and would find quite disappointing if I had to replace any of them because of *this*. > My concern is why many routers get corrupted when "saving" data in the flash if there is a power outage in the middle of the operation. I'm convinced it is again about proper engineering. In this case, I bet it is. Essentially you'd have to have an alternative means to bootstrap the device, if you screw the main one. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 12: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 14DF4130F01; Thu, 31 Jan 2019 12:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdSSNYc30W8H; Thu, 31 Jan 2019 12:05:00 -0800 (PST) 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 D7A9A130F2B; Thu, 31 Jan 2019 12:04:59 -0800 (PST) Received: from [10.22.5.132] (unknown [200.61.187.100]) (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 7AAC984592; Thu, 31 Jan 2019 21:04:56 +0100 (CET) To: Richard Patterson Cc: Tassos Chatzithomaoglou , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <76ea7b13-888c-a978-9fd7-cc8387169215@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: Date: Thu, 31 Jan 2019 16:18:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 20:05:06 -0000 On 31/1/19 10:51, Richard Patterson wrote: > On Thu, 31 Jan 2019 at 12:15, Fernando Gont wrote: >> >> On 31/1/19 08:40, Tassos Chatzithomaoglou wrote: >>> Isn't that handled by L-13 of RFC7084? >>> >>> L-13: If the delegated prefix changes, i.e., the current prefix is >>> replaced with a new prefix without any overlapping time >>> period, then the IPv6 CE router MUST immediately advertise the >>> old prefix with a Preferred Lifetime of zero and a Valid >>> Lifetime of either a) zero or b) the lower of the current >>> Valid Lifetime and two hours (which must be decremented in >>> real time) in a Router Advertisement message as described in >>> Section 5.5.3, (e) of [RFC4862]. >> >> Yes, we missed this REQ, and will update our doc accordingly. HOwever, >> this bullet was included for completeness sake. The case we care and are >> trying to address here is that in which the CPE reboots. > > I think this requirement already resolves the CPE-side of things, and > the rest I believe, is solved server-side? > If the CPE is hard rebooted, it hasn't sent a Release, so I'd expect > the lease-state to be kept server-side, and re-offered if the DUID+MAC > binding is the same when the CPE reconnects. Well, if you want to play safe, you cant expect anything. Also, in some cases it may be the actual *goal* to get a *different* prefix. i.e., the so-called "dynamic" prefixes, which seem to be the recommended default there. > Although, during soft reboots, I have often seen CPEs sending a > Release, telling the servers to relinquish the lease. Perhaps we > should discuss the benefits/detriments of doing this? I will add some text on the topic. However, if we elaborate more on the CPE behaviour we may want to end up splitting the document: one part that focuses on the host-behaviour and that is aimed at 6man, and the CPE part aimed at v6ops? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 12:05: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 BEBF5130F37; Thu, 31 Jan 2019 12:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yomEwJEFCFvb; Thu, 31 Jan 2019 12:05:39 -0800 (PST) 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 129BE130F61; Thu, 31 Jan 2019 12:05:38 -0800 (PST) Received: from [10.22.5.132] (unknown [200.61.187.100]) (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 C7CAE84256; Thu, 31 Jan 2019 21:05:32 +0100 (CET) To: Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@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: Date: Thu, 31 Jan 2019 17:02:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 20:05:47 -0000 On 31/1/19 10:43, Philip Homburg wrote: >> So while I am generally sympathetic to this draft and what it tries to >> achieve (especially the part where it ties the router announcing something >> to what it's later announcing, and lack of something means it's implicitly >> zero preferred time for that), we need to figure out a few more things >> first. RFC7084 was informational which made it fairly easy to get through, >> now you're proposing a standards track document so we need to make sure >> everything works. Changing all hosts is a big thing. > > I think changing host behavior is good in this case if we can make hosts more > robust. I prefer the network to do the right thing, but reality is that that > will not always happen, so it is good to have robust hosts. > > That said, I don't like playing games with the valid lifetime. Changes to > preferred lifetime are relatively benign, setting the valid lifetime of a > prefix to zero may have more serious consequences. FWIW, our first initial version only changed the "Preferred Lifetime", and never modified the "Valid Lifetime". Then we realized it was easy to update the "Valid Lifetime" with the same "mechanism" and incorporated that. THe most important bit is, indeed, updating the "Preferred Lifetime". Question: How about making the update to the "Valid Lifetime" a SHOULD or MAY, instead? Or, maybe, at least, set it to the current "Valid Lifetime"? Otherwise, with the default values for the "Valid Lifetime", the addresses might lie around for 1 month.... > I think the algorithm can be simplified to: > - When a RA is received that contains a PIO with the A bit set, then set the > preferred lifetime to zero for all addresses derived from prefixes that were > announced by the same router and that are not covered by the current RA. > > In extreme cases this may cause the preferred lifetime to ping-pong. But that > just causes source address selection to become more random, which should be > fine. The mechanism in the document tries to accommodate the case where the information conveyed in an RA is split among two RA messages -- so it's the second RA with the PIO that causes the update, rather than the first one. In all current practical cases, all info is normally conveyed into a single RA. However, the mechanism that's currently in the I-D allows for cases where it can be split in two. Based on whether we want to allow such case or not, we may or may not simplify the mechanism as you suggest. What do other folks think? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 12:17: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 99F36130ED4 for ; Thu, 31 Jan 2019 12:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMGWFQd7ZK2W for ; Thu, 31 Jan 2019 12:17:49 -0800 (PST) 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 BB401130EBE for ; Thu, 31 Jan 2019 12:17:48 -0800 (PST) Received: from [10.22.5.132] (unknown [200.61.187.100]) (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 1602D8469A; Thu, 31 Jan 2019 21:17:45 +0100 (CET) To: Tarko Tikan , Philip Homburg , v6ops@ietf.org References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <9da736fc-032f-1466-f90f-5d346e73a1aa@lanparty.ee> 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: Date: Thu, 31 Jan 2019 17:09:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <9da736fc-032f-1466-f90f-5d346e73a1aa@lanparty.ee> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 20:17:51 -0000 On 31/1/19 13:42, Tarko Tikan wrote: > hey, > >> There is always the possibility that someone uses a switch or a wifi >> repeater. >> >> In addition, VMs (on a laptop) can be connected using a software >> bridge on >> the host. >> >> Simple setups will be fine, but it may be worth solving this problem. > > Sure, don't get me wrong, I'm not saying it's an non-issue that is not > worth solving. Everyone would win if we could iron out another corner case. > > Like with everything, we have to balance different factors. Considering > how many problems (many) we have had due to flash wear/issues in the > CPEs, and also considering the lack of issues (none) due to additional > switches/equipment, I'd say the solution is not storing the prefix > information to flash. FWIW, my personal view regarding the CPEs is that it'd be nicer if they behaved nicely -- however, there might be issues with storing the prefixes on flash (even if just because the vendors of some cheap CPE's don't do the "some required engineering" that was mentioned here), and, more importantly, because the network is more robust if the hosts implement more robust behaviour. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 13:03: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 7D786130F23 for ; Thu, 31 Jan 2019 13:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 D6xMPAHbRiZV for ; Thu, 31 Jan 2019 13:03:01 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::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 3BA9B130F1C for ; Thu, 31 Jan 2019 13:03:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 156924A; Thu, 31 Jan 2019 22:02:58 +0100 (CET) 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=1548968574; bh=Orr7AIXyrNAsMkCxqLF MeTSZnNyD/IABGZmC1afaj5E=; b=ivXiX97O/O+H01ugDba9pa/AfHcUDqRTwdw iEEW0AF3RZkpvlGugK/mT3pAyt0lvQWqYtRR8yqNmMNDs614fh29Nj1iqVAI/XQK 7ZuRkpaAbAUZwef5/UIoLg1uBh9QLBYkGbY7TWNj7W3mI15P8YsNGa9jBJWgV+72 9Erntd/4= 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 kjC3t_9sPFDJ; Thu, 31 Jan 2019 22:02:54 +0100 (CET) Received: from [IPv6:2a02:a213:a300:ce80::10] (unknown [IPv6:2a02:a213:a300:ce80::10]) (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 7A72449; Thu, 31 Jan 2019 22:02:53 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1DB60745-70EB-40D0-9E13-DA3B9F08EE7F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 31 Jan 2019 22:02:52 +0100 In-Reply-To: Cc: Tarko Tikan , Philip Homburg , v6ops@ietf.org To: Fernando Gont References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <9da736fc-032f-1466-f90f-5d346e73a1aa@lanparty.ee> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 21:03:04 -0000 --Apple-Mail=_1DB60745-70EB-40D0-9E13-DA3B9F08EE7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > FWIW, my personal view regarding the CPEs is that it'd be nicer if = they > behaved nicely -- however, there might be issues with storing the > prefixes on flash (even if just because the vendors of some cheap = CPE's > don't do the "some required engineering" that was mentioned here), = and, > more importantly, because the network is more robust if the hosts > implement more robust behaviour. We should stop making excuses for badly behaved CPEs, they are crappy = enough already and I'd really like to work towards tiger standards. That = said: more robust hosts are also a good thing :) Cheers! Sander --Apple-Mail=_1DB60745-70EB-40D0-9E13-DA3B9F08EE7F 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----- iQEzBAEBCAAdFiEE9VC3eloaasvH0nE1oC0DsP4kE7kFAlxTYnwACgkQoC0DsP4k E7kC6gf/dTwIg20nkIdC+osKP5sgY/nFLWyhs/DBtK3alYB8AzFDTwVC5bL0ZQKY 5Xap3d7K23AT7gBvucUc7Wlof9HEC/CUWcUNU35v7dwJ1/ahTDLHShnUXibDQadp I6FReDkaEURTj001hFCoZb66eZtfJSgPWl/LYopLqTQqCzkOUqSxyhEsV/6KlGK2 9T4WS7+BSzOWwJXMX2P6qdkA7NCcfDWeJDDUZ9ksYzItOLI1FLgADwH8lQPVolNz VFXQmmkkVr9VxB3rqFUypbSt4YtqpCri4DhPmIx5FD5zj+wj1NPzaMFIw3fTmCjk 3Hc4VsrF1OKWvvMbft6J8ET7FCUDig== =oHlp -----END PGP SIGNATURE----- --Apple-Mail=_1DB60745-70EB-40D0-9E13-DA3B9F08EE7F-- From nobody Thu Jan 31 13:04:07 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 F32B6130F25 for ; Thu, 31 Jan 2019 13:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Ii-Z0QS_12jq for ; Thu, 31 Jan 2019 13:04:03 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::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 69451130F1C for ; Thu, 31 Jan 2019 13:04:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 33EC04B; Thu, 31 Jan 2019 22:04:02 +0100 (CET) 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=1548968639; bh=tmTdnD79dGajoIipjSk VmQlZSXWd7bRD8KVOAmDiRJY=; b=Qls65e2VZZD5xZPE8R+hpoGuEE06VBOH1nG QmhyU53Wfaj1IMVhNSDirqSZ/aE+Y29owHuD/3ioe4AoPYzOr+osOdmfoe14y3/A +cd9xeveY2nFVOBNqF9AjgyXZ5eii2cuLRwJVwBVJr1FzZD0Xo/JFojHL6dWgmk1 cuYgyPbU= 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 KpXanXQqRm5W; Thu, 31 Jan 2019 22:03:59 +0100 (CET) Received: from [IPv6:2a02:a213:a300:ce80::10] (unknown [IPv6:2a02:a213:a300:ce80::10]) (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 3D7734A; Thu, 31 Jan 2019 22:03:59 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_03EB80B8-64DE-410E-B6A9-90C9D6523866"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 31 Jan 2019 22:03:58 +0100 In-Reply-To: Cc: Tarko Tikan , Philip Homburg , v6ops@ietf.org To: Fernando Gont References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <9da736fc-032f-1466-f90f-5d346e73a1aa@lanparty.ee> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 21:04:05 -0000 --Apple-Mail=_03EB80B8-64DE-410E-B6A9-90C9D6523866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > We should stop making excuses for badly behaved CPEs, they are crappy = enough already and I'd really like to work towards tiger standards. That = said: more robust hosts are also a good thing :) Although tigers are nice, in this case I would still prefer "higher" :) --Apple-Mail=_03EB80B8-64DE-410E-B6A9-90C9D6523866 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----- iQEzBAEBCAAdFiEE9VC3eloaasvH0nE1oC0DsP4kE7kFAlxTYr4ACgkQoC0DsP4k E7klqwf/evyvKBmzE3FG09m3XrX1BJngjumYmSVpK1H5L4iRaiQunwKg3s5IB86t X0v55D5VAy2xhIfmlah8hU5ptsWTMb2f1wLILcpLexCSppWCIBr3flJBIaS+XOzy CVft830YVSgOByNpcNJR3zsjf3IR3fJ2WRkozI7P3K0ub2cBU4+ffoS4cXM9LuFq 0gje+i+uW/skE3u/0eVt/CNrCtg+WWGCi44RusKDkVHOXM1eqdPZ6SjMyCs4rkm6 y/Kioou5sZeoekebeEUSiz974GwoAVF5tqrwK9/jJUJ6JexapX3UPa/Rn0NIlZJ8 PWU/yJ7FBK2qIcQgVI6EwVB5IT+C6g== =4Q8p -----END PGP SIGNATURE----- --Apple-Mail=_03EB80B8-64DE-410E-B6A9-90C9D6523866-- From nobody Thu Jan 31 13:09:59 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 B3173130F2C for ; Thu, 31 Jan 2019 13:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI6cvo4j-MAk for ; Thu, 31 Jan 2019 13:09:52 -0800 (PST) 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 8315D130F27 for ; Thu, 31 Jan 2019 13:09:52 -0800 (PST) Received: from [10.20.5.3] (unknown [190.111.250.98]) (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 2130F82E6B; Thu, 31 Jan 2019 22:09:48 +0100 (CET) To: Sander Steffann Cc: Tarko Tikan , Philip Homburg , v6ops@ietf.org References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <9da736fc-032f-1466-f90f-5d346e73a1aa@lanparty.ee> 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: <1e5097d5-e2ff-5ad3-b761-69d70125544b@si6networks.com> Date: Thu, 31 Jan 2019 18:09:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 21:09:58 -0000 On 31/1/19 18:02, Sander Steffann wrote: > Hi, > >> FWIW, my personal view regarding the CPEs is that it'd be nicer if they >> behaved nicely -- however, there might be issues with storing the >> prefixes on flash (even if just because the vendors of some cheap CPE's >> don't do the "some required engineering" that was mentioned here), and, >> more importantly, because the network is more robust if the hosts >> implement more robust behaviour. > > We should stop making excuses for badly behaved CPEs, they are crappy enough already and I'd really like to work towards tiger standards. That's kind of my take: some tend to be so crappy that I'm not expecting the "engineering" to happen there. But... we can nevertheless give the proper advice in that area... then... it's up to them. > That said: more robust hosts are also a good thing :) Indeed! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 31 13:26: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 8CC11130F6A; Thu, 31 Jan 2019 13:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_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 uz_g_mj8YqBL; Thu, 31 Jan 2019 13:26:38 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71349130F2C; Thu, 31 Jan 2019 13:26:38 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id u18so4022200oie.10; Thu, 31 Jan 2019 13:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZO9bXTZh4hCy2fr4xlre8MvQjFGVRmIrDi4LR1BN3To=; b=sUdq8E18vwqpQKetl1wBcPUPd8bAiM/pfJdxtZFJHIgd/X49Vn01yJZLsmCUQ9UKpM wZ29eoUnP63rYKEZJv9OLv3oYfuPzIwwYKMzvDeNbZhfmXqWEIHrTfXFqGJMp9XYw7fS Ww7ZwkZlM58lIh8iKvg6s18CWvPlVsRlyllLteVMpT4e034+lt8InzMSrN52Qf1J7Krc JaRZ4UT7Vdggplx16SK04HgsIs93fRmZVnUcFBZiMWWd03rtT25j7EjJnnN906uAClzH Cb9e1xlifH1BEIVhwcYSyOxmfrfV5nNagM0yFWxSGExoaHcG0EC9wKUt1RK690GNAOea 8egg== 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=ZO9bXTZh4hCy2fr4xlre8MvQjFGVRmIrDi4LR1BN3To=; b=aQRO3JGvqF+19cpfQkHHnlFAlFXjZ0GZbda5TJHQ4PDGbsO+KpjU4G3Mqzo6MJY4MI uPAAdy+iow4ELyclbgROEVHYcTuDAHwuYP32JHa+2Tfg7pH5P7VyjFX2k/IZLNcqLR3V JG6K3JgoA2w5/wuJb8GSnL1ihXpd9KyhsAFutVN9YmwO5CQYvct+yhbbCbK1buow6LBG AdB4Lrb+XZysONCj9eQ8aeMavNLBupPBA62rOwA+XqP4mcaRlQEfP24+bH9h2ccGNeKK WFsghiAgjf3/MyJZ6lKaRi4M+bixCHocuGReibP7cL1SSZLvmvgihww5ZNZHQNlsWXJP tfwA== X-Gm-Message-State: AJcUukcVdJOnspzIMFSQG6/fg1yRZsKU3ZTD1tAzIszXoykgYqbO+PQQ qtKjvbTCgNiEwh5i4x//95NXogbK6Z8qWMCthR3hMiJB X-Google-Smtp-Source: ALg8bN48MyvYK6pqtOlntg98Rsgqdr6cP1ixift7H5bBp2iM0Kr8awA40gcHyU44xjgK8vnbl9inILw4sRLpLkvoyV4= X-Received: by 2002:aca:5a88:: with SMTP id o130mr17107417oib.275.1548969997342; Thu, 31 Jan 2019 13:26:37 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> In-Reply-To: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> From: Mark Smith Date: Fri, 1 Feb 2019 08:26:10 +1100 Message-ID: To: Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 31 Jan 2019 21:26:43 -0000 Hi, So I thought about this problem back when I was doing some work with IPv6 CPE vendors and working on a production IPv6 residential deployment in 2010. As the CPE vendors were commonly using 'radvd', I thought it would be easier for me to write some code for that to handle this situation and push it directly to the 'radvd' people rather than try to go through the vendors and have them up stream it. Here's the descriptions of the two options that were added for a prefix (from radvd.conf(5)) DeprecatePrefix on|off Upon shutdown, this option will cause radvd to deprecate = the prefix by announcing it in the radvd shutdown RA with a z= ero preferred lifetime and a valid lifetime slightly greater tha= n 2 hours. This will encourage end-nodes using this prefix to dep= re=E2=80=90 cate any associated addresses immediately. Note that this opt= ion should only be used when only one router is announcing the p= re=E2=80=90 fix onto the link, otherwise end-nodes will deprecate associa= ted addresses despite the prefix still being valid for prefer= red use. See RFC4862, section 5.5.3., "Router Advertisement Processin= g", part (e). Default: off DecrementLifetimes on|off This option causes radvd to decrement the values of the p= re=E2=80=90 ferred and valid lifetimes for the prefix over time. The li= fe=E2=80=90 times are decremented by the number of seconds since the l= ast RA. If radvd receives a SIGUSR1 signal, it will reset the val= ues of the preferred and valid lifetimes back to the initial val= ues used by radvd when it started. If radvd never receives a SIGU= SR1 signal, it will continue to decrement the lifetimes until = the preferred lifetime reaches zero. After a final RA with a z= ero value preferred lifetime, radvd will cease to announce the p= re=E2=80=90 fix. If a SIGUSR1 signal then causes the lifetimes to be res= et, the prefix will then re-appear in the RAs. This option is intended to be used in conjunction with a DHC= Pv6 client that is using the Identity Association for Prefix Dele= ga=E2=80=90 tion (IA_PD) option to acquire a prefix from a Delegating Rou= ter for use by a Requesting Router. In this scenario, the prefix(= es) from within the delegated prefix that are announced by ra= dvd would age in parallel with and at the same rate as the delega= ted prefix, and expire at approximately the same time, if the de= le=E2=80=90 gated prefix's life isn't extended. See RFC3633, "IPv6 Prefix Options for Dynamic Host Configurat= ion Protocol (DHCP) version 6". Default: off As mentioned in the first option description, to deprecate an address/prefix, a RA PIO valid lifetime of zero is invalid, and must be greater than 7200 seconds / 2 hours. This is to prevent a DoS by a rogue RA announcing a 0 valid lifetime. RFC4862, section 5.5.3., "Router Advertisement Processing", part (e) discusses this. I chose the value 7203 seconds. The second option is to ensure synchronised ageing of addresses on hosts in parallel with the age of the DHCPv6-PD prefix. In case of a CPE reboot, if the CPE gets a different new prefix via DHCPv6-PD, the new prefix's lifetimes will probably be greater than those of the old DHCPv6-PD prefix, and if I recall correctly, I was seeing hosts choose to use the highest preferred lifetime addresses. So the addresses from the newer PD prefix should be used by hosts, and the addresses from the old and now invalid one should eventually age out and disappear. I've recently thought there was something in the source address selection RFC about choosing highest value lifetimes in source address selection, however I can't seem to find it, so I may be misremembering. This second option isn't perfect though, as it won't work if the newer PD prefix has lower initial lifetimes than the current lifetimes of the old prefix at the time CPE reboots. That could happen if an ISP has decided to roll out lower PD prefix lifetimes. More broadly, a router reboot is or should be a transient packet loss event. Hosts are expected to tolerate transient packet loss, which is why TCP didn't originally have any keepalives at all, and the keepalives it commonly has now has a large initial timeout value of 2 hours. Devices (well, routers) in the Internet aren't intended to have knowledge of transport layer connections, so that if they reboot they don't have to reacquire or relearn transport layer connection state before being able to forward hosts' packets. IPv4/IPv6 forwarding is purposely stateless. So if a CPE reboots and reattaches to the network/Internet at the same point, it should be given back the same DHCPv6-PD prefix i.e. the stable prefix scenario. If the CPE reattaches to the network at a different point (for some definition of different attachment point e.g. different access link, different PPPoE username), then giving it a different PD prefix is reasonable and probably should be expected. I sympathise with the privacy issue of the stable prefix. I think it would be better to have the end-user initiate a PD prefix change via a web portal or similar, rather than rebooting their CPE, because it isn't possible for an ISP to distinguish whether a CPE reboot was caused by a bug or the end-user was actively doing it for the purposes of changing the PD prefix, so it isn't possible to absolutely know if the same or a different PD prefix should be given back to the CPE. If an ISP wants to or needs to initiate the prefix changes, they could have a mechanism to cycle customers through old and new DHCPv6-PD prefixes, phasing them in and out over time using IPv6 address ageing. I don't think that would be a very simple mechanism to build, however there is the cost of providing prefix privacy over time. (One issue might be that some customers have connections they want to have up for long periods of time e.g. a CCTV video feed, longer than the ISP chosen default prefix lifetime for privacy. Those customers should probably given a option somewhere to opt out of the changing prefixes, or to be able to set their own privacy prefix change interval.) Note that the ISP I worked for in 2010 provided (an still provides) stable PD prefixes (and dynamic SLAAC ones on the PPPoE/PPP session), so the ability to cope with changing PD prefixes upon CPE reboot wasn't a capability we required. I mainly spent my own time on the problem and the 'radvd' code. I think that's all of what I thought about this at the time, I'll see if I can remember anything else. Regards, Mark. On Thu, 31 Jan 2019 at 22:01, Fernando Gont wrote: > > Folks, > > We have posted a new I-D discussing a problem that can arise in typical > deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and > advertises a prefix on the LAN side. > > Our draft is available at: > https://tools.ietf.org/html/draft-gont-6man-slaac-renum > > > The Abstract is: > A very common IPv6 deployment scenario is that in which a CPE employs > DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one > prefix from within the leased prefix is advertised on a local network > via SLAAC. In scenarios where e.g. the CPE crashes and reboots, > nodes on the local network continue using outdated prefixes which > result in connectivity problems. This document analyzes this problem > scenario, and proposes workarounds. > > Any comments will be welcome. > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------