From nobody Fri Mar 1 07:39: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 57385124C04 for ; Fri, 1 Mar 2019 07:39: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA4BgCvLJQIj for ; Fri, 1 Mar 2019 07:38:59 -0800 (PST) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EE5130E7F for ; Fri, 1 Mar 2019 07:38:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0EE0932023BF; Fri, 1 Mar 2019 12:38:57 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id oUzGiGSbz7ql; Fri, 1 Mar 2019 12:38:55 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 8ED1A3202383; Fri, 1 Mar 2019 12:38:55 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 8ED1A3202383 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1551454735; bh=uexnPvj6bq7Hc6iApC4r/W09vyG888PuuSnGCJGrlUc=; h=Date:From:To:Message-ID:MIME-Version; b=gI28Eh4G75o8zyP/39Y4457FqL42iX9BYozxe3E+Mr+AJ7UAd8uZu1rR3BXmGM1x4 eMSRtGqUjtN6P/QrLezb7S79zI/4RBdh4lBSNVOx5tcY0PwH5dR+27YTf5vAxORpqK gnJvJMUo56VDIT+5SiXDVxi4QHFtnTLb5wasorvTqmpxinkWIsLPIQWLoG6IX9pMLS bWDNzqwnSF4Zdo/W8ddcccvlWqWLkIgU4ePS4Ao9PQrhUbc2TsKWDLIzdtvioz7AO3 L0QxP1aaXHMW1vl2e3QK+jU4h4kJDzbwVpnU4deseILb3mXEqkckZWJTp2saU3cd8r AkwftE3T+1cwg== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2sUD2hXR5yDm; Fri, 1 Mar 2019 12:38:55 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 08EDE32023BF; Fri, 1 Mar 2019 12:38:55 -0300 (-03) Date: Fri, 1 Mar 2019 12:38:54 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Message-ID: <519998863.33225976.1551454734779.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <86B7975E-87B1-44BE-8220-661A73A016B8@consulintel.es> References: <86B7975E-87B1-44BE-8220-661A73A016B8@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC72 (Win)/8.8.8_GA_1703) Thread-Topic: inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment Thread-Index: Gjs3TkVXPy10QAkU38ousR7DayGTcA== Archived-At: Subject: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2019 15:39:03 -0000 Hello Jordi, Yes, I understand it should works routing IPv6 CLAT traffic directly to CDN= s but I don't know if there is some kind of rule in CLAT where all traffic = should be routed to the NAT64 prefix. Regards, Alejandro ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "Alejandro Degidio" CC: "v6ops@ietf.org list" Enviados: Mi=C3=A9rcoles, 27 de Febrero 2019 3:18:47 Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks draft-ietf-v6ops-nat64-deployment Hi Alejandro, Thanks, I understand your point better now. I was thinking only that you me= an IPv4-only CDN resources. However, I believe that by using routing (I didn't actually try it myself, = but I think it is simple to do), because the CLAT brings this IPv4-only as = IPv6 traffic into your access/distribution network, so you can make sure to= route more specifics prefixes directly to the CDN as IPv6, without going t= hru the NAT64 and then the CLAT will translate it back to IPv4 for the Smar= tTV. So I don't think we need any additional "protocol" or change to 464XLAT to = do that. Regards, Jordi From nobody Fri Mar 1 13:10:29 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 17D1B130ED9; Fri, 1 Mar 2019 13:09:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: v6ops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147459608.6101.5623565143618132416.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:09:56 -0800 Archived-At: Subject: [v6ops] v6ops - Requested session has been scheduled 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: Fri, 01 Mar 2019 21:09:57 -0000 Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00 requested) Thursday, 28 March 2019, Afternoon Session I 1350-1550 Room Name: Athens/Barcelona size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/v6ops.ics Request Information: --------------------------------------------------------- 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 Wed Mar 6 01: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 8138E130ED1 for ; Wed, 6 Mar 2019 01:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JnAbK7eVoj8 for ; Wed, 6 Mar 2019 01:21:52 -0800 (PST) Received: from consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA6F130DF1 for ; Wed, 6 Mar 2019 01:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1551864108; x=1552468908; i=jordi.palet@theipv6company.com; 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=t1JPptGL 2hXSKGQUsct4A5+58MhRb3EpGURCx/LOCHA=; b=CJigKEBoEEKb9uNb86UhftFP 31maAyk4dpfpiYr8T2Y0A/NsAlDkuPvZciJx5zOOubPh2CCdLQ3oUfKM/jXTSubc be+Vci2bO3kBkDwgzd2bzzE5GGYTw74jmL5A0s4RD4PpCk9ACpU4QjiwstcglPOg 7YHIH/gN/iUP1xEZ8wo= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Wed, 06 Mar 2019 10:21:48 +0100 X-Spam-Processed: consulintel.es, Wed, 06 Mar 2019 10:21:48 +0100 Received: from [10.10.10.139] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006176283.msg for ; Wed, 06 Mar 2019 10:21:47 +0100 X-MDRemoteIP: 2001:470:1f09:495:f904:cd5b:df7f:a0f0 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 06 Mar 2019 10:21:47 +0100 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=196836ca1f=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Wed, 06 Mar 2019 10:21:46 +0100 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: "v6ops@ietf.org list" Message-ID: Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt References: <155186342461.24565.992983876092646343.idtracker@ietfa.amsl.com> In-Reply-To: <155186342461.24565.992983876092646343.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 09:21:54 -0000 Hi all, I've submitted this document after the questions from Alejandro for CDN opt= imization with IPv4aaS. https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/ I think, in addition to operators, it will be interesting to have the views= of CDN/cache operators, not sure if we have people related to this in the = list, such as Akamai, Netflix, AWS, Facebook, Google, etc. We know that today some of them already do this optimization to avoid the C= GN when using the 100.64.0.0/10 prefix. Regards, Jordi =EF=BB=BF-----Mensaje original----- De: Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 10:10 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-cach= es-00.txt =20 A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-464xlat-opt-cdn-caches Revision: 00 Title: 464XLAT Optimization for CDNs/Caches Document date: 2019-03-06 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= 464xlat-opt-cdn-caches-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-464x= lat-opt-cdn-caches/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-464xlat-o= pt-cdn-caches-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -464xlat-opt-cdn-caches =20 =20 Abstract: This document describes the drawbacks of IP/ICMP Translation Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or applications initiate traffic flows to dual-stack CDNs (Content Delivery Networks) or Caches, which are forced to be translated back to IPv4 by a NAT64. The document proposes possible solutions to avoid that. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Mar 6 01:54: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 63A3A130ED4 for ; Wed, 6 Mar 2019 01:54:04 -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 8FYSpmbYT6G5 for ; Wed, 6 Mar 2019 01:54: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 D209C130DF1 for ; Wed, 6 Mar 2019 01:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1551866038; x=1552470838; 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=g4vvi2L8RLJ5PH9OzTvUj PzzG4+DxJAlLRlcjc8w4Z4=; b=X1lfNyGWymawaW71QuCyrBerui+RtBlQmcTO9 QMcAN1OBS9IOHIGKnjLwtYaUdkHO4o/wjGwwomjLIUIdq6HizhLBPGqCSt6E6bAY eh/rIEwegOzJ5GORguaYfy++i5YIjBBdQtvgdq4mBWitt4S1+PvQEFZREGEb16i6 0k0X7c= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Mar 2019 10:53:58 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 06 Mar 2019 10:53:58 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006176314.msg for ; Wed, 06 Mar 2019 10:53:58 +0100 X-MDRemoteIP: 2001:470:1f09:495:f904:cd5b:df7f:a0f0 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 06 Mar 2019 10:53:58 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1968b193b8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Wed, 06 Mar 2019 10:53:56 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 09:54:04 -0000 One important consideration that I missed in the submitted version. In the case of the "operator provided EAMT" (section 5), there is no need t= o have a "match" with the AAAA records. So, we can have for example: www.example.com A 192.0.2.1 AAAA 2001:db8::192.0.2.2 EAMT pushed entry 192.0.2.1 2001:db8::192.0.2.33 CLAT translated to 2001:db8::192.0.2.33 CDN IPv6 interface already is 2001:db8::192.0.2.33 Operator already has a specific route to 2001:db8::192.0.2.33 The problem of this alternative is now to "renew" the EAMT info, with will = depend on the mechanism to tell the CE (or the CE to ask if we go for a pul= l instead of a push) ... One more issue, how much time the EAMT information is kept in the case of t= he "automated" EAMT (section 4). May be with every A record request this en= try should be cleared and otherwise use the default TTL from the A record?.= This seems to avoid having a mechanism to configure the table at the CE. I think the information that the CDN operators can provide will be key to d= etermine which approach is better, or may be to figure out new approaches. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Jordi Palet Mart=C3=ADnez <= jordi.palet=3D40theipv6company.com@dmarc.ietf.org> Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 10:22 Para: "v6ops@ietf.org list" Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-= opt-cdn-caches-00.txt Hi all, =20 I've submitted this document after the questions from Alejandro for CDN= optimization with IPv4aaS. =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-cach= es/ =20 I think, in addition to operators, it will be interesting to have the v= iews of CDN/cache operators, not sure if we have people related to this in = the list, such as Akamai, Netflix, AWS, Facebook, Google, etc. =20 We know that today some of them already do this optimization to avoid t= he CGN when using the 100.64.0.0/10 prefix. =20 Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 10:10 Para: Jordi Palet , Jordi Palet Martine= z Asunto: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-= caches-00.txt =20 =20 A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-00.t= xt has been successfully submitted by Jordi Palet Martinez and posted = to the IETF repository. =20 Name: draft-palet-v6ops-464xlat-opt-cdn-caches Revision: 00 Title: 464XLAT Optimization for CDNs/Caches Document date: 2019-03-06 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-palet-v6= ops-464xlat-opt-cdn-caches-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-= 464xlat-opt-cdn-caches/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-464xl= at-opt-cdn-caches-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v= 6ops-464xlat-opt-cdn-caches =20 =20 Abstract: This document describes the drawbacks of IP/ICMP Translation Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or applications initiate traffic flows to dual-stack CDNs (Content Delivery Networks) or Caches, which are forced to be translated = back to IPv4 by a NAT64. The document proposes possible solutions to avoid that. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of s= ubmission until the htmlized version and diff are available at tools.ietf.org= . =20 The IETF Secretariat =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 Mar 6 11:57: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 1C3FB12D84C for ; Wed, 6 Mar 2019 11:57:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMz9VyD4tdNj for ; Wed, 6 Mar 2019 11:57:29 -0800 (PST) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB0112EB11 for ; Wed, 6 Mar 2019 11:57:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 63B793201D49; Wed, 6 Mar 2019 16:57:25 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CwkLiHIqdKC6; Wed, 6 Mar 2019 16:57:21 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 4EAD73201D5C; Wed, 6 Mar 2019 16:57:21 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 4EAD73201D5C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1551902241; bh=yE7DcrDRkGVK1g5kQ4P0M2+dWtt6W8Lguv5l4woEgq4=; h=Date:From:To:Message-ID:MIME-Version; b=YY6LHh8fpU/bTaejZsWS3Wn4x0dUTUslSVVaftsUg7g7Z/kXR4KQZ/gUflEQKGkyX +EiuUYJtnkADcR69T34Ug+dr8UypXYKzNAlDXForDlmeKIxVJusNLkXoVlZo+KOnYy 8OnCYTV+9L7aY8ZWn66LMteTW4cp7dme9g/SLjLxuICOJjGLjoWIx5lCgaa4NCNGrH Fev6eCMGObClaQhxNkX00AYrDrdG8luAIot5tRUmatwe4782t9HwYB7uf5pBoD7++b 9Hf6K66CUjkb187hPLiHXempxxl6dyqhr0/4opz//b12bnayCCMyZauNclMF91vwsT xhR30OHVAyeoQ== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F047wuImy5G1; Wed, 6 Mar 2019 16:57:21 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0EE2E3201D49; Wed, 6 Mar 2019 16:57:21 -0300 (-03) Date: Wed, 6 Mar 2019 16:57:20 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Message-ID: <1242302095.68359179.1551902240024.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC72 (Win)/8.8.8_GA_1703) Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt Thread-Index: /YKaUt3ZBJlYPvmRxhwhOAKYEn4tFw== Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 19:57:34 -0000 Hello Jordi, Thanks for helping with this scenario of CDNs, please let's work together o= n it. As a summary you consider these scenarios always in a IPv6-only access netw= ork (which is the case): 1- IPv6 capable device/app: it can directly connects to IPv6 service (CDN, = etc). 2- IPv4 only device/app: they need to use a PLAT to access to the service. I think we can include, as a part of introduction, the actual case of why I= SPs need to continue providing IPv4 to have a direct connection to CDNs avo= iding CGN, something like: .--+--.=09 / \ / IPv4 \ ( Internet ) /\ / / \ /\ / `-----' \ +-------+ .-----. / \ .-----. | IPv6 | / \/ \/ Dual- \ .-----. | CE | / \ .-----. / Stack \ / IPv4- \ | or +--( DS )---( CGN )---( ) / only \ | UE | \ Access /\ `-----' \ CDNs/ / ( SmartTV )--+ | \ / \ \ Caches/ \ STB / | with | `-----' \ .-----. / `--+--' \ VoIP / | | \ / \ / `-----' | CLAT | / IPv6 \/=20 | + | ( Internet ) | IPv4- | \ / | CGN | \ / =20 +-------+ `-----' =20 Showing that private IPv4 (typically 100.64.0.0/10) can connect directly to= CDNs with public IPv4. After the text: "As show in the precedent picture, this is also the case for other services, not just CDNs or caches, such as VoIP access to the relevant operator infrastructure, which may be also dual-stack, but is not commonly the case for many VoIP devices or applications." Can be included a note saying that this is the scenario where ISPs and CDNs= need to have a direct connection without CGN avoiding the sizing and trans= lation impact of CGN. About the approachings: DNS/Routing-based Solution Approach: I think that is a good idea. The thing= here is to know how possible is this to be considered by CNDs. Also, this = scenario is just possible if CPE is in router mode. CLAT/DNS-proxy-EAMT-based Solution Approach: I think this is a better appro= ach where is not necessary to modify anything in CDNs. I see two things: a. How long is the timeout of the EAMT entry? b. How to determine which FQDNs CLAT needs to verify if there is an AAAA re= cord? If it tries with all A records it can have a service impact (more del= ay thinking about a lot of queries per second). CLAT-provider-EAMT-based Solution Approach: Really hard to implement and to= maintain. It depends on features of provisioning systems. With CM we can t= hink on: Push this information to millions of devices using SNMP and pray to all CMs= are online what is not true because there are always CMs offline. Include this information into a config-file and restart all CMs!? For both cases how to update some change to all CMs? I think the best approach is CLAT/DNS-proxy but I'm worried about A record = queries delay where destination is an external service. Regards, ALEJANDRO D'EGIDIO=20 Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3=ADa=20 M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 11 39= 77-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.ar | adegid= io@telecentro.net.ar ]=20 Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "v6ops@ietf.org list" Enviados: Mi=C3=A9rcoles, 6 de Marzo 2019 6:53:56 Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-= opt-cdn-caches-00.txt One important consideration that I missed in the submitted version. In the case of the "operator provided EAMT" (section 5), there is no need t= o have a "match" with the AAAA records. So, we can have for example: www.example.com A 192.0.2.1 AAAA 2001:db8::192.0.2.2 EAMT pushed entry 192.0.2.1 2001:db8::192.0.2.33 CLAT translated to 2001:db8::192.0.2.33 CDN IPv6 interface already is 2001:db8::192.0.2.33 Operator already has a specific route to 2001:db8::192.0.2.33 The problem of this alternative is now to "renew" the EAMT info, with will = depend on the mechanism to tell the CE (or the CE to ask if we go for a pul= l instead of a push) ... One more issue, how much time the EAMT information is kept in the case of t= he "automated" EAMT (section 4). May be with every A record request this en= try should be cleared and otherwise use the default TTL from the A record?.= This seems to avoid having a mechanism to configure the table at the CE. I think the information that the CDN operators can provide will be key to d= etermine which approach is better, or may be to figure out new approaches. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Jordi Palet Mart=C3=ADnez <= jordi.palet=3D40theipv6company.com@dmarc.ietf.org> Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 10:22 Para: "v6ops@ietf.org list" Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-= opt-cdn-caches-00.txt Hi all, =20 I've submitted this document after the questions from Alejandro for CDN= optimization with IPv4aaS. =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-cach= es/ =20 I think, in addition to operators, it will be interesting to have the v= iews of CDN/cache operators, not sure if we have people related to this in = the list, such as Akamai, Netflix, AWS, Facebook, Google, etc. =20 We know that today some of them already do this optimization to avoid t= he CGN when using the 100.64.0.0/10 prefix. =20 Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 10:10 Para: Jordi Palet , Jordi Palet Martine= z Asunto: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-= caches-00.txt =20 =20 A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-00.t= xt has been successfully submitted by Jordi Palet Martinez and posted = to the IETF repository. =20 Name:=09=09draft-palet-v6ops-464xlat-opt-cdn-caches Revision:=0900 Title:=09=09464XLAT Optimization for CDNs/Caches Document date:=092019-03-06 Group:=09=09Individual Submission Pages:=09=099 URL: https://www.ietf.org/internet-drafts/draft-palet-v6= ops-464xlat-opt-cdn-caches-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-= 464xlat-opt-cdn-caches/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-464xl= at-opt-cdn-caches-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v= 6ops-464xlat-opt-cdn-caches =20 =20 Abstract: This document describes the drawbacks of IP/ICMP Translation Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or applications initiate traffic flows to dual-stack CDNs (Content Delivery Networks) or Caches, which are forced to be translated = back to IPv4 by a NAT64. The document proposes possible solutions to avoid that. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of s= ubmission until the htmlized version and diff are available at tools.ietf.org= . =20 The IETF Secretariat =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 From nobody Wed Mar 6 12:49: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 D357A12EB11 for ; Wed, 6 Mar 2019 12:49:38 -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 Vj3-Z141xLzO for ; Wed, 6 Mar 2019 12:49:33 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF43013110A for ; Wed, 6 Mar 2019 12:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1551905363; x=1552510163; 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=77pFZnBIle5BUs4AZOwKb 4OLjJTcnUOFW94dgbt8xUE=; b=o6GhIpNpEcnelGLEeIfuSTssKrtA8Ui/Hs9KE 3340nK4pijNWTSdPPVm728ba8RM3eVH4MqY4fLwa4Ugua4QM0wXzcPbw8Hkxh/6j Nwqal80M1dqTMFmmgehw7evrfW+MReLrMaEB3zB16s+F0+oc1kDoXYI5YMDFZFdw qKjxUM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Mar 2019 21:49:23 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 06 Mar 2019 21:49:22 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006177003.msg for ; Wed, 06 Mar 2019 21:49:22 +0100 X-MDRemoteIP: 2001:470:1f09:495:4cc2:97f9:7aa1:e3f5 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Wed, 06 Mar 2019 21:49:22 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1968b193b8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Wed, 06 Mar 2019 21:49:18 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: <81BF332B-9694-4E3C-8B80-82C79E6B897A@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 20:49:39 -0000 Hi Alejandro, Responding below, in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alejandro D'Egidio Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 20:58 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-= opt-cdn-caches-00.txt Hello Jordi, Thanks for helping with this scenario of CDNs, please let's work togeth= er on it. As a summary you consider these scenarios always in a IPv6-only access = network (which is the case): 1- IPv6 capable device/app: it can directly connects to IPv6 service (C= DN, etc). 2- IPv4 only device/app: they need to use a PLAT to access to the servi= ce. =20 I think we can include, as a part of introduction, the actual case of w= hy ISPs need to continue providing IPv4 to have a direct connection to CDNs= avoiding CGN, something like: .--+--.=09 / \ / IPv4 \ ( Internet ) /\ / / \ /\ / `-----' \ +-------+ .-----. / \ .-----. | IPv6 | / \/ \/ Dual- \ .-----. | CE | / \ .-----. / Stack \ / IPv4- \ | or +--( DS )---( CGN )---( ) / only \ | UE | \ Access /\ `-----' \ CDNs/ / ( SmartTV )--+ | \ / \ \ Caches/ \ STB / | with | `-----' \ .-----. / `--+--' \ VoIP / | | \ / \ / `-----' | CLAT | / IPv6 \/=20 | + | ( Internet ) | IPv4- | \ / | CGN | \ / =20 +-------+ `-----' =20 =20 Showing that private IPv4 (typically 100.64.0.0/10) can connect directl= y to CDNs with public IPv4. -> I can't see the picture very well, but I guess you mean to include the e= xample of what the CDNs do for avoiding the 100.64.0.0/10 traffic via the C= GN. I'm wondering if this is the same for CDNs and caches ... We should hav= e a clear picture if all them are doing it the same way and describe it. Pr= obably it may be better to have it in a different section, something like "= Comparative situation in IPv4 CGN traffic". =20 After the text: "As show in the precedent picture, this is also the case for other services, not just CDNs or caches, such as VoIP access to the relevant operator infrastructure, which may be also dual-stack, but is not commonly the case for many VoIP devices or applications." =20 Can be included a note saying that this is the scenario where ISPs and = CDNs need to have a direct connection without CGN avoiding the sizing and t= ranslation impact of CGN. =20 About the approachings: DNS/Routing-based Solution Approach: I think that is a good idea. The t= hing here is to know how possible is this to be considered by CNDs. Also, t= his scenario is just possible if CPE is in router mode. -> I heard from CDNs that this approach is not so easy. The way they handle= the DNS make it difficult. For caches may be. =20 CLAT/DNS-proxy-EAMT-based Solution Approach: I think this is a better a= pproach where is not necessary to modify anything in CDNs. I see two things: a. How long is the timeout of the EAMT entry? -> Time out should probably be consistent with the TTL of A records (I've s= ent another email about this, because I didn't include it in v00) b. How to determine which FQDNs CLAT needs to verify if there is an AAA= A record? If it tries with all A records it can have a service impact (more= delay thinking about a lot of queries per second). -> I think is easy. A dual-stack will query for the A and AAAA records. If = the DNS-proxy is only queried for the A record, it must also query for the = AAAA and build the EAMT entry. I don't this is heavy at all for the CPE DNS= proxy.=20 CLAT-provider-EAMT-based Solution Approach: Really hard to implement an= d to maintain. It depends on features of provisioning systems. With CM we c= an think on: Push this information to millions of devices using SNMP and pray to all= CMs are online what is not true because there are always CMs offline. Include this information into a config-file and restart all CMs!? =20 For both cases how to update some change to all CMs? =20 =20 I think the best approach is CLAT/DNS-proxy but I'm worried about A rec= ord queries delay where destination is an external service. =20 -> Yes, agree, I think approach number 2 (CLAT responsible for building the= EAMT) may be the best choice. Regarding the delay, think on it this way. I= f it was a host with dual-stack, the query will be done anyway for both the= A and AAAA records, not a big impact. =20 Regards, ALEJANDRO D'EGIDIO=20 Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3=ADa= =20 M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 1= 1 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.ar | ad= egidio@telecentro.net.ar ]=20 Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) =20 ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "v6ops@ietf.org list" Enviados: Mi=C3=A9rcoles, 6 de Marzo 2019 6:53:56 Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464x= lat-opt-cdn-caches-00.txt =20 One important consideration that I missed in the submitted version. =20 In the case of the "operator provided EAMT" (section 5), there is no ne= ed to have a "match" with the AAAA records. So, we can have for example: www.example.com A 192.0.2.1 AAAA 2001:db8::192.0.2.2 EAMT pushed entry 192.0.2.1 2001:db8::192.0.2.33 CLAT translated to 2001:db8::192.0.2.33 CDN IPv6 interface already is 2001:db8::192.0.2.33 Operator already has a specific route to 2001:db8::192.0.2.33 =20 The problem of this alternative is now to "renew" the EAMT info, with w= ill depend on the mechanism to tell the CE (or the CE to ask if we go for a= pull instead of a push) ... =20 One more issue, how much time the EAMT information is kept in the case = of the "automated" EAMT (section 4). May be with every A record request thi= s entry should be cleared and otherwise use the default TTL from the A reco= rd?. This seems to avoid having a mechanism to configure the table at the C= E. =20 I think the information that the CDN operators can provide will be key = to determine which approach is better, or may be to figure out new approach= es. =20 Regards, Jordi =20 =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Jordi Palet Mart=C3=ADn= ez Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 10:22 Para: "v6ops@ietf.org list" Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464x= lat-opt-cdn-caches-00.txt =20 Hi all, =20 I've submitted this document after the questions from Alejandro for= CDN optimization with IPv4aaS. =20 https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-= caches/ =20 I think, in addition to operators, it will be interesting to have t= he views of CDN/cache operators, not sure if we have people related to this= in the list, such as Akamai, Netflix, AWS, Facebook, Google, etc. =20 We know that today some of them already do this optimization to avo= id the CGN when using the 100.64.0.0/10 prefix. =20 Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 10:10 Para: Jordi Palet , Jordi Palet Mar= tinez Asunto: New Version Notification for draft-palet-v6ops-464xlat-opt-= cdn-caches-00.txt =20 =20 A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-= 00.txt has been successfully submitted by Jordi Palet Martinez and pos= ted to the IETF repository. =20 Name: draft-palet-v6ops-464xlat-opt-cdn-caches Revision: 00 Title: 464XLAT Optimization for CDNs/Caches Document date: 2019-03-06 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-pale= t-v6ops-464xlat-opt-cdn-caches-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6= ops-464xlat-opt-cdn-caches/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-4= 64xlat-opt-cdn-caches-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-pal= et-v6ops-464xlat-opt-cdn-caches =20 =20 Abstract: This document describes the drawbacks of IP/ICMP Translation Algorithm (SIIT), when used as a NAT46, and IPv4-only device= s or applications initiate traffic flows to dual-stack CDNs (Cont= ent Delivery Networks) or Caches, which are forced to be transla= ted back to IPv4 by a NAT64. The document proposes possible solution= s to avoid that. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time = of submission until the htmlized version and diff are available at tools.ietf= .org. =20 The IETF Secretariat =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven if partially, including attached files, is strictly prohibited and will= be considered a criminal offense. If you are not the intended recipient be= aware that any disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited, will be considered a criminal offense, so you must reply to th= e original sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ 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 _______________________________________________ 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 Mar 7 04:25: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 9B80E130EEE for ; Thu, 7 Mar 2019 04:25:12 -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, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFXmpnRKPqbd for ; Thu, 7 Mar 2019 04:25:10 -0800 (PST) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0703130EE3 for ; Thu, 7 Mar 2019 04:25:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 257F73201DCB; Thu, 7 Mar 2019 09:25:05 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ETKWU8JE6u7A; Thu, 7 Mar 2019 09:25:04 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 2D1CB3201E11; Thu, 7 Mar 2019 09:25:04 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 2D1CB3201E11 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1551961504; bh=k1wbLF/Ek/tf3E+ePuupl3zNc8gg5k6ae+Y/d0fmDEM=; h=Date:From:To:Message-ID:MIME-Version; b=AbpBdJj3iIDUlW7KIiLizJTLEFn4EFt7WKA8IbMRYdhaVeoWdP5yEiJFZ3hevANkO w5wguKAzJKwP9JWunVzlixYQagYvC/BMEGKnFSJzxcM/NXomoNDjt5alpbBnL5lQRd mxvjpXqYrsTsBID1YQtU9lQR9jf/8CgGANSVpGSuaK2p/YuXGMJ1ceOkr0Mi/CEqLq B4HBMKEJ2t9YdwhZP4yhK++dbuPGAbE5JrBSC2I8/4Azfatc+feSwmXdAJjJLIzPQR HVuN+HoygvdlmCWH/bhhuy94PP6j8eVy1NG6/RPg1cjKdSWo8+i7AcwGXLFCmC4lZh 7y1jUX89JVYNg== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VjPeUN0DV9ah; Thu, 7 Mar 2019 09:25:03 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id D3D403201E0E; Thu, 7 Mar 2019 09:25:03 -0300 (-03) Date: Thu, 7 Mar 2019 09:25:03 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Message-ID: <977540941.73233109.1551961503169.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <81BF332B-9694-4E3C-8B80-82C79E6B897A@consulintel.es> References: <81BF332B-9694-4E3C-8B80-82C79E6B897A@consulintel.es> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_73233105_963645385.1551961503166" X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC72 (Win)/8.8.8_GA_1703) Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt Thread-Index: av4aLVl8X++VVKl6OVI6Q05lL1qOcw== Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 12:25:13 -0000 ------=_Part_73233105_963645385.1551961503166 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Jordi, My answers in line also. Regards, Alejandro ----- Mensaje original ----- > De: "JORDI PALET MARTINEZ" > Para: "v6ops@ietf.org list" > Enviados: Mi=C3=A9rcoles, 6 de Marzo 2019 17:49:18 > Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xla= t-opt-cdn-caches-00.txt > Hi Alejandro, >=20 > Responding below, in-line. >=20 > Regards, > Jordi >=20 >=20 >=20 >=EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Alejandro D'Egidio > > Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 20:58 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org list" > Asunto: Re: [v6ops] New Version Notification for > draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt >=20 > Hello Jordi, > Thanks for helping with this scenario of CDNs, please let's work toget= her on it. > As a summary you consider these scenarios always in a IPv6-only access= network > (which is the case): > 1- IPv6 capable device/app: it can directly connects to IPv6 service (= CDN, etc). > 2- IPv4 only device/app: they need to use a PLAT to access to the serv= ice. > =20 > I think we can include, as a part of introduction, the actual case of = why ISPs > need to continue providing IPv4 to have a direct connection to CDNs av= oiding > CGN, something like: > .--+--. > / \ > / IPv4 \ > ( Internet ) > /\ / > / \ /\ > / `-----' \ > +-------+ .-----. / \ .-----. > | IPv6 | / \/ \/ Dual- \ > .-----. | CE | / \ .-----. / Stack \ > / IPv4- \ | or +--( DS )---( CGN )---( ) > / only \ | UE | \ Access /\ `-----' \ CDNs/ / > ( SmartTV )--+ | \ / \ \ Caches/ > \ STB / | with | `-----' \ .-----. / `--+--' > \ VoIP / | | \ / \ / > `-----' | CLAT | / IPv6 \/ > | + | ( Internet ) > | IPv4- | \ / > | CGN | \ / > +-------+ `-----' > =20 > Showing that private IPv4 (typically 100.64.0.0/10) can connect direct= ly to CDNs > with public IPv4. >=20 > -> I can't see the picture very well, but I guess you mean to include the > example of what the CDNs do for avoiding the 100.64.0.0/10 traffic via th= e CGN. > I'm wondering if this is the same for CDNs and caches ... We should have = a > clear picture if all them are doing it the same way and describe it. Prob= ably > it may be better to have it in a different section, something like "Compa= rative > situation in IPv4 CGN traffic". Strange you can't see the picture. I attach it. The idea is to show the act= ual case of why ISPs with CGN and CDNs need to have a direct connection wit= h IPv4 without using a CGN. If there is no new definition (this draft) ISPs and CDNs will continue usin= g IPv4 in access network. I think is better to include a simple part in introduction because regardin= g that we are thinking about this new draft. Then, we can have a section with additional information of how it's impleme= nted although it's not necessary because it's not the point of the document= , that's why the idea of just introduction. >=20 > =20 > After the text: > "As show in the precedent picture, this is also the case for other > services, not just CDNs or caches, such as VoIP access to the > relevant operator infrastructure, which may be also dual-stack, but > is not commonly the case for many VoIP devices or applications." > =20 > Can be included a note saying that this is the scenario where ISPs and= CDNs need > to have a direct connection without CGN avoiding the sizing and transl= ation > impact of CGN. > =20 > About the approachings: > DNS/Routing-based Solution Approach: I think that is a good idea. The = thing here > is to know how possible is this to be considered by CNDs. Also, this s= cenario > is just possible if CPE is in router mode. >=20 > -> I heard from CDNs that this approach is not so easy. The way they hand= le the > DNS make it difficult. For caches may be. Yes, I agree. > =20 > CLAT/DNS-proxy-EAMT-based Solution Approach: I think this is a better = approach > where is not necessary to modify anything in CDNs. > I see two things: > a. How long is the timeout of the EAMT entry? > -> Time out should probably be consistent with the TTL of A records (I've= sent > another email about this, because I didn't include it in v00) Yes, I suppose. >=20 > b. How to determine which FQDNs CLAT needs to verify if there is an AA= AA record? > If it tries with all A records it can have a service impact (more dela= y > thinking about a lot of queries per second). > -> I think is easy. A dual-stack will query for the A and AAAA records. I= f the > DNS-proxy is only queried for the A record, it must also query for the AA= AA and > build the EAMT entry. I don't this is heavy at all for the CPE DNS proxy. Yes, maybe it wont have a big impact but by default it will try to find the= AAAA record for all A records queries from hosts. An additional case related to this is when a customer has an additional rou= ter behind the provided CPE. If this additional router doesn't support thes= e new features, I think EAMT entries can solve it. >=20 > CLAT-provider-EAMT-based Solution Approach: Really hard to implement a= nd to > maintain. It depends on features of provisioning systems. With CM we c= an think > on: > Push this information to millions of devices using SNMP and pray to al= l CMs are > online what is not true because there are always CMs offline. > Include this information into a config-file and restart all CMs!? > =20 > For both cases how to update some change to all CMs? > =20 > =20 > I think the best approach is CLAT/DNS-proxy but I'm worried about A re= cord > queries delay where destination is an external service. > =20 >=20 > -> Yes, agree, I think approach number 2 (CLAT responsible for building t= he > EAMT) may be the best choice. Regarding the delay, think on it this way. = If it > was a host with dual-stack, the query will be done anyway for both the A = and > AAAA records, not a big impact. I agree but the idea is to think about devices and apps that only support I= Pv4. >=20 > =20 > Regards, > ALEJANDRO D'EGIDIO > Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3=AD= a > M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 = 11 > 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.ar | > adegidio@telecentro.net.ar ] > Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) ------=_Part_73233105_963645385.1551961503166 Content-Type: image/png; name="IPv4-CGN to IPv4-Pub.PNG" Content-Disposition: attachment; filename="IPv4-CGN to IPv4-Pub.PNG" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAiQAAAFZCAYAAACopzTyAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAACe1SURBVHhe7d0NkqSqtobhO6ce1+6pdPRMao/k RA3jRJw51BXQFBAVlMUCfZ8II6rKLNNUfj4xk/y/HwAAAGUEEgAAoI5AAgAA1BFIAACAOgIJAABQ RyABAADqCCQAgNB//vz8+vXn53v+FWiBQAIACBFIoIBAAgAIEUiggEACAE9iw8Svdfnn6+d/8yrj +6+3blp+/7us/f754/09WP4u0eR/P1//hOv+/GdeZfz36+e3t45QgxIEEgBAiBESKCCQAMBolpGI aPSjGslAsozgfEZdAIdAAgCjIZDggQgkAABAHYEEAACoI5AAAAB1BBIAAKCOQAIAANQRSAAAgDoC CQAAUEcgAYCemXk7pOYb6YmdW4XZYd+MQAIA3XLfHRN8X8yDme/ZectrxRaBBAB6ZUYN3jA6snjL aBCSCCQA0CkzYrB+G+8bvGtECCECCQD06KXvqfjfv7/5npuXIpAAQIfe2zF///z59fvn67/zr3gN AgkAdOfdnfL7blXBIJAAQG/e/uZOPgL8SgQSAOgKb+zkGLwTgQQAesLogMNHgF+HQAIAHeH9EwtG Sd6GQAIAANQRSAAAgDoCCQAAUEcgAQAA6ggkAABAHYEEAACoI5AAgCbmHcnDvCSPRyABAEV15x0x 34Hz6+dXtCxzedgv7AvWXf2+HDdHyPX/v8I8J1+692QEEgBQYwKExOiICybxpGI2kPijDGbU4UKo cN9E/Kf5FwC+9xuQ34FAAgBK5DrYzEAyj3S4ERr/50Xib/YWkwkiGt9IrPGcaIVAAgAqJDvXK4Ek tT7eR//xOuGAqfWfi0ACABpE36SZF0js78EtoyhkmH30R3CCfdYJJLwJ+LkIJADQnBtpiANDPQeB ZPr7umw7dn8Ewvy8biMOIEqBRPzYQQuBBABaE7/KPwgkZ6Myn1EQsw1vH+0bYP0w4y2t32gqOroE LQQSAGhM/n0QNwLJEkSmTv94H7VGSAzN54YUAgkANCXZmbogEo9gLMEkL5Ast3bO9lE3FNh95CPA j0IgAYCG6EhrYZTkaQgkAABAHYEEAACoI5AAAAB1BBIAAKCOQAIAANQRSAAAgDoCCQAI4mO+rZiP AfMdNyMjkACAFDvdes1O0n2PSzzxWdGsrz1/Od3Nfcud+A19IpAAgAg3a6rMl8C5YHJp+vkHBxJD flp+SCGQAIAA2Vs1e4Fkvm1hO/Z5BOUzYuACUjy6spkiPvgSvcQ6sz1/+5/XaPbJPN5/njhchPuw 7n/mvuXoOXDhEIEEAKqT/or8o0BiOvKlQ3a/B/tx1GHbdV4IiG85fcLK/Lfg8W6f1hAR72P8e+G+ ZZM+9pBCIAGA6kxne+HqPttRIAmfd3ML46DTN6M64Tajzt0GEn/7/vptEAhGiczzRu/v2IwiVQkk ideMIRBIAKC2YORAgkwgMY/d3jaJAsnum0ZPAslndCVaBAKJ7O0ySCGQAEB1Y46QnI4s3A0ku/87 Y4Tk1QgkAFDdtnOu60YgsY/Z2bfNLZnInUAyP+9xUDjYt2zSxx5SCCQAIMB2xmcjAsVcZxvf9lg7 +ZxAMglun0QBJFhnFm/E4lYgMVzg8Le/CQ5H+5aj0igL2iOQAICIGlf7KMXtmnERSABAir3a52q9 FZlRKbRCIAEAQdvbFpBhRqQIfyMjkAAAAHUEEgAAoI5AAgAA1BFIAACAOgIJAIiK5udgnow6DudE wYgIJAAgKdFxmrkymJ/kDmZjfSICCQAISoYPru7vMaNMHL/HIZAAgJTd2zNc4d/BbKzPRCABACFH HScTpl3Ee3Aei0ACACK2X3QXOluPFILccxFIAEBATsfJrYdShLgnI5AAQHWZ7xHh9kMZ3gz8aAQS AKgtu+Pkza35OFZPRyABgMqKbsVw1Z+H0aTHI5AAQE3FHSdX/jl4v83zEUgAAIA6AgkAAFBHIAEA AOoIJAAAQB2BBAAAqCOQAAAAdQQSALip6kdSmZfEiT8+zXF5PAIJANxRfcIuMy8J39eyDXkcl6cj kADADeZL9GpP2MU32pov0duGPI7LsxFIAOAyqW+fffe32u4HD77t98kIJABwkeQV+3unSj8OHUwh /1wEEgC4RPg7aN76ZXJnb17lS/Yei0ACAFeIf+rjjV+6l/Oa33hc3oFAAgAXNLl18LaPuuaOfvAR 4EcikABAqWa3Dd71Js78kMebW5+IQAIAhVp+/PQ9H3UtCxl8BPh5CCQAUKT11fk7RgPKAwajJE9D IAEAAOoIJAAAQB2BBAAAqCOQAAAAdQQSAACgjkACAADUEUgA4ERPX+hm9uXXr5GnTjcf161/PPnS vfERSADgSI9f5mb3adRQIhNI7DFhOvmhEUgA4ICZsIsr75pcIKkfpvjSvdERSABgF7OBDoUv3Rsa gQQAdvB9KaMhQI6MQAIASdwCGBEhclwEEgBIGXX43+z3L/dJHLtEr2H5lM6yxO+POV7vQpq/Pghs 85tt1/UKbwbu8U3IyEIgAYAEPkY6Ls7dmAgkABDjKntsvLl1SAQSAIjwPoTR8f6fERFIACDAJzUe gVGS4RBIAACAOgIJAABQRyABAADqCCQAAEAdgQQAAKgjkAAAAHUEEgDgI6KPx+yt/SOQAHg5JtF6 BTP7LqGzawQSAO9GR/USBM/eEUhQzE6r/cYG3H6LKt9v8jQM5b8It+a6RiBBMQIJHoMv0XsZvhag ZwQSFCOQ4Cn4Er334Zz3i0CCPPZK8tfUIW+Xz3D35jFR5207dG99FGrM0Lm/Ph5GP17v7g/764N7 xZf3zVxReX/3lyc0aj2fM3FcLb+SxqjYq+tZPgIJijFCgkcw5/ON5Ri2A487degjkKAYgWQ0yxXS gKMBy5Vl9fLGJy5eTSSMUs/uIpCgGIFkNDSUGxrD9uiIRCClnt1FIAHwOgzZg1t2/SGQAAAAdQQS AACgjkACAADUEUgAAIA6AgkAAFBHIEE58+70N069bD4ax7vyAUAEgQTlCCT9es38GoXzSDDvCA6N XJ78r7eoPQeKxHwt+wgkKHcpkKS/E2Yp6HaytWDdtYoVfKdD7dA0QCB51fwaBeWQeUdwSqo8me0G bZtUWRT6bqaGF6AEEpS7VUBdMIkT92b2V1uJSyrXPEuiZMXpPpCYY/umUYDcBvhtxwXXCJUn25Z5 j7ejKxKhJHf/S0ltd4tAgnItAskcMFyl9X9eRH9rkeI7DyT2GDa6kulFzmt+43HBNSLlKQ4kRvC3 bYe/GYGxj19HWNK3UOSCQ6s6RCBBueaBJLU+rHyuAn/ZbR9X2hu6DiRyjVHX7NXm0dXqS48LrpEo T6lAYp9n2c52m2Egmdb77W1qe5ZgWT89LnUQSFCuQSCxvwcVIKpswT7Mt2v8x9tKW7ly9hxIzOvt NizJOryf/+LjgmuqlyfbFsWdud+ebYPE4T4kHu/s/b2O432qg0CCcqaCSQQSb3QjdQXgVwjz87oN F0jCbab+dlO3gUTgtY5kt5N4+XHBNbXLUyqQFI2QuN/D9rEkkLj99v//Up3YPS71EEhQTiqQnBX2 T4Uw2wgr+Da9vyiQNBpO7dfOuX79ccE1lctTIpCEI8DHgeR0tPhj7++1CLSpEQIJymkFEvu/U8Wc nn8zdBhX+kQjcFungWQbxt7Hlp+oTHJccFXV8pRsm/w2MGwTXQCJAonX7pj9KBshqSd1XGoikKCc qVDFhdJVOn/Y0K+UcaXb4yprutItFdktlcOI0WUgkW+ExhAfB44L7qhYnuYAsi6J7fiPmdrWMPyY 517/371539vGZvtmkSr7svWKQIJylwLJA3QYSKSvWEbiHwuOC+6iPKVJHgsCCcoRSAAAlRFIUI5A AgCojEACAADUEUgAAIA6AgkAAFBHIEE53kMCAKiMQIJyBBJF8rMlPoI5VxJz0eAlnlPP7Md0pdqt yvWMQIJyYoHENQKfyX3857AF31tnl8YdTg+BxBx7RmmymMmlCG64pHo9Cyc3M0tYNuUCkGggmdSs ZwQSlBMJJHOF9bc7Pc+noPdwxdtBIKGTLUB4w0V165kLG8fTzo8bSGrWMwIJygkEktNKQyDp4xgM 5TnD7miodj2z29ufbt2EH3/kZFmCAGPaXG/dtkxHo8ve/sdt6/J8tQNXje0RSFCueiDJuIIgkNiG 5PgqCzHbGFcfzcOT1a9nS1g4+g6Yo079++dPNHIc3q6et79Tzv1AYsOIQBtWq54RSFBOLZC4ZP9Z WocD1UAi+6VWz8VxQwm58mI77bnt2rZ1R4EkFu3jJqCElkDyJRRGnDrH7bmBJBriik9EPEwWFpAl 0a5LUFA2nWNUGE6ee3hqgeS9IyRc6V/3uJGlm+3Pcdt3s20cXJN6tpy/4HmOA0l8TvzRliVw7JXw 4yBUT416xggJylUPJHOFO+rsXx1ISq6esNFD2cEA2tWzbYjYf24XKPzymxghOQskZv0chMReX4V6 NnYgWa4EBrxyXBLvkJ2MQCBZrhqChD09z+f49NCpmH3QCCQnDQ7OjBjo3D4fv++gU3NdHq7MNqtn 87mN2lDbJyTa1Ti8uL7DLxcmoOyPTgT/b/tMqTJ1v54RSJQQSBKWhmxZ/OeI19mlcUBRCiSmrEgO tb7CcKGOQNKaWD1b+il/SbafLlgsj1n3Jf77V+L9GuFj/LYxDjRuxEXwtd4479yyQTmpQNI7jUBi G3flkaFHGHGUBM1Qzyq5V88IJChHIAEAVEYgQTkCCQCgMgIJAABQRyABAADqCCQAAEAdgQTl3voe EgCAmGECyWvmYrj5Oe4mCCRyRjj/D2HaFP2PAb/s48i9vDGcetZMST0bI5AUf0Y8niTGLctBWSaG WZeLkw/Z/Zr+v2rBNg1U55MhEUhk2PLU8Nyb8xjUg0ToX8r4Zxlwoq49rY93gmmsJepS2MbFbWfU PnrPb/cnOCb1A5PUa87WwXl/lYLjPUQgMZXr2uiIq3hxZYpnrnMNc2kBnSvq3/pJ2+5fzx0+gUSA K09NRwFtufc6qzl8rPuQrj+PYo6B1pVyfPwrcaHC3+50Hpf6ujnHk2k/lnNs/vf3dEG0rpcYwZHY Zi6FeobsejZAIDGN4tU0mxlIgkKa+p/t3z7bEGnQ7rzmBsxrlggkc2OZunJz60wj686FXd+6IxHq QCyRcnQi9Xr8v0m+3m5odY5Cz3tyNXo2OmEDiZ2afDnvQvupUd4Nred9vbxy1H0guTdacCWQJCrt pzOc+ZVeqIC7hqHTamNec/VAEp8r9/vnGHzCytLYps+tKMEOWuV8p15P0KEt4e/ZoURlRDJuUyrZ tm2+8zqzlEOzHfc4qcBm9qX9RVfX7erD5dSzzgPJ3cqQroBxpbW/bwLH+rtZ7xfioFBLJW6hBqsK gUASnxPLP7ZzIPHPZfPGRSyQSDX6J5KvZ9tRmOO8jFo138cWpOrwEaHnTNajj7A9TJ3XT50y9c1u R6psapR5pXoGJ6PM9x1Iblfag0AyV0S3xI2yX3DNz14DHe9Tah/N3/ztX3oNHVce8/okAkm8Tf/Y qgU0V4aC87ksn/1158pfF5y3OUyt61MhQOFc23Ia7Yvd150r17lcP+4KM1W2zs7Z2fqTNuA4OFxX EkicsJ3xQ/73X1MO5Nqh1AWFH5LMEq4ftJ7BSdWzSNeBJFVgyxwEkpPG4NNBmoPoPTauMP5SvaD7 HXJPzH41GCEJ/pZRmMWlOvAqlMJn4vXYY37wGm35r3zu1WnUM6nntOd071bI3KEH528/kNht/f0S KpsaZV6pnsHJKPP9BpIqHdD1QLIEke/psYcFWLQxM/u/17gosg1V5U7Jnm//XEXn7tGBJOoIWolf j/39qMF256T5fgr7XHy0JFae59ARtEnTeVte3+YcHwQSu+731A4elYmrdNo2lXoGK6eedRtI7jUS ruH0Ry/8SpgVSCb2avCs0TAVXCyQ3D0OQsxrltinOZQs5ytoOB4eSES3vWfunNYl7CBs2QvWP7Ex 17pqds8rczznUPI5b1G5iuqZWdKBZC0D1Y+PcLu5S6OeYZJXzzoNJDrpuU8dHgtTqXsLScOT7KCw S6tjNF7bOWqFQIN6piKznvX9plb0iUAiw165EsSb6eB421HYl9Ul9ddMPWur4HgTSFCOQCJH84r9 ZUzHqHOV7tMcLVBgOqceyjf1rJmSekYgAQAA6ggkAABAHYEEAACoI5Cg3FvfQ9LL/W8AeKB+AklP bzKy7wpePqPf2cfyejhOBJKGXvamRym2Tnt1uec3NZp9M23PsHXMldmx9v9F9Uyy7Mf1rFAngaTT wnDz4Mowx0r5I2sCgSQ1WV3wtyAkLkvjc6MSSCbSAXA5tr120BXEE351UY8OjdipLwbdd+l6tgRN u6xlLzUBod8X2o9JBx+bvdNf3vnfc9t6VqaPQKLV0J/pMpDMBVizsqsFEuVzoVZOZSfHM8f597/f nXfQd5jjty076vXosVynN97kY3L1zJa1OFT8dW3Jpu2bg8sSGmwnb6bw/xzPG6FCtA1L17MSXQSS u6kqyXZgXur0G565Q3WFxK1PPn+qE7SFJeNvopRnbyWQNGePhUjnuTZu5jlS9cCvJ2YJG0L3/+v6 VN1Y1m3L7K1tZ9o/dsr1CN2RqWemnO0HCPucB22f6x+/vM4+EUiCerbfn4r0tbMax04/kIh0NHEB cL9/TsRy8paDtxcokvu2LVzmJMt0FvskC9YpAkl7Uq/f3645r6lzsPu8c2DYKwt2216HH9ezk9dU o4Fz9XU/dKjWI/RHop7t9S+zVNvn/89SRs3jXL8TB5LjMv4h1YZYmftwQj2Q1Gl0QrsnePnbpuHd OZg7JzDc5zonopho4Tphjp9KIFmvAOwSn2NpZh9aP6dHovM8Lsvm9/0ru5yGNtzfqCGdz+ne9u2+ 3S3jm7oe0axH6FL1epZRTzZl1CuXn/35tD+pQHK+z2Fdr+ysnmVSDiQynXnywPsHbHPwdvZjr7Hy /262JXWSDyWG7VoReM2pShn8rYeO49MgKKlU6VfbMhQ0xvaY79fPZEPqMdsKAuS8BGXWvKZlXWJb /jbKO4mcOqJYj66y52U9LpvOzj+mZomOa3xe4uN6vN4dL3/9UMcuR+16Zs/HftuVrEfe//h18vuv qY+JMhuUidRzyfS1Tr06pBtIap/42WnntnnewkDinQBTWNQqpNDxO2Wet3YIS7wWe86W59k9Fw2Z fdA43h+VO89NxzYvn9d40oidlD+/Ic1hO8Ld7Zl9KQwluWVGqx6hUzL1bG97qf7KrwtBPbJt79fh /tntxeVesoxXbJsVA0nlk+7bFADXmH1+35yc0kAysdv4rdxBnXQYUmylqBwN7LH2X0t0zioW+svM Pqie77mxqXXsU41UdB5uhQSz/YLymWqYV669KA04eY9XqkfoVtV6NrH1KGi/pvK88ykbFyjCOriW Y1MPTL9z0Hfaehc9l1RfO8mvZ+f0Aol0B2O3bwqBW4IDtmmIwwbJFYj1f90S7+tJY9xI7YqTRSKQ GLYircc8OLbR+XRL44DSQSCJy+od6YZk2/G7xnRdwobN1YPdcxKdU3/9tp75/+v2I1hfVObKjpNK PULH6tWzRViPjvqbsA7F9XR5fHCBHfx/tN+ifW3d46QWSGqmKh31C+w1CvshFUh610UgofPMUX6M eqnP6MVT6plkX1v7GCm/qXVcNu2+tVMgkAAAKiOQFPoMu725YyKQAAAqI5AAAAB1BBIAAKCOQAIA ANQRSIBcvIcEAMQ0CiSyE7PAZz6+KPWZ85frMZCYfeJ8T+q2MeNPS4Cqeq5n5kMGzdol2b68SSAR +YisLSDzJ15Sk8EI22uwlklrNospMHYCm0ShrlzY7T5wJV9fj4FkYsri68N+7Ua503MNPbfrmW3/ lz6hYn/VMpAIP5d8INnrhG8xowC6jfD5FVRqH9P7LTEBz/n+oVivnVTLBqlT9UMZo7qI3Khn7kLV DyFT+Zqnjr+tYf2XvvgRDiRClfok5JiT//vfL9v528fZx08/+53+8rd5CfZxOcH+KMz8v7sjIJtA kQ4f5oSGjxU6RpVHXXyvHYHp9qr55Z2nVFlv2NBjBFfrWc4FtHvMfn/innvtc7zyPpfTb69vii9G w34rrisH2/YJ9ikL2UAi9gKWk5fe9ppG5wP9CRfL46f/34QTb1ufsDL/zf5vOMR2bYRkEj+X2DGS 66QIJP2x52TTiL2D3GigqcNtbwWjb5fqWdzmJ3z/9dfHfcfcj+0979JfLeuT/dn6e9x+574muXq2 kg0k5kAINuB2tMEGh7DjXQ+w1ykfdvxRw2NPYDS8FnXulwNJ9HfJjkSqAMUF+jU6DiSbMvwasq9b sn5iRBfKWxwQMgRt99n/b/rZcB/NtsJ+KFxvy/jp/rVpX0QDSbOOy56w9QSujch+IPHDjFu8g705 wVvXA8n83PH+CUg2pvOx+izR64yPy+c12uMXrts85um6DiQ5ZfJ5xAPD4YUM3qi4np0FCiNul712 9bQf3fRXfniYR1eibcdvqvXb/dRrE69ns6FHSHxrJ+8fvHQgseuDAhKlv4z9Pi+U+4HkU0CFGzup Duq0gjxV54HkfZ2nbKBfSNUjDKq0ntnHH5TTxPqgzJ31RxmBJL+OuH4rLO9t6pkx6HtIYuFBzAok 3gm0YaYwkJx3ygeBZNnff5b9lCBXiAgkvWrXcHQho55W0ep5MIjyeub6GL8vnLaxfMrG9k1R/xOE glRI8BwGkrm9zu6H3WsLnqth+ZcNJKkXV4E7wOsQUzzMZNcfBJLlBK//az6RUxZIlm1/9mETLI4C yVJABTsPwTBIIOnYizrPdiMXXjsCGBfq2dLmu8XrbybBumm7X5uyHfZZQcA4CSTGps/8PD7qx8wS 9WXt6pl4IJmYgyXUMWJfy0L0GiMEkrmBeXznKRi4k14U9JCDeiZBPpBMbPoTuzWB2GtHMKQNEUgA YExNAslr0mQXzHAdI1IiCCQAIKZRIAEAANhHIAEAAOoIJAAAQB2BBOXMJw7e+CZl3kMCAGL0Agkf o6tD4zhKBhL7MbPyT2Wtc88IGjGQmHN14Xj2Y54nobP952P1T1f4QQzqWRWKIyTmAISTt7S0P1FM PAHNurjCmVivdhKVPr2kFUjsuvQniAgkR/rs1PN0uu/DlgVkuXShRz27S/WWTZNOJMWm2fOPxqbn 83CBZA0B8e8NaTWKkoHkCIHkhVxD2d9ohNsvlXoPcWYE7F3nto96pvweEtOZtx8lyZ2oLS+QuO1p nEi1YePiQLLXeIfn354XMzoyLeHrcsc8GJWyy/q/SyDxt1G9QSGQwHfpKhrdO7jwUZV5IT0y9Te1 qnSq9sROndZJp5o/QqJw60mz0lwYIUmf5/Sx2y0TZyMk03lZ/i997m4ikCCgVPchSqVPykEgaUCt Y/Wvug86uZ1AslyF+51gS8uIgIoLgcTsrztO3mjJzrm/HEj8fZIoVwQSRFTrIQR0HDIJJC3o34s1 HWD87YvGUSBZ99ftf9tGSbnSXAgkn/+ZOvU/f//8/DGBY6eDJ5A0ZI+TH7CjY2YbQW999Ppd3VmX +Lwdr5/rjrdesx24RKKc3aV5zs7KU+fEAublera9AP4s3n4+pZ51EEgm5mSoNvRxyHDyAsmk9f5r Hy/z/KWVdu7Mv6dj+uc/UwX5O+3/znZM5YobSeug8SeQQMtuecVgXMfdbSg27eVgAa9UH4HEdvLK V/w3R0jaNUgdVJobgeTrr6tQ33+nYDItqeO238Cng6NBIIEaUx9alwtbvqer3RHLo21vp30vbUOk aZzHEva4EUiaEBsq29gOX6XCiHEUSIL/b1mxJDraUlcCyXLclv+bG6U1XCSO67RsgsnSmNllPW8E EuhRuEggkFTX/UgXgaQl0yEpjpIMootKcymQPACBBHtMnaBsjKuHCz30FEgwDAIJAKAyAgnKEUgA AJURSAAAgDoCCQAAUEcgAQAA6ggkKMd7SAAAlXUbSJj9cNbjxwkJJMCByvOS9NgGSGj80Vv6mP70 O0JyufHfm80zv5Gwk2x9Jt+al8++tJwYrYNZWVMIJMCxanWk0zZAiAkJTV5r4/CDPB3fsrleEU2h 3jQGFwrg0Uyt6365/RTpoHvtAAkkwIlKEz2+rcw1Gg0ybTujI/3p+z0kVwun+b8ofMRTi8ejIKng kxdIJonnq6HbIUUCCXAqbnOueN9thRYjQpXCIqrr/E2tVwtOehTj83scIOzv2+dRDSQXRnSaIZAA 5+7W4Z7bAEE1gtwR6e3jus4DyfXCE9y2CSq2CyfxVUfqSiQvkLjfa1/FdF1pCCRAljsjHO/tOK9e iOZoMQKDq7oPJJevErxRi7BipwtkaSDxb/fUDiOyFbICAgmQx9SVS2Wm8zZAmNitqsvnAy30H0gm 1wqnCw5//hMHkNQISXrUJG+EREDvlYZAAmS6eEX+9o7z6oXoCbGggyqGCCRXK6cpfL/++b0p2DZo +H8z208Ufp1AcrEBa4lAAmQLR2hzDNAGiBM4BkIhB/WMEUiuFk4bNLz3knhcKFluu4RDo+G6efl0 RMKBZIRKQyABChTefqHjdC5eiO4pD4ZobZBAMqlcOHs1xJAigQQoUtIZclthUXOUpDAUQsU4gQT9 IJAAACojkKAcgQQAUBmBBAAAqCOQAAAAdQQSAACgjkCCcryHBABQ2aCBxH0cLPWFeMMwnfqo+08g Aeox5Yp5R86Zdqeg/vHx6fGMPUIyeqf+wkASTjrnN8J5cw7Y2Xc3E9O5yerW7a5L1QnsCCQQULfj TNeFpR5sJ3281gYt9dAuzS5OTBuRub+EvCFxy0aLDSSDVpiLgcQ1Yv5rnhrPz3ZyAolpbKf/P3h+ 2+BKhQYCCaqby/T8Wz0umMT1aVM/ii+M5tHpZiEklDvBnHkcoyPjIZCg3JVAYq9Yjhq+jEBintc2 pvuNOIEEI8ntYMtlBpK53rnO2/95Ef3t4sVIPeZ1nQWonMegRwQSlLvQKJ0HhfNAsg5t7z+WQIJx SHacVwJJan24j64OftltL7dsDi8iBJzd4rKvQTU04SoCCcqpBJKwYdxrdM6f5wYCCWr6jPhJyAsk 9vf4NqofkoK67upo8HizvvVohB1t3bvNdX5hg349N5DYirKm+LjiB2/KmpbUMKW/PijgtkL466PK cfLcwwsaqTy3A4l5Tv//dxolAgnGIN1xHgQSv21K1CF/BML8vG4jtc8aAeDgOeN2AkNhhATlLgQS F9KOrqSOG7Y4QC5L/HgCCYZweJVfQ94ISdKnUzfbCPdxe7tEI5BMdoLHdv8wEgIJyl0JJHPDFTYi U4MXDQenG7b0OhtSov0gkGAE8h3njUCyBJGpnm/20V5YeCEl/r0Zs4/RBY54yIM0AgnKXQokxhxK PiMcfuMRr3OLbVD3GppEY0ggQf8SnWk1Logk69Ekt37Yx+3so1u3bFsvANj98Nqh+HeMh0CCcpcD yeAIJKiAjrMWP9hJhjy0QiBBOQIJAKAyAgnKEUgAAJURSAAAgDoCCQAAUEcgAQAA6ggkKMd7SAAA lRFIUI5AAmTjY76tmI/+MjHayAgkKEcgAfKYulK1k0xPIFg066spx7123Df3zYY/6uiwCCQoRyAB MrhZU9Nfh3CXCyaXpp9/cCAx+D6bcRFIUE4zkFS/4ixAIEEB2Vs1e4Fkvm1hO/Z5BOVTZl1AikdX NlPE2zp2sM5sz9/+5zWafTKP958nrqvhPqz7n7lvOXoOXDhEIEE5AglwwgUGmdER4yiQmI58qSPu 92A/jjpsu84LAXF9+4SV+W/B490+rSEi3sf498J9yyZ97CGFQIJyBBLghOlsL1zdZzsKJOHzbm5h HHT6ZlQn3GbUudv652/fX78NAsEoUaL+bEaRqgSSxGvGEAgkKNc8kCxXfYml5X4QSJDLdqzjBRLz 2FQ9CwLJbh04CSQ2zCS2LxBIZG+XQQqBBOWaBxKPbdQYIUHvxhwhOR1ZuBtIzupPpUDCCMmYCCQo RyABTmw757puBBL7mJ19s/XrIEjdCSTz8x4HhYN9yyZ97CGFQIJyBBLglO2Mq5cX19nGtz3WTj4n kExsPVr+PwogwTqzePXtViAxXODwt78JDkf7lqPSKAvaI5CgnGkwtAKJJgIJitS42kcpbteMi0CC cgQSII+92udqvRWZUSm0QiBBOQIJkG172wIyzIgU4W9kBBIAAKCOQAIAANQRSAAAgDoCCcrxHhIA QGUEEpQjkADXmXLEmy/vM+0Q9fFRCCQodymQbCdEMssyR4P9JEKw7sKESNYycdTV/z9AIEElZq4M 5ie5g9lYn4hAgnK3RkjSk0Vt5g8wz3EhVLiPWP6ZnoNAgo5xdX8PdfGRCCQo1yKQTD+ZKyA346L/ 8yLxNzsUboKIeQ4CCXrGFf4dzMb6TAQSlGseSFLr49DhP55Agv650TzeSVLMXnjwHpwnIpCgXINA Yn8PGp0oZMT7EAyBE0gwAqFy+nAEuecikKCcVCCZ/r4u2ysgf5g2fFNg3LAnGnp7VXW8/VMEElTG rYdShLgnI5CgXJNbNgmfURCzDS9QmL8HYcNbal5JEUhQG7cfygQjoXgaAgnKaQWSJYhMz398VSl0 FUUgQXW8uTUfx+rpCCQodymQuCASj2AsjUteIJkfdxo2CCQYCFf9eRhNejwCCcrdGiEZGIEEIrjy z8H7bZ6PQIJyBBIAQGUEEpQjkAAAKiOQAAAAdQQSAACgjkACAADUEUhQjveQAAAqI5CgHIEEkGPq F+XM1TfmHXkVAgnKiQUSNx/DZ+K0zXNEk6t91i//5zdeApOjEUjQhCnPfF8L8468D4EE5UQCyRw2 /O1Oz/OZLMpeLUUN1Ge9CyS/p0Z8nVyKQIJx2RmJRUL/KEz9ZXTkbQgkKCcQSM6mjjdXS/vPOc90 +a8fGAgkGJlA+R0IgeydCCQoVz2QzCMcu8OzbvRkf2rtOZBM67//Lo04gQRje+8ti3eHsTcjkKCc ciCxoyXm9s7nb2sgWfeNQILB2duUL7xtYeow9eyVCCQo18UIiRdCNj+bRpxAgtH55fot3viasSCQ oFz1QDKPeux29q6RCp8zDiFrI2buP//+94tAgvG9bbTgraNCsAgkKCcQSFxDFI2STM/zuVIyzxmM kuwHEjui8s8USggkGJ7ASF/H+KjvuxFIUE4ikBhzKNnOMzKL109LOpDMIy4EEjzAez5x8q7whS0C CcpJBZLeEUig4h0dNR/1BYEE5QgkAIDKCCQoRyABAFRGIAEAAOoIJAAAQB2BBAAAqCOQAAAAdQQS ABjI8l1O/rw7YzEfY2YCNGwRSABgNPMkgWOGEgIJ0ggkAICGXCAZd4QHUggkKGZnVHzjfBz2+3T4 4i8AkEAgQTECCQCgNgIJihFIAAC1EUiQZ34Tnf9Nu8vyeXPa5jFR5207dG99FGqWTw8sS/ymt+P1 7ht//fXBPerL++budwfrloUvAkOPeq5nwAECCYoxQgIAqI1AgmIEEgBAbQQSFCOQAABqI5AAAAB1 BBIAAKCOQAIAANQRSAAAgDoCCQAAUEcgAQAA6ggkAABAHYEEAACoI5AAAABlPz//D1MZRqpvxlVK AAAAAElFTkSuQmCC ------=_Part_73233105_963645385.1551961503166-- From nobody Mon Mar 11 01:57: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 73231127968; Mon, 11 Mar 2019 01:57:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <155229467244.16964.2716057971582201801@ietfa.amsl.com> Date: Mon, 11 Mar 2019 01:57:52 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.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, 11 Mar 2019 08:57:53 -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 : NAT64/DNS64 detection via SRV Records Author : Martin Hunek Filename : draft-ietf-v6ops-nat64-srv-00.txt Pages : 8 Date : 2019-03-11 Abstract: This document specifies the way of discovering the NAT64 pools in use as well as DNS servers providing DNS64 service to the local clients. The discovery is done via SRV records, which also allows asignment of priorities to the NAT64 pools as well as DNS64 servers. It also allows clients to have diferent DNS providers than NAT64 provider, while providing a secure way via DNSSEC validation of provided SRV records. This way, it provides DNS64 service even in case where DNS over HTTPS is used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00 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 Mar 11 02:20: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 1521D13109F for ; Mon, 11 Mar 2019 02:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6A2Hd0hkJTYX for ; Mon, 11 Mar 2019 02:19:58 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9FA1310CC for ; Mon, 11 Mar 2019 02:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1552295995; x=1552900795; i=jordi.palet@consulintel.es; q=dns/txt; h=From:Content-Type: Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id: References:In-Reply-To:To; bh=p64fChJEPlV7EUkTRirSi2feqiE5gCzUn9 z7x40shLk=; b=uol7QpisjP7/Sk7xl2/qiJ5IFyXl1VCsbjErycQ8jHo5c5o2Bz r8g3+zNtbGGduTLr05DzfpcUop/fiGqKyJ3WwMsePbsxgGEo2bacELzLfcFiiPko 7AumR2/KC0v4APkiiuxXx2taq9LovjNLcCrIQO/OC44yFRv2CorI9s9rw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 11 Mar 2019 10:19:55 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 11 Mar 2019 10:19:54 +0100 Received: from [10.8.10.10] by mail.consulintel.es (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v16.5.2) with ESMTPSA id md50006181026.msg for ; Mon, 11 Mar 2019 10:19:54 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.8.10.10] X-MDArrival-Date: Mon, 11 Mar 2019 10:19:54 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1973d83fb4=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org From: Jordi Palet Martinez Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Mon, 11 Mar 2019 10:19:51 +0100 Message-Id: References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> In-Reply-To: <155229467244.16964.2716057971582201801@ietfa.amsl.com> To: v6ops@ietf.org X-Mailer: iPhone Mail (16D57) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:20:04 -0000 Confused with this doc. Don=E2=80=99t recall having seen it before and then= , when it was accepted as WG item ? Note: Not meaning to disregard the document contents here. Regards, Jordi > El 11 mar 2019, a las 9:57, internet-drafts@ietf.org escribi=C3=B3: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : NAT64/DNS64 detection via SRV Records > Author : Martin Hunek > Filename : draft-ietf-v6ops-nat64-srv-00.txt > Pages : 8 > Date : 2019-03-11 >=20 > Abstract: > This document specifies the way of discovering the NAT64 pools in > use as well as DNS servers providing DNS64 service to the local > clients. The discovery is done via SRV records, which also allows > asignment of priorities to the NAT64 pools as well as DNS64 servers. > It also allows clients to have diferent DNS providers than NAT64 > provider, while providing a secure way via DNSSEC validation of > provided SRV records. This way, it provides DNS64 service even in > case where DNS over HTTPS is used. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 ********************************************** 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 Mar 11 02:35:39 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFDD1310ED for ; Mon, 11 Mar 2019 02:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Oiw8f8k41w45 for ; Mon, 11 Mar 2019 02:35:21 -0700 (PDT) Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 4B856131074 for ; Mon, 11 Mar 2019 02:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at tul.cz Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id E4AEA18050A1C for ; Mon, 11 Mar 2019 10:35:17 +0100 (CET) From: Martin Hunek To: v6ops@ietf.org Date: Mon, 11 Mar 2019 10:35:13 +0100 Message-ID: <11094911.y04JXqmEik@rumburak.ite.tul.cz> Organization: Technical University of Liberec In-Reply-To: References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4018179.3oaCGjXeOA"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:35:37 -0000 --nextPart4018179.3oaCGjXeOA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi, I suppose it hasn't been. I'm actually new in this, so I'm sorry if I cause= d any confusion. I haven't found any best practice for submission, so I tho= ught it would be the best to make submission first and discuss and make cha= nges afterwards. Best Regards, Martin Dne pond=C4=9Bl=C3=AD 11. b=C5=99ezna 2019 10:19:51 CET, Jordi Palet Martin= ez napsal(a): >=20 > Confused with this doc. Don=E2=80=99t recall having seen it before and th= en, when it was accepted as WG item ? >=20 > Note: Not meaning to disregard the document contents here. >=20 > Regards, > Jordi >=20 > > El 11 mar 2019, a las 9:57, internet-drafts@ietf.org escribi=C3=B3: > >=20 > >=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 : NAT64/DNS64 detection via SRV Records > > Author : Martin Hunek > > Filename : draft-ietf-v6ops-nat64-srv-00.txt > > Pages : 8 > > Date : 2019-03-11 > >=20 > > Abstract: > > This document specifies the way of discovering the NAT64 pools in > > use as well as DNS servers providing DNS64 service to the local > > clients. The discovery is done via SRV records, which also allows > > asignment of priorities to the NAT64 pools as well as DNS64 servers. > > It also allows clients to have diferent DNS providers than NAT64 > > provider, while providing a secure way via DNSSEC validation of > > provided SRV records. This way, it provides DNS64 service even in > > case where DNS over HTTPS is used. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/ > >=20 > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00 > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00 > >=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 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --nextPart4018179.3oaCGjXeOA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJchivVAAoJELUQZepRHeVcdpQH+wYPFOi9r03D08ueWHJxI4oB D8abUwy6oYPdBIbUD81beSsPq4Dg3W7tmDDi1n4+oknv8stII6Pur9xN1d1FlEyR N1NCIMpiEjGg/9w/RQD6CUyJGVn2IkhVHcCIVQvt2kPfYZlWx9W43AanZUzRo3Hh 5RUUACso5fRaQ+dDsUybDV1SX421LZTlEXdMuP8Ig31y/yODorTJuci50J1bdV0E cIw7ksKq2cy3GaNKbeugOEF+2ufkVn9SrZDwwLkJR3W3AiIrxLY3UyUQ75kjYY5d SUI8uowu8ln78aAUy/BDJNS8ibH+eJhnugiWEjfxmsckODSkN7OspeiiLRY3q9U= =XzQ7 -----END PGP SIGNATURE----- --nextPart4018179.3oaCGjXeOA-- From nobody Mon Mar 11 05:08:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254DF130DCB for ; Mon, 11 Mar 2019 05:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtftiD6HyFnH for ; Mon, 11 Mar 2019 05:08:03 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E713130E6B for ; Mon, 11 Mar 2019 05:08:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 942B3320133F; Mon, 11 Mar 2019 09:08:00 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YKM9qf6j_PRj; Mon, 11 Mar 2019 09:07:58 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id D0B5A32010F8; Mon, 11 Mar 2019 09:07:58 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar D0B5A32010F8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1552306078; bh=jZl0UWKX8xvHwKr2ZmgjDBFoHTKSJM/+pkqwE9saKJI=; h=Date:From:To:Message-ID:MIME-Version; b=jUDyBTuzZ4vY0pJZger5YW/wq6i8CBiVUtDnZyEDhmmScNrtPD0t5Hvj/IkJub11G E9OgqdHxUEcQ2T2voGamxJg/RdiTrqwmg3QNEUaj9lP6q6jf8SO5FqwuedET/nuuSG ylhsCajD0/q2HUn1wQT1R2vLixOKo6cmbD71LdmjqOeKx2SsvIAMxqf6fa+Jbv19YB gEhTAohUzBx35Lk2t5ANTfDCz9gr8yzC0F4nItpoK+pVsTW8qcqC/QN0rc9QLGV3oQ s0+2D+Rimeyh1uQ/VdaT4+tLVFck3L9jkH3H1Qnjma6DKda4TbFEk79OXbab+nOx4b 8z5uTV4otJ5Ew== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GDeYla62H0-c; Mon, 11 Mar 2019 09:07:58 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 8F7A832010F2; Mon, 11 Mar 2019 09:07:58 -0300 (-03) Date: Mon, 11 Mar 2019 09:07:58 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Message-ID: <1951652350.101035159.1552306078181.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <977540941.73233109.1551961503169.JavaMail.zimbra@telecentro.net.ar> References: <81BF332B-9694-4E3C-8B80-82C79E6B897A@consulintel.es> <977540941.73233109.1551961503169.JavaMail.zimbra@telecentro.net.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC72 (Win)/8.8.8_GA_1703) Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt Thread-Index: av4aLVl8X++VVKl6OVI6Q05lL1qOcxwCKMEl Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 12:08:06 -0000 Hello Jordi, Have you seen the last email? Have you been able to upload a new version? Regards, Alejandro ----- Mensaje original ----- De: "Alejandro Degidio" Para: "JORDI PALET MARTINEZ" CC: "v6ops@ietf.org list" Enviados: Jueves, 7 de Marzo 2019 9:25:03 Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-= opt-cdn-caches-00.txt Hello Jordi, My answers in line also. Regards, Alejandro ----- Mensaje original ----- > De: "JORDI PALET MARTINEZ" > Para: "v6ops@ietf.org list" > Enviados: Mi=C3=A9rcoles, 6 de Marzo 2019 17:49:18 > Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xla= t-opt-cdn-caches-00.txt > Hi Alejandro, >=20 > Responding below, in-line. >=20 > Regards, > Jordi >=20 >=20 >=20 >=EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Alejandro D'Egidio > > Fecha: mi=C3=A9rcoles, 6 de marzo de 2019, 20:58 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org list" > Asunto: Re: [v6ops] New Version Notification for > draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt >=20 > Hello Jordi, > Thanks for helping with this scenario of CDNs, please let's work toget= her on it. > As a summary you consider these scenarios always in a IPv6-only access= network > (which is the case): > 1- IPv6 capable device/app: it can directly connects to IPv6 service (= CDN, etc). > 2- IPv4 only device/app: they need to use a PLAT to access to the serv= ice. > =20 > I think we can include, as a part of introduction, the actual case of = why ISPs > need to continue providing IPv4 to have a direct connection to CDNs av= oiding > CGN, something like: > .--+--. > / \ > / IPv4 \ > ( Internet ) > /\ / > / \ /\ > / `-----' \ > +-------+ .-----. / \ .-----. > | IPv6 | / \/ \/ Dual- \ > .-----. | CE | / \ .-----. / Stack \ > / IPv4- \ | or +--( DS )---( CGN )---( ) > / only \ | UE | \ Access /\ `-----' \ CDNs/ / > ( SmartTV )--+ | \ / \ \ Caches/ > \ STB / | with | `-----' \ .-----. / `--+--' > \ VoIP / | | \ / \ / > `-----' | CLAT | / IPv6 \/ > | + | ( Internet ) > | IPv4- | \ / > | CGN | \ / > +-------+ `-----' > =20 > Showing that private IPv4 (typically 100.64.0.0/10) can connect direct= ly to CDNs > with public IPv4. >=20 > -> I can't see the picture very well, but I guess you mean to include the > example of what the CDNs do for avoiding the 100.64.0.0/10 traffic via th= e CGN. > I'm wondering if this is the same for CDNs and caches ... We should have = a > clear picture if all them are doing it the same way and describe it. Prob= ably > it may be better to have it in a different section, something like "Compa= rative > situation in IPv4 CGN traffic". Strange you can't see the picture. I attach it. The idea is to show the act= ual case of why ISPs with CGN and CDNs need to have a direct connection wit= h IPv4 without using a CGN. If there is no new definition (this draft) ISPs and CDNs will continue usin= g IPv4 in access network. I think is better to include a simple part in introduction because regardin= g that we are thinking about this new draft. Then, we can have a section with additional information of how it's impleme= nted although it's not necessary because it's not the point of the document= , that's why the idea of just introduction. >=20 > =20 > After the text: > "As show in the precedent picture, this is also the case for other > services, not just CDNs or caches, such as VoIP access to the > relevant operator infrastructure, which may be also dual-stack, but > is not commonly the case for many VoIP devices or applications." > =20 > Can be included a note saying that this is the scenario where ISPs and= CDNs need > to have a direct connection without CGN avoiding the sizing and transl= ation > impact of CGN. > =20 > About the approachings: > DNS/Routing-based Solution Approach: I think that is a good idea. The = thing here > is to know how possible is this to be considered by CNDs. Also, this s= cenario > is just possible if CPE is in router mode. >=20 > -> I heard from CDNs that this approach is not so easy. The way they hand= le the > DNS make it difficult. For caches may be. Yes, I agree. > =20 > CLAT/DNS-proxy-EAMT-based Solution Approach: I think this is a better = approach > where is not necessary to modify anything in CDNs. > I see two things: > a. How long is the timeout of the EAMT entry? > -> Time out should probably be consistent with the TTL of A records (I've= sent > another email about this, because I didn't include it in v00) Yes, I suppose. >=20 > b. How to determine which FQDNs CLAT needs to verify if there is an AA= AA record? > If it tries with all A records it can have a service impact (more dela= y > thinking about a lot of queries per second). > -> I think is easy. A dual-stack will query for the A and AAAA records. I= f the > DNS-proxy is only queried for the A record, it must also query for the AA= AA and > build the EAMT entry. I don't this is heavy at all for the CPE DNS proxy. Yes, maybe it wont have a big impact but by default it will try to find the= AAAA record for all A records queries from hosts. An additional case related to this is when a customer has an additional rou= ter behind the provided CPE. If this additional router doesn't support thes= e new features, I think EAMT entries can solve it. >=20 > CLAT-provider-EAMT-based Solution Approach: Really hard to implement a= nd to > maintain. It depends on features of provisioning systems. With CM we c= an think > on: > Push this information to millions of devices using SNMP and pray to al= l CMs are > online what is not true because there are always CMs offline. > Include this information into a config-file and restart all CMs!? > =20 > For both cases how to update some change to all CMs? > =20 > =20 > I think the best approach is CLAT/DNS-proxy but I'm worried about A re= cord > queries delay where destination is an external service. > =20 >=20 > -> Yes, agree, I think approach number 2 (CLAT responsible for building t= he > EAMT) may be the best choice. Regarding the delay, think on it this way. = If it > was a host with dual-stack, the query will be done anyway for both the A = and > AAAA records, not a big impact. I agree but the idea is to think about devices and apps that only support I= Pv4. >=20 > =20 > Regards, > ALEJANDRO D'EGIDIO > Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3=AD= a > M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 = 11 > 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.ar | > adegidio@telecentro.net.ar ] > Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) From nobody Mon Mar 11 08:37:53 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECEE12796B for ; Mon, 11 Mar 2019 08:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 243lfZ3-WjEE for ; Mon, 11 Mar 2019 08:37:49 -0700 (PDT) Received: from atl4mhob17.registeredsite.com (atl4mhob17.registeredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id C08DF127962 for ; Mon, 11 Mar 2019 08:37:48 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob17.registeredsite.com (8.14.4/8.14.4) with ESMTP id x2BFbjGT043580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 11 Mar 2019 11:37:45 -0400 Received: (qmail 18509 invoked by uid 0); 11 Mar 2019 15:37:45 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 11 Mar 2019 15:37:45 -0000 To: v6ops@ietf.org References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> <11094911.y04JXqmEik@rumburak.ite.tul.cz> From: Lee Howard Message-ID: Date: Mon, 11 Mar 2019 11:37:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <11094911.y04JXqmEik@rumburak.ite.tul.cz> Content-Type: multipart/alternative; boundary="------------0D6E94C6147C6FB4F25267E1" Content-Language: en-US Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 15:37:52 -0000 This is a multi-part message in MIME format. --------------0D6E94C6147C6FB4F25267E1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/11/19 5:35 AM, Martin Hunek wrote: > Hi, > > I suppose it hasn't been. I'm actually new in this, so I'm sorry if I caused any confusion. I haven't found any best practice for submission, so I thought it would be the best to make submission first and discuss and make changes afterwards. On behalf of myself only, don't worry about it. There's a naming convention that is poorly described at https://www.ietf.org/standards/ids/guidelines/  (Section 7). When first submitting a draft, name it draft-lastname-wg-topic. Once the draft is adopted, the chairs will tell you to name it draft-ietf-wg-topic. Comment on the draft: If I understand correctly, your idea is for the home gateway (e.g.) to search the DNS Search List for SRV records indicating the presence of a NAT64.  Then it should synthesize the DNS64 record, or if it can't, use the ipv4only.arpa trick in rfc7050. I think it would work, but I'm not generally in favor of giving more support to people who won't provide forward compatibility. I'd need to think about it more. Lee > Best Regards, > Martin > > Dne pondělí 11. března 2019 10:19:51 CET, Jordi Palet Martinez napsal(a): >> Confused with this doc. Don’t recall having seen it before and then, when it was accepted as WG item ? >> >> Note: Not meaning to disregard the document contents here. >> >> Regards, >> Jordi >> >>> El 11 mar 2019, a las 9:57, internet-drafts@ietf.org escribió: >>> >>> >>> 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 : NAT64/DNS64 detection via SRV Records >>> Author : Martin Hunek >>> Filename : draft-ietf-v6ops-nat64-srv-00.txt >>> Pages : 8 >>> Date : 2019-03-11 >>> >>> Abstract: >>> This document specifies the way of discovering the NAT64 pools in >>> use as well as DNS servers providing DNS64 service to the local >>> clients. The discovery is done via SRV records, which also allows >>> asignment of priorities to the NAT64 pools as well as DNS64 servers. >>> It also allows clients to have diferent DNS providers than NAT64 >>> provider, while providing a secure way via DNSSEC validation of >>> provided SRV records. This way, it provides DNS64 service even in >>> case where DNS over HTTPS is used. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00 >>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------0D6E94C6147C6FB4F25267E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 3/11/19 5:35 AM, Martin Hunek wrote:
Hi,

I suppose it hasn't been. I'm actually new in this, so I'm sorry if I caused any confusion. I haven't found any best practice for submission, so I thought it would be the best to make submission first and discuss and make changes afterwards.

On behalf of myself only, don't worry about it.

There's a naming convention that is poorly described at https://www.ietf.org/standards/ids/guidelines/  (Section 7).

When first submitting a draft, name it draft-lastname-wg-topic.

Once the draft is adopted, the chairs will tell you to name it draft-ietf-wg-topic.


Comment on the draft:

If I understand correctly, your idea is for the home gateway (e.g.) to search the DNS Search List for SRV records indicating the presence of a NAT64.  Then it should synthesize the DNS64 record, or if it can't, use the ipv4only.arpa trick in rfc7050.

I think it would work, but I'm not generally in favor of giving more support to people who won't provide forward compatibility. I'd need to think about it more.

Lee


Best Regards,
Martin

Dne pondělí 11. března 2019 10:19:51 CET, Jordi Palet Martinez napsal(a):

Confused with this doc. Don’t recall having seen it before and then, when it was accepted as WG item ?

Note: Not meaning to disregard the document contents here.

Regards,
Jordi


El 11 mar 2019, a las 9:57, internet-drafts@ietf.org escribió:


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           : NAT64/DNS64 detection via SRV Records
       Author          : Martin Hunek
   Filename        : draft-ietf-v6ops-nat64-srv-00.txt
   Pages           : 8
   Date            : 2019-03-11

Abstract:
  This document specifies the way of discovering the NAT64 pools in
  use as well as DNS servers providing DNS64 service to the local
  clients. The discovery is done via SRV records, which also allows
  asignment of priorities to the NAT64 pools as well as DNS64 servers.
  It also allows clients to have diferent DNS providers than NAT64
  provider, while providing a secure way via DNSSEC validation of
  provided SRV records. This way, it provides DNS64 service even in
  case where DNS over HTTPS is used.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00


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/

_______________________________________________
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



      

      

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


    

  


--------------0D6E94C6147C6FB4F25267E1--


From nobody Mon Mar 11 10:20: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 D81A61277D8 for ; Mon, 11 Mar 2019 10:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 m1CvI2x2lKDz for ; Mon, 11 Mar 2019 10:20:31 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2CD13110F for ; Mon, 11 Mar 2019 10:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id ECD1D18050A1C for ; Mon, 11 Mar 2019 18:20:25 +0100 (CET)
From: Martin Hunek 
To: v6ops@ietf.org
Date: Mon, 11 Mar 2019 18:20:21 +0100
Message-ID: <1791357.vEFxOy6jbE@rumburak.ite.tul.cz>
Organization: Technical University of Liberec
In-Reply-To: 
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> <11094911.y04JXqmEik@rumburak.ite.tul.cz> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1959685.WEO77Y65P8"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2019 17:20:34 -0000

--nextPart1959685.WEO77Y65P8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hi, Lee see a reply inline.

Dne pond=C4=9Bl=C3=AD 11. b=C5=99ezna 2019 16:37:44 CET, Lee Howard napsal(=
a):
>=20
> On 3/11/19 5:35 AM, Martin Hunek wrote:
> > Hi,
> >
> > I suppose it hasn't been. I'm actually new in this, so I'm sorry if I c=
aused any confusion. I haven't found any best practice for submission, so I=
 thought it would be the best to make submission first and discuss and make=
 changes afterwards.
>=20
> On behalf of myself only, don't worry about it.
>=20
> There's a naming convention that is poorly described at=20
> https://www.ietf.org/standards/ids/guidelines/  (Section 7).
>=20
> When first submitting a draft, name it draft-lastname-wg-topic.
>=20
> Once the draft is adopted, the chairs will tell you to name it=20
> draft-ietf-wg-topic.
>=20
Thank you for clarification, I've missed it.
>=20
> Comment on the draft:
>=20
> If I understand correctly, your idea is for the home gateway (e.g.) to=20
> search the DNS Search List for SRV records indicating the presence of a=20
> NAT64.  Then it should synthesize the DNS64 record, or if it can't, use=20
> the ipv4only.arpa trick in rfc7050.

Yes, it is the general idea. Think is that not every end user uses DNS serv=
ers of its ISP (quad8, quad9, and so on). But doing so, they would lost DNS=
64 functionality so they would not have NAT64 available as well. Until now,=
 it was negligible, however with DNS over HTTPS, it might get more pressing=
 (as DoH operator is generally third party). In this case, the RFC7050 tric=
k would not work.

DNS64 SRV record would be used if the end node won't be able to actually do=
 DNS64 itself. If it can, then it might just point to NAT64 prefix from cor=
responding SRV record. If it cannot, than it should use server from DNS64 S=
RV record when it receives NODATA on AAAA query via usual channel.

With DNS64 SRV record I am actually strugling if it should be mandatory or =
optional. If I would only like to cover detection of NAT64 prefix for case =
of DNSSEC validation, then it is not needed. But on the other hand, if I wo=
uld like it to cover cases in which you would have only stub resolver witho=
ut ability of DNS64, then the DNS64 SRV would be quite handy.
>=20
> I think it would work, but I'm not generally in favor of giving more=20
> support to people who won't provide forward compatibility. I'd need to=20
> think about it more.

Can you elaborate on "people who won't provide forward compatibility"? I'm =
not sure what do you mean by that.

Martin
--nextPart1959685.WEO77Y65P8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABCAAGBQJchpjZAAoJELUQZepRHeVcTMcH/3ICHJEopnU3WO0+8prLIV6C
RuntN0Beb2yuc0hGwZL7gl4NnEnmyrZLubigd2fx7MDJsN7Ra5mmCqn2nD56evTp
q8ArHyQSfNdFzz5EnUylsCA1Z8qXXcuxkUJSsEQKsFnaX3u7rhpnwsz+oCoTeJu1
wtYgXXYvZCcGPQdGqLn8xtVvNKRbehCATnwJXg1O90hlRCUFOb3qwQPGA73mGlRE
1C9eNPJxyIcRrWV/O0V1aSIe4G/5sEIaaAPMIKy0FLYlmjDpohMbexDw96rbZUe0
dI9T+GxbUdkq8YpouNF0IO9pIzcz1DwZVHnAqvmtVPcAdZPbA6/ElFRbDJRuUIY=
=EZKm
-----END PGP SIGNATURE-----

--nextPart1959685.WEO77Y65P8--


From nobody Mon Mar 11 10:51: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 9402E128B14 for ; Mon, 11 Mar 2019 10:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level: 
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP62Nlwowwgj for ; Mon, 11 Mar 2019 10:50:57 -0700 (PDT)
Received: from atl4mhob05.registeredsite.com (atl4mhob05.registeredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id A2EEC1279AF for ; Mon, 11 Mar 2019 10:50:57 -0700 (PDT)
Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob05.registeredsite.com (8.14.4/8.14.4) with ESMTP id x2BHosJB007507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 11 Mar 2019 13:50:55 -0400
Received: (qmail 25608 invoked by uid 0); 11 Mar 2019 17:50:54 -0000
X-TCPREMOTEIP: 174.64.33.182
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 11 Mar 2019 17:50:54 -0000
To: v6ops@ietf.org
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> <11094911.y04JXqmEik@rumburak.ite.tul.cz>  <1791357.vEFxOy6jbE@rumburak.ite.tul.cz>
From: Lee Howard 
Message-ID: <0ca23b85-8b7f-1b7f-afe4-2187b2f98b2a@asgard.org>
Date: Mon, 11 Mar 2019 13:50:53 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <1791357.vEFxOy6jbE@rumburak.ite.tul.cz>
Content-Type: multipart/alternative; boundary="------------660207D743E924CB7829C57E"
Content-Language: en-US
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2019 17:50:59 -0000

This is a multi-part message in MIME format.
--------------660207D743E924CB7829C57E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


On 3/11/19 1:20 PM, Martin Hunek wrote:
>
> Dne pondělí 11. března 2019 16:37:44 CET, Lee Howard napsal(a):
>
> Yes, it is the general idea. Think is that not every end user uses DNS servers of its ISP (quad8, quad9, and so on). But doing so, they would lost DNS64 functionality so they would not have NAT64 available as well. Until now, it was negligible, however with DNS over HTTPS, it might get more pressing (as DoH operator is generally third party). In this case, the RFC7050 trick would not work.
Yes, people who use DoH have decided that they don't need to reach the 
tens of millions of people using DNS64.
>
> DNS64 SRV record would be used if the end node won't be able to actually do DNS64 itself. If it can, then it might just point to NAT64 prefix from corresponding SRV record. If it cannot, than it should use server from DNS64 SRV record when it receives NODATA on AAAA query via usual channel.
>
> With DNS64 SRV record I am actually strugling if it should be mandatory or optional. If I would only like to cover detection of NAT64 prefix for case of DNSSEC validation, then it is not needed. But on the other hand, if I would like it to cover cases in which you would have only stub resolver without ability of DNS64, then the DNS64 SRV would be quite handy.
I don't know how you can make it mandatory. Who's going to enforce the rule?
>> I think it would work, but I'm not generally in favor of giving more
>> support to people who won't provide forward compatibility. I'd need to
>> think about it more.
> Can you elaborate on "people who won't provide forward compatibility"? I'm not sure what do you mean by that.

I mean that people on IPv4-only are not compatible with IPv6, which 
everyone knows is the protocol going forward.

I will also say that people who deploy DoH are knowingly losing 
connectivity. I refer to the first paragraph of Section 10 "Operational 
Considerations" of the DoH RFC, rfc8484:

    Local policy considerations and similar factors mean different DNS
    servers may provide different results to the same query, for
    instance, in split DNS configurations [RFC6950].  It logically
    follows that the server that is queried can influence the end result.
    Therefore, a client's choice of DNS server may affect the responses
    it gets to its queries.  For example, in the case of DNS64 [RFC6147],
    the choice could affect whether IPv6/IPv4 translation will work at
    all.

Lee

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

--------------660207D743E924CB7829C57E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 3/11/19 1:20 PM, Martin Hunek wrote:

    

    

      

Dne pondělí 11. března 2019 16:37:44 CET, Lee Howard napsal(a):


      

      
Yes, it is the general idea. Think is that not every end user uses DNS servers of its ISP (quad8, quad9, and so on). But doing so, they would lost DNS64 functionality so they would not have NAT64 available as well. Until now, it was negligible, however with DNS over HTTPS, it might get more pressing (as DoH operator is generally third party). In this case, the RFC7050 trick would not work.

    

    Yes, people who use DoH have decided that they don't need to reach
    the tens of millions of people using DNS64.

    

      

DNS64 SRV record would be used if the end node won't be able to actually do DNS64 itself. If it can, then it might just point to NAT64 prefix from corresponding SRV record. If it cannot, than it should use server from DNS64 SRV record when it receives NODATA on AAAA query via usual channel.

With DNS64 SRV record I am actually strugling if it should be mandatory or optional. If I would only like to cover detection of NAT64 prefix for case of DNSSEC validation, then it is not needed. But on the other hand, if I would like it to cover cases in which you would have only stub resolver without ability of DNS64, then the DNS64 SRV would be quite handy.


    

    I don't know how you can make it mandatory. Who's going to enforce
    the rule?

    

      

        
I think it would work, but I'm not generally in favor of giving more 
support to people who won't provide forward compatibility. I'd need to 
think about it more.


      

      
Can you elaborate on "people who won't provide forward compatibility"? I'm not sure what do you mean by that.

    

    
I mean that people on IPv4-only are not compatible with IPv6,
      which everyone knows is the protocol going forward.

    

    
I will also say that people who deploy DoH are knowingly losing
      connectivity. I refer to the first paragraph of Section 10
      "Operational Considerations" of the DoH RFC, rfc8484:

    
   Local policy considerations and similar factors mean different DNS
   servers may provide different results to the same query, for
   instance, in split DNS configurations [RFC6950].  It logically
   follows that the server that is queried can influence the end result.
   Therefore, a client's choice of DNS server may affect the responses
   it gets to its queries.  For example, in the case of DNS64 [RFC6147],
   the choice could affect whether IPv6/IPv4 translation will work at
   all.

    
 

    
Lee

    

    

      

Martin

      

      

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


    

  


--------------660207D743E924CB7829C57E--


From nobody Mon Mar 11 11:23: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 192E012426A for ; Mon, 11 Mar 2019 11:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1-ntfb3-Uby3 for ; Mon, 11 Mar 2019 11:23:17 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 B03151310F0 for ; Mon, 11 Mar 2019 11:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 1E2321867FA44 for ; Mon, 11 Mar 2019 19:23:12 +0100 (CET)
From: Martin Hunek 
To: v6ops@ietf.org
Date: Mon, 11 Mar 2019 19:23:06 +0100
Message-ID: <2234233.06BcvnN4Zm@rumburak.ite.tul.cz>
Organization: Technical University of Liberec
In-Reply-To: <0ca23b85-8b7f-1b7f-afe4-2187b2f98b2a@asgard.org>
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> <1791357.vEFxOy6jbE@rumburak.ite.tul.cz> <0ca23b85-8b7f-1b7f-afe4-2187b2f98b2a@asgard.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1600842.1sULF9XDHN"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2019 18:23:23 -0000

--nextPart1600842.1sULF9XDHN
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Dne pond=C4=9Bl=C3=AD 11. b=C5=99ezna 2019 18:50:53 CET, Lee Howard napsal(=
a):
>=20
> On 3/11/19 1:20 PM, Martin Hunek wrote:
> >
> > Dne pond=C4=9Bl=C3=AD 11. b=C5=99ezna 2019 16:37:44 CET, Lee Howard nap=
sal(a):
> >
> > Yes, it is the general idea. Think is that not every end user uses DNS =
servers of its ISP (quad8, quad9, and so on). But doing so, they would lost=
 DNS64 functionality so they would not have NAT64 available as well. Until =
now, it was negligible, however with DNS over HTTPS, it might get more pres=
sing (as DoH operator is generally third party). In this case, the RFC7050 =
trick would not work.
> Yes, people who use DoH have decided that they don't need to reach the=20
> tens of millions of people using DNS64.
It really depends, who would actually choose to use it. When web browser ve=
ndor chooses to prefer DoH, the end user would be the one without working N=
AT64/DNS64.
> >
> > DNS64 SRV record would be used if the end node won't be able to actuall=
y do DNS64 itself. If it can, then it might just point to NAT64 prefix from=
 corresponding SRV record. If it cannot, than it should use server from DNS=
64 SRV record when it receives NODATA on AAAA query via usual channel.
> >
> > With DNS64 SRV record I am actually strugling if it should be mandatory=
 or optional. If I would only like to cover detection of NAT64 prefix for c=
ase of DNSSEC validation, then it is not needed. But on the other hand, if =
I would like it to cover cases in which you would have only stub resolver w=
ithout ability of DNS64, then the DNS64 SRV would be quite handy.
> I don't know how you can make it mandatory. Who's going to enforce the ru=
le?
I mean MUST vs. SHOULD. No one would actually force it.
> >> I think it would work, but I'm not generally in favor of giving more
> >> support to people who won't provide forward compatibility. I'd need to
> >> think about it more.
> > Can you elaborate on "people who won't provide forward compatibility"? =
I'm not sure what do you mean by that.
>=20
> I mean that people on IPv4-only are not compatible with IPv6, which=20
> everyone knows is the protocol going forward.
This is somehow philosophical issue. If I deploy NAT64/DNS64 it is because =
I want my IPv6 users to be able to access IPv4 internet. This is something =
which actually allows me to shutdown IPv4 in internal network sooner. But I=
 understand that it might be even used other way around and allow this way =
access to internal IPv4 network. This is than slowing IPv6 deployment in pa=
rticular network, but at least it somehow ease access to such network from =
IPv6 hosts. So it won't hurt overall.=20
>=20
> I will also say that people who deploy DoH are knowingly losing=20
> connectivity. I refer to the first paragraph of Section 10 "Operational=20
> Considerations" of the DoH RFC, rfc8484:
>=20
>     Local policy considerations and similar factors mean different DNS
>     servers may provide different results to the same query, for
>     instance, in split DNS configurations [RFC6950].  It logically
>     follows that the server that is queried can influence the end result.
>     Therefore, a client's choice of DNS server may affect the responses
>     it gets to its queries.  For example, in the case of DNS64 [RFC6147],
>     the choice could affect whether IPv6/IPv4 translation will work at
>     all.

Thanks for clarification.

Martin
>=20
> Lee
>=20
> >
> > Martin
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>=20


--nextPart1600842.1sULF9XDHN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABCAAGBQJchqePAAoJELUQZepRHeVchykH/jZacAz6crF5UV41HTpELpVp
9wi+tKr3/iAKSd1nj4A0jC08BqddEtJVOMrABke02YRzviUpiNN9m1P2+L1rRzTm
7dFwX/5ZyF31ipGc4gt43Lmll4VVB0QSGbxG+ynmpSup1rhRSVedaET1vxdtn/PO
4FRcSmyiwxhPqSlN7nLZlFiR8trMGWB1Vs2JQl+9u2Uafxf6Ke5l3xtQgB/5PhNj
JvHIK0F+/G0rxAPBKE23pCyFNnXbce0lVK7wWD8o9DeNBiS5eMYsoIEjJXoV8BRu
vCPp1rtzJBISWGlW+CKfMh3BXJypxkyczFUK/uoinkeN3UyAo3mV8FwWRQTL1rA=
=1PBt
-----END PGP SIGNATURE-----

--nextPart1600842.1sULF9XDHN--


From nobody Mon Mar 11 11:29: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 2F0EE12426A for ; Mon, 11 Mar 2019 11:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8rrs9GxReUH for ; Mon, 11 Mar 2019 11:29:01 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9A512008A for ; Mon, 11 Mar 2019 11:29:00 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1C45E41B8A for ; Mon, 11 Mar 2019 19:28:58 +0100 (CET)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 09EA241967; Mon, 11 Mar 2019 19:28:58 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id F076FB73E5; Mon, 11 Mar 2019 19:28:57 +0100 (CET)
Date: Mon, 11 Mar 2019 19:28:57 +0100
From: Gert Doering 
To: Lee Howard 
Cc: v6ops@ietf.org
Message-ID: <20190311182857.GY10407@Space.Net>
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> <11094911.y04JXqmEik@rumburak.ite.tul.cz>  <1791357.vEFxOy6jbE@rumburak.ite.tul.cz> <0ca23b85-8b7f-1b7f-afe4-2187b2f98b2a@asgard.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0ca23b85-8b7f-1b7f-afe4-2187b2f98b2a@asgard.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.11.2 (2019-01-07)
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2019 18:29:03 -0000

Hi,

On Mon, Mar 11, 2019 at 01:50:53PM -0400, Lee Howard wrote:
> I will also say that people who deploy DoH are knowingly losing 
> connectivity. 

Unfortunately, those people that push DoH into browsers etc. are causing 
breakage for *other* people, who wouldn't know who to complain to.

Ceterum censeo, DoH must die.  In flames.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279


From nobody Mon Mar 11 15:27:23 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F901228B7 for ; Mon, 11 Mar 2019 15:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uecU_LDlvbxD for ; Mon, 11 Mar 2019 15:27:19 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86AD1277E6 for ; Mon, 11 Mar 2019 15:27:19 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id e17so215498pgd.2 for ; Mon, 11 Mar 2019 15:27:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HOoCIFIsxhmq5up1tDdoVTr+BT4UA3fxV1NExkTbZ4Y=; b=a31MDLQK+rqe5pcoTVg2idNDvbFLgCY+cYakrNypccZMlod9fhyKNsbbEFxfixfsu+ KJ2z/OM3iNPEcmo6xZ1Rij4yuBLo5EZwfkVMu6jowTk6Ae9Fp0lva7xNP80V1z7pmCvw P7x6g0cpjvzxEcMUD1CW/smojNzzz0GM7z3fPM2JI4JdenQKLqsvdNwSWitBbiJ6ivVE vsg22DviHo3K9TP2GODVN0k/OzK2sxuzJmqM0SDPwLlDPossqXgEwpIZAsM/1vnE85eX NbGOj0Ljef8bv35jxM2GNmOsX5kBvANU1VyI7MeC/i4D8oeR97q9HneTgFPVyPNq0rzy XKQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HOoCIFIsxhmq5up1tDdoVTr+BT4UA3fxV1NExkTbZ4Y=; b=iteE+oi5WW3kmGwinePcctSjCsHifaWYx8JIFv6f6mV1G93nQb4I7udJF7fyLTCJlq hsE/uufmzOZl+Aol9RA8hUq9H2Bkv/ZOCjdEOL0dLCAtMqrmioWr/+D5c3139tuOghXc 9C4rezke9LgRttwtMAdoyvbt+xCYQIWaY+wBJ+xd3W9N7SnVlpmp+EdtwM4Gg8mKA5zI 87LsdNDzg+wniGXn6DCaHp60Rijqw5J7ikMydr8PXl42A1PBg353e/T/nfIbanUGASHa 46fxLXBF7ZOwuWDgAyGuvg9GZNWBeykytDAn3TbGbvJDm7i647em1w+MoL5BuJz3tgDl 3KGA==
X-Gm-Message-State: APjAAAW8oXmhOHZUWYSuJQYevQVXLYgUmPQy4Ga9ZGQEg23QMQqugTtE +RgTXNrK2O4Cro9SaWBMLbrIzvJu
X-Google-Smtp-Source: APXvYqzz2CobB6lueTlvO0iHcV7HlFaDoVjm27J7U2OdOEB/XdL57Uft5eZiUiiXmWHcYWcOLbKFIA==
X-Received: by 2002:a62:a10c:: with SMTP id b12mr34920845pff.234.1552343238906;  Mon, 11 Mar 2019 15:27:18 -0700 (PDT)
Received: from [192.168.178.21] (211.231.69.111.dynamic.snap.net.nz. [111.69.231.211]) by smtp.gmail.com with ESMTPSA id j4sm8966585pfn.132.2019.03.11.15.27.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 15:27:18 -0700 (PDT)
To: Lee Howard , v6ops@ietf.org
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com>  <11094911.y04JXqmEik@rumburak.ite.tul.cz> 
From: Brian E Carpenter 
Message-ID: 
Date: Tue, 12 Mar 2019 11:27:15 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2019 22:27:22 -0000

Wait a minute... the I-D submission tool is supposed to block such filena=
mes and require WG Chair approval - there was definitely a robotic or hum=
an glitch here.

I'd like to know if it was robotic glitch, because that could be fixed ;-=
). If it was a human glitch, never mind.

Regards
   Brian

On 12-Mar-19 04:37, Lee Howard wrote:
>=20
> On 3/11/19 5:35 AM, Martin Hunek wrote:
>> Hi,
>>
>> I suppose it hasn't been. I'm actually new in this, so I'm sorry if I =
caused any confusion. I haven't found any best practice for submission, s=
o I thought it would be the best to make submission first and discuss and=
 make changes afterwards.
>=20
> On behalf of myself only, don't worry about it.
>=20
> There's a naming convention that is poorly described at https://www.iet=
f.org/standards/ids/guidelines/=C2=A0 (Section 7).
>=20
> When first submitting a draft, name it draft-lastname-wg-topic.
>=20
> Once the draft is adopted, the chairs will tell you to name it draft-ie=
tf-wg-topic.
>=20
>=20
> Comment on the draft:
>=20
> If I understand correctly, your idea is for the home gateway (e.g.) to =
search the DNS Search List for SRV records indicating the presence of a N=
AT64.=C2=A0 Then it should synthesize the DNS64 record, or if it can't, u=
se the ipv4only.arpa trick in rfc7050.
>=20
> I think it would work, but I'm not generally in favor of giving more su=
pport to people who won't provide forward compatibility. I'd need to thin=
k about it more.
>=20
> Lee
>=20
>=20
>> Best Regards,
>> Martin
>>
>> Dne pond=C4=9Bl=C3=AD 11. b=C5=99ezna 2019 10:19:51 CET, Jordi Palet M=
artinez napsal(a):
>>> Confused with this doc. Don=E2=80=99t recall having seen it before an=
d then, when it was accepted as WG item ?
>>>
>>> Note: Not meaning to disregard the document contents here.
>>>
>>> Regards,
>>> Jordi
>>>
>>>> El 11 mar 2019, a las 9:57, internet-drafts@ietf.org escribi=C3=B3:
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts d=
irectories.
>>>> This draft is a work item of the IPv6 Operations WG of the IETF.
>>>>
>>>>        Title           : NAT64/DNS64 detection via SRV Records
>>>>        Author          : Martin Hunek
>>>>    Filename        : draft-ietf-v6ops-nat64-srv-00.txt
>>>>    Pages           : 8
>>>>    Date            : 2019-03-11
>>>>
>>>> Abstract:
>>>>   This document specifies the way of discovering the NAT64 pools in
>>>>   use as well as DNS servers providing DNS64 service to the local
>>>>   clients. The discovery is done via SRV records, which also allows
>>>>   asignment of priorities to the NAT64 pools as well as DNS64 server=
s.
>>>>   It also allows clients to have diferent DNS providers than NAT64
>>>>   provider, while providing a secure way via DNSSEC validation of
>>>>   provided SRV records. This way, it provides DNS64 service even in
>>>>   case where DNS over HTTPS is used.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of su=
bmission
>>>> 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/
>>>>
>>>> _______________________________________________
>>>> 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 di=
sclosure, copying, distribution or use of the contents of this informatio=
n, even if partially, including attached files, is strictly prohibited an=
d will be considered a criminal offense. If you are not the intended reci=
pient be aware that any disclosure, copying, distribution or use of the c=
ontents of this information, even if partially, including attached files,=
 is strictly prohibited, will be considered a criminal offense, so you mu=
st reply to the original sender to inform about this communication and de=
lete it.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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


From nobody Mon Mar 11 15:47: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 6A5051311C3 for ; Mon, 11 Mar 2019 15:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0Gghl7wwoFwL for ; Mon, 11 Mar 2019 15:47:20 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2531E128B33 for ; Mon, 11 Mar 2019 15:47:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1552344436; x=1552949236; 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=BfNSOAyr GNhfmjX/LcFm7IGzZerY4xIk5uYhbWAABuE=; b=cNVKeVgTBEAzC+i0/+7dBsLj aShFUdhoRQRrp7AmzygqFyXcBY1uWVsk9jKCanywyqPIwwkVGxpqBx9YyYgcOJsi +OBeURl/dpnvdr5YlalbfeF1TVSORuO9EW1HwJOHyARCReOQJoqC9GlTx6hB53+W W5MXq2uL+c3RJb+OA5s=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 11 Mar 2019 23:47:16 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 11 Mar 2019 23:47:14 +0100
Received: from [192.168.1.81] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006181803.msg for ; Mon, 11 Mar 2019 23:47:13 +0100
X-MDRemoteIP: 10.8.10.6
X-MDHelo: [192.168.1.81]
X-MDArrival-Date: Mon, 11 Mar 2019 23:47:13 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1973d83fb4=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.7.190210
Date: Mon, 11 Mar 2019 23:47:12 +0100
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <2B2A9CEF-1BFF-4F93-A499-49D28AFD9E6E@consulintel.es>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com>  <11094911.y04JXqmEik@rumburak.ite.tul.cz>  
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2019 22:47:25 -0000

I guessed so, and I'm sure it was that way, so that's why I got really conf=
used!

I was thinking: my god, I lost a full thread for so many months? I've lost =
my memory or what?

Regards,
Jordi
=20
=20

=EF=BB=BF-----Mensaje original-----
De: v6ops  en nombre de Brian E Carpenter 
Fecha: lunes, 11 de marzo de 2019, 23:27
Para: Lee Howard , 
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt

    Wait a minute... the I-D submission tool is supposed to block such file=
names and require WG Chair approval - there was definitely a robotic or hum=
an glitch here.
   =20
    I'd like to know if it was robotic glitch, because that could be fixed =
;-). If it was a human glitch, never mind.
   =20
    Regards
       Brian
   =20
    On 12-Mar-19 04:37, Lee Howard wrote:
    >=20
    > On 3/11/19 5:35 AM, Martin Hunek wrote:
    >> Hi,
    >>
    >> I suppose it hasn't been. I'm actually new in this, so I'm sorry if =
I caused any confusion. I haven't found any best practice for submission, s=
o I thought it would be the best to make submission first and discuss and m=
ake changes afterwards.
    >=20
    > On behalf of myself only, don't worry about it.
    >=20
    > There's a naming convention that is poorly described at https://www.i=
etf.org/standards/ids/guidelines/  (Section 7).
    >=20
    > When first submitting a draft, name it draft-lastname-wg-topic.
    >=20
    > Once the draft is adopted, the chairs will tell you to name it draft-=
ietf-wg-topic.
    >=20
    >=20
    > Comment on the draft:
    >=20
    > If I understand correctly, your idea is for the home gateway (e.g.) t=
o search the DNS Search List for SRV records indicating the presence of a N=
AT64.  Then it should synthesize the DNS64 record, or if it can't, use the =
ipv4only.arpa trick in rfc7050.
    >=20
    > I think it would work, but I'm not generally in favor of giving more =
support to people who won't provide forward compatibility. I'd need to thin=
k about it more.
    >=20
    > Lee
    >=20
    >=20
    >> Best Regards,
    >> Martin
    >>
    >> Dne pond=C4=9Bl=C3=AD 11. b=C5=99ezna 2019 10:19:51 CET, Jordi Palet=
 Martinez napsal(a):
    >>> Confused with this doc. Don=E2=80=99t recall having seen it before =
and then, when it was accepted as WG item ?
    >>>
    >>> Note: Not meaning to disregard the document contents here.
    >>>
    >>> Regards,
    >>> Jordi
    >>>
    >>>> El 11 mar 2019, a las 9:57, internet-drafts@ietf.org escribi=C3=B3=
:
    >>>>
    >>>>
    >>>> 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           : NAT64/DNS64 detection via SRV Records
    >>>>        Author          : Martin Hunek
    >>>>    Filename        : draft-ietf-v6ops-nat64-srv-00.txt
    >>>>    Pages           : 8
    >>>>    Date            : 2019-03-11
    >>>>
    >>>> Abstract:
    >>>>   This document specifies the way of discovering the NAT64 pools i=
n
    >>>>   use as well as DNS servers providing DNS64 service to the local
    >>>>   clients. The discovery is done via SRV records, which also allow=
s
    >>>>   asignment of priorities to the NAT64 pools as well as DNS64 serv=
ers.
    >>>>   It also allows clients to have diferent DNS providers than NAT64
    >>>>   provider, while providing a secure way via DNSSEC validation of
    >>>>   provided SRV records. This way, it provides DNS64 service even i=
n
    >>>>   case where DNS over HTTPS is used.
    >>>>
    >>>>
    >>>> The IETF datatracker status page for this draft is:
    >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/
    >>>>
    >>>> There are also htmlized versions available at:
    >>>> https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00
    >>>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-0=
0
    >>>>
    >>>>
    >>>> 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.or=
g.
    >>>>
    >>>> Internet-Drafts are also available by anonymous FTP at:
    >>>> ftp://ftp.ietf.org/internet-drafts/
    >>>>
    >>>> _______________________________________________
    >>>> 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 privilege=
d or confidential. The information is intended to be for the exclusive use =
of the individual(s) named above and further non-explicilty authorized disc=
losure, copying, distribution or use of the contents of this information, e=
ven if partially, including attached files, is strictly prohibited and will=
 be considered a criminal offense. If you are not the intended recipient be=
 aware that any disclosure, copying, distribution or use of the contents of=
 this information, even if partially, including attached files, is strictly=
 prohibited, will be considered a criminal offense, so you must reply to th=
e original sender to inform about this communication and delete it.
    >>>
    >>>
    >>>
    >>> _______________________________________________
    >>> 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
   =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 Mar 11 16: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 AF58C131246 for ; Mon, 11 Mar 2019 16:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmNNEe7YpSJp for ; Mon, 11 Mar 2019 16:58:26 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D555F13124C for ; Mon, 11 Mar 2019 16:58:26 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id j5so437942pfa.2 for ; Mon, 11 Mar 2019 16:58:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F8evrBnO4nl3eLPzMrkq1km8Pc/2ddnc/lC9C7amu2g=; b=UbE/sIHWYkfrlrZDhJG4fHVXS3Eu77lEfqA2791JtALiHRzGv7WugrJ6HenGN2urPc nawZJC4jS311zQgHbdXsbOR/XgN/ahx9/gy3ThngAY9rRilXz47Kmf+O7IljRmaEc+sY vA/Ja2RCVWmuauS+PIoGrX76SbpHYuzPhXkjni1KWZa2KitYOWcw9Vg7W0rjkyW0Iedu HuM0bEPAXXYTGQmHJ5eItC5FR21nXVINVBFEH5TOUapKbDm1XSTw2B1qBi732uHvmdrs aUD6VYILpAFBbwLfI42ZGOeVMRBysUvTwYHKWAe1Jq6ewgyX/3VtuwOyFx0jkOnUi+3Z b6tg==
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=F8evrBnO4nl3eLPzMrkq1km8Pc/2ddnc/lC9C7amu2g=; b=G+MhcP0CRSBds9gXi3grBB5K1HLVnYddnbkz+OV+ag9QD5PVuJ66eWI7TGIHyBDMCu YiIWejnDSH1rGcddNvNbe/+ywhBtfAOQ3nY3TVLnZ9OgCLaJYXH1qaMOQM+HcQx4i4D0 YZpz0LwZFj+3jF2TNq2mWFsc1zKJHOIGpvHYPuXX2THptp3fTDEr8mgITkMXbAYc5gsu TWSM2F6XVqypAKIfTNuZLlxcz8cjGVVbrqqDKsD/GptEalB6gBiC5jwcoCHW0zz0s2+P IsAhCtL397cuhWpdI8nxUrSOmJxnsm8jLiPhGcYoN2S5DYmnSbfho/RhZTtvfZY+EB3d WMCA==
X-Gm-Message-State: APjAAAWbzAxPx6fryrAkrkE7mswfjEdWK1DZFferhJAHFGqY0LfMA+C0 G2I+QAeAsIX8ulNT9hM91EMJ/kahk5w=
X-Google-Smtp-Source: APXvYqzBVRn6ixSCdFlsmQjGDfl1qRdsQC/ME5Q71F/vmQDO9R5jNiip5QclYKyEYrQ9o9uGyJijIg==
X-Received: by 2002:a63:6b03:: with SMTP id g3mr15121447pgc.239.1552348706308;  Mon, 11 Mar 2019 16:58:26 -0700 (PDT)
Received: from ?IPv6:2620:f:8000:210:21fa:5941:8612:9889? ([2620:f:8000:210:21fa:5941:8612:9889]) by smtp.gmail.com with ESMTPSA id i126sm16486222pfb.15.2019.03.11.16.58.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 16:58:25 -0700 (PDT)
From: Fred Baker 
Message-Id: <60747B6D-C9CB-4DDA-89D3-7519DCA07AB5@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_27A88996-68BF-4736-80D7-5832986071CC"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Tue, 12 Mar 2019 08:58:22 +0900
In-Reply-To: 
Cc: v6ops@ietf.org
To: Jordi Palet Martinez 
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> 
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2019 23:58:35 -0000

--Apple-Mail=_27A88996-68BF-4736-80D7-5832986071CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Mar 11, 2019, at 6:19 PM, Jordi Palet Martinez =
 wrote:
>=20
> Confused with this doc. Don=E2=80=99t recall having seen it before and =
then, when it was accepted as WG item ?

As Martin says, it's a brand new doc, and there's a glitch in the title. =
It was rejected on initial submission because the date was malformed. I =
took the executive perspective that, especially since the author is in =
the Czech Republic, it would be better to have the topic on the table =
and discuss it than get all quibbly with a new author.

I would invite commentary on the substance of the draft, which has to do =
with how one determines the prefix one should use in a CLAT, and =
proposes a solution in an SRV record. If there is working group =
interest, we can invite Martin to discuss it at IETF 104.

--Apple-Mail=_27A88996-68BF-4736-80D7-5832986071CC
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+AFAlyG9h4ACgkQEhdRnd2G
P+Ahkg//b54b00h+n7jwgRjqmqX8n+wONdbpdL3iZdgI4uDA3p+G8qXv85Nqzd6c
upJNVIKCjFr88BlGbnS9609JJlh02D4HDykqzktjfJdGb8dOWi+nIt2YMSDOIDJI
BfbhfLl30tWCpRVWSuZuZcb9pCMK0PHGG3zmdDv7wXb1/DEho3Z/vEzR5rSai2Ej
Ze0WFwGhMoOPdBCEIWZI/5TGqOkUpO69qbJLkqengjaI6+1jdiDkCROdPWN2780c
5M7OE+lYKi1FTNyp9F7vSMBiA4HORpqtxa5xYX0A3JS3YOpAsTBoRO1IGO0QQ7vG
pZhix2MjBZbBe4+PSuxuOVNMmEDeUXfryHUcLLUiNOC+x78nEWn9Txjhb01geRlC
DNAEQPD51ZQgV0c4h2z+gBtO7PIPCl4i0ou619ee6C2zwffVQqC49wCVqQGn0tvN
k5uxGcev0PdQ4ooLvdirM6RRCrJcWSs4ng+aOCKWCVhUwKNyRpgw8hjhBnVoBNYj
lQ7tnloPM6WbdPnMKFfT96XYJxNUS2+BD7ygJCOzpvok6ly4ihFbU/q+mQdd3rQW
moXKnHIBr9LMlvXpnaSrzw2azYFo6IIRdOnRyp1a47aj9qvUbBmWh5h8wQjYIiQ1
BAaoWR1NOTeusOvqMr7DqF82d053pHZ+TRHTSjNBDPRUHi3SSLg=
=kkV7
-----END PGP SIGNATURE-----

--Apple-Mail=_27A88996-68BF-4736-80D7-5832986071CC--


From nobody Mon Mar 11 18:00:53 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37DE127876 for ; Mon, 11 Mar 2019 18:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFTiziPH7wJm for ; Mon, 11 Mar 2019 18:00:49 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA671277CD for ; Mon, 11 Mar 2019 18:00:48 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id z13so490095qki.2 for ; Mon, 11 Mar 2019 18:00:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZEWtBwZx85k4t0KhJQfOF1wNIxkyliz+yItfwSiJf3M=; b=FPZLyrEHO9fQAPFRLMh0yVwJ37R5b1FvXAsyM9cJtVoEN6YfkH//tYV8qCspvcN3U/ omuBilK/xxWyj9E6B4qqth6h8xYZwficOPCla9J2+FIfPbikgFNp9R1nI5JkoAz3jOCz IJ1mKByw7SSUrbq9kPBBzvdU+XMfVdkBv99wcuLJeuelrIGwBb/FYoslweBvLb7ENW/N wsY+1dORoLYQDG3vKr1g1CgrA5wm5oFALGvyFZojVlWIVNyxQLcPOGY1HbfQJoZTSGyW nX+HPx3VwhjWEzUhwaCt0rUjVXi7rAcdR7wC0EpZR4axAI8CMFYoAcTamcDKTR6JiQiu mtqA==
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=ZEWtBwZx85k4t0KhJQfOF1wNIxkyliz+yItfwSiJf3M=; b=oKAcdj/mkWF833idzPYfUU0oO06ZSSa3OSnJvOGfKWi02UMWbCfIkulP8QAL02nreq xRHK/PeQBGm2Z2WnO7+waLi5Dup5sLpTNOHK+NPHtMf3t59JCE6dB71ZQfWruz1IFMzT M1IC9/mrMmW0iBdVMeBkr8YOMt62T+cbzgYBUQ7gY5m4mg0M7xouHBJssbRgSgsJTTKa volAeQ/UgUuMMdo9rBJUIyqGYBnimAkP1kB41exdW0iWUuYRNYASl69o8L6WYnhxNsLM Vw1hqFlB2ljD5MlvlqnHk+o0k8Bwm+ZUjFewF0jl/ooEWZVywJ09fW79rPu8IIti26sq 0l+w==
X-Gm-Message-State: APjAAAVBfXNpkpXODdpsAiIoKia2w1f9xBWFvTtRt54zSM8wB7CflEN2 1c8bmqAFWu3pdAhlaVfubMC1OyHzmUc=
X-Google-Smtp-Source: APXvYqyHKFKuvgGS35lgpCzFEJNhVMT4cZ99u20k1BHDoA1DNDOzOi7/438H9xCXsGiSA+8VP4yLkw==
X-Received: by 2002:ae9:e113:: with SMTP id g19mr6164239qkm.285.1552352447800;  Mon, 11 Mar 2019 18:00:47 -0700 (PDT)
Received: from ?IPv6:2620:f:8000:210:21fa:5941:8612:9889? ([2620:f:8000:210:21fa:5941:8612:9889]) by smtp.gmail.com with ESMTPSA id w8sm6426145qkw.80.2019.03.11.18.00.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 18:00:46 -0700 (PDT)
From: Fred Baker 
Message-Id: <76A6C573-2DEE-41A9-89FB-9F8F02EC0F8A@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E12F455E-67D8-4BCA-919A-0C1DCEDAE976"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Tue, 12 Mar 2019 10:00:42 +0900
In-Reply-To: <11094911.y04JXqmEik@rumburak.ite.tul.cz>
Cc: IPv6 Operations 
To: Martin Hunek 
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com>  <11094911.y04JXqmEik@rumburak.ite.tul.cz>
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2019 01:00:52 -0000

--Apple-Mail=_E12F455E-67D8-4BCA-919A-0C1DCEDAE976
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Chair hat off.

The biggest concern or question that I have in this is that it appears =
that networks now have an *expectation* that there is a NAT64 and a =
DNS64 somewhere in the network, which to my knowledge is only a =
reasonable expectation during the transition period. To put that in =
context, I at one time used an HE tunnel to provide IPv6 service in my =
home, and then my upstream (which was first Cisco and later Cox) =
provided that service. So I *could* have had a NAT64 in my home, and =
then the service moved to whoever was upstream of me. Over time, One =
could imagine the service moving again. If I were maintaining my DNS =
service, they would have to track that changing landscape, which I could =
imagine becoming a headache.

So the intent of the draft makes sense to me. I find myself wondering =
about the operational implications. Maybe you can fill me in?


> On Mar 11, 2019, at 6:35 PM, Martin Hunek  wrote:
>=20
> Signed PGP part
> Hi,
>=20
> I suppose it hasn't been. I'm actually new in this, so I'm sorry if I =
caused any confusion. I haven't found any best practice for submission, =
so I thought it would be the best to make submission first and discuss =
and make changes afterwards.
>=20
> Best Regards,
> Martin
>=20
> Dne pond=C4=9Bl=C3=AD 11. b=C5=99ezna 2019 10:19:51 CET, Jordi Palet =
Martinez napsal(a):
>>=20
>> Confused with this doc. Don=E2=80=99t recall having seen it before =
and then, when it was accepted as WG item ?
>>=20
>> Note: Not meaning to disregard the document contents here.
>>=20
>> Regards,
>> Jordi
>>=20
>>> El 11 mar 2019, a las 9:57, internet-drafts@ietf.org escribi=C3=B3:
>>>=20
>>>=20
>>> 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.
>>>=20
>>>       Title           : NAT64/DNS64 detection via SRV Records
>>>       Author          : Martin Hunek
>>>   Filename        : draft-ietf-v6ops-nat64-srv-00.txt
>>>   Pages           : 8
>>>   Date            : 2019-03-11
>>>=20
>>> Abstract:
>>>  This document specifies the way of discovering the NAT64 pools in
>>>  use as well as DNS servers providing DNS64 service to the local
>>>  clients. The discovery is done via SRV records, which also allows
>>>  asignment of priorities to the NAT64 pools as well as DNS64 =
servers.
>>>  It also allows clients to have diferent DNS providers than NAT64
>>>  provider, while providing a secure way via DNSSEC validation of
>>>  provided SRV records. This way, it provides DNS64 service even in
>>>  case where DNS over HTTPS is used.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/
>>>=20
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00
>>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of =
submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> 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
>>=20
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>=20
>=20
>=20

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


--Apple-Mail=_E12F455E-67D8-4BCA-919A-0C1DCEDAE976
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+AFAlyHBLsACgkQEhdRnd2G
P+Bfdw/8DXBsJuvURdfT6Aes+FHMXvNV/0KRMz6uEL2IcJewb4aC5Rlk5fUzNMnR
WKGaHMH6FFN5BPO7aN4ss6xTRZ4198q171gUOy1Tbs+bo0VvjSzJ+lpjRtA6CHsC
gHZNIShUq0SA6EuU7almwn9No8xe+3/J70ikiFwbG1A1RWgbvzHRy6joYO2/0sVF
nLm/XCcaZee9wJ24wGaZmWf4xSY5p8u4kJrrPW/gQACWolqTnNiWKrsy0+c0JDGg
crBZCM03K7ke9eh48emvHVIy/hAEJxtbDjGSDzdbsnmRa0EIosZMHD3sLMt+qsC9
kwCNJS2vc72BTOM6p2xnhs9wCuxumyqPq7KWyDBIQFaHwd73T966HQV5m1VPSjna
B4tdXiN+HFcI8VEkuwoDQp4bGHEnIX6ZoAFoaW3LOWXhlr4isUIwKbFEk9dN1K1S
PtTf6yPGv3KaDCvnZRZXT5aVt4Qvn93DG+45p0jnOm2UP3M0dVXVw1U/ZJafnmGh
jOjIxw9b4ZRRelQRTZ7QCSs6EcpqkPwSbq0NCfW18VfvOmbZ1u4Xebfb5cnXi8EK
CnhpBy53U6bew1zdhTvSxfVXVzkxdlwnNYDpFGb0WnVOvBDx6kRDcgq02NB09+UM
Q2ExPfYN6S4cwRe34oA9V+tC9In4ih5Y2l5ykDQWD+pXkqQtsjg=
=RLsU
-----END PGP SIGNATURE-----

--Apple-Mail=_E12F455E-67D8-4BCA-919A-0C1DCEDAE976--


From nobody Mon Mar 11 18:19: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 7751D131209 for ; Mon, 11 Mar 2019 18:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTjvGvHud1ev for ; Mon, 11 Mar 2019 18:19:29 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315B5130DCD for ; Mon, 11 Mar 2019 18:19:29 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id 125so465552pgc.12 for ; Mon, 11 Mar 2019 18:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UYTsfc864IaXvekxT7GfY/fQcq1AtY6C+0q4jhRC7/o=; b=Gn5PLiGDtFlnHgYc80Ze5SX7L1w3exgu84bOC05ZF0rDRnfLSISbsMRJpWWxV3E844 goLICWZSMPQnqUyyV10kxLOt8vOwav8OyhaEgvNfBxUCk2MbqoHswMoDKhKjPuWwG4JZ xoWF8LmUauawlnwPppjl48596sgCC42u3vCAmIgWAa5wgOkYcnCkdy8/f/0HvdU+j0FB rd5MKKHq0KGkZfYBPjyp0tQP3lRMAq0pUDyMDLixdOj8VmRTuqhDADV39p009vGdfroY lKaSeEFMuWEg6r1FIAZDK5dd+uwSmmC+BLmhuMfcb124DTahhgF+Tp2flvc6/3scxWCk or9g==
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=UYTsfc864IaXvekxT7GfY/fQcq1AtY6C+0q4jhRC7/o=; b=dwatG0T5ddp6b4AaWBsq+xI7doYGt30lqKvhHIRynichOvzF8uHrIW4tbGMJt/ppxL Cnqc2iBF0IhRJEjem4wsi5JCIYJQii6fM2t/zzD+FOXFLiT9bABZnfZsvZKS88IWgIFp mwDq8eCdau+BE00PJ2UxAQGe4agqvKgnDDtlav5EAEPntbk9hK+ZecdllWREHsN8VLLi nZx8SMiXKYRxV4bQbmXMJIa8pLIKumN0AkPb9yKEC0moTpc958jqfO6OFceHOqQeItbx iLvLbTeYH69sXy+ElLa2/nhfYhAAZEh1hagzed0RD9P0WaTxqNwZ25qyWkwWneDfZfPW RfHA==
X-Gm-Message-State: APjAAAXUcGL3859vZF1off/u4EuzQEB/oC+w8zrXRhmw8OOBC0Jdyr3Y EJ7gjz1NUEvdqyriibCGKm0=
X-Google-Smtp-Source: APXvYqzMTHCriTPkT0JOyeJShnX29DP2oAKTH7QCbSItVpbGuG2f/7FRy6oTSVn1XX66pDVVHtrjJg==
X-Received: by 2002:aa7:8c1a:: with SMTP id c26mr35916499pfd.31.1552353568601;  Mon, 11 Mar 2019 18:19:28 -0700 (PDT)
Received: from ?IPv6:2620:f:8000:210:21fa:5941:8612:9889? ([2620:f:8000:210:21fa:5941:8612:9889]) by smtp.gmail.com with ESMTPSA id j1sm8997092pgp.84.2019.03.11.18.19.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 18:19:27 -0700 (PDT)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_873A5B78-8179-4141-9A90-2766D40B5479"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Tue, 12 Mar 2019 10:19:24 +0900
In-Reply-To: 
Cc: Lee Howard , v6ops@ietf.org
To: Brian E Carpenter 
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com>  <11094911.y04JXqmEik@rumburak.ite.tul.cz>  
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2019 01:19:30 -0000

--Apple-Mail=_873A5B78-8179-4141-9A90-2766D40B5479
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Mar 12, 2019, at 7:27 AM, Brian E Carpenter =
 wrote:
>=20
> Wait a minute... the I-D submission tool is supposed to block such =
filenames and require WG Chair approval - there was definitely a robotic =
or human glitch here.

There were a couple of glitches, and I'm part of one of them in that I =
asked the Secretariat to post the draft for discussion. Blame me.

--Apple-Mail=_873A5B78-8179-4141-9A90-2766D40B5479
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+AFAlyHCR0ACgkQEhdRnd2G
P+B8tQ//ZZsNpwgl3u6KIi4VFG+BGTRYKDAa0onRVRG8aq6jk/bPwQooaH4FvBuB
v9Sv/llrZUOKp5ldfvfQvoGB879sf+IjcjkdI3sa8+XAeJT7K7iljNl36m75Oxav
LvzDiC0K5SctRYa0yQ9GpnAusT9I8Rfw/Uyufoy6s+uaDIfAq3OgVZjjjykYERBk
5bEfCsbI2ik7slUPCV5DGdMK90McIlM9XBYIm0k27fqZoiZzVIT37c3jWN7/JQ9k
8MBl9EYKRYJcihmjbLlF1214FkLGJx/aRjq45boWrQ/E1QojD4HcLUkojHpk1xQr
TTaSFvGYjsLvlL88wQ8PEo064Oo3dbvTqXp6b3n+TQ8uMN1jgWKMaj2ZwrOhAFhR
Izf43pPrboI8OgjZ03yYYkUP9pFn2q7tEjvYNSiFVoNvWO8qPrf2YzBPfWmq7LSM
5jHxreT3IuQKz2mFmNjly/I7C00aU6aeYC3hGihBVifKqA5+PxHKCr+KEIKhB14c
HaQz3wJuKOxL2JAGsgOU4XLap98DFPf2WMnoqTTJLb7x56+9fdQOxvzjOJxJz+9c
9CowSm64SvkCJGKICQyR+T5IxOCVvCHh4azmpnuicX+sJYxj8QNEQM3n5btWZiiy
T3PfjsiTbfbctg2i/uzvtqCmFaHsvlgxjfsVkvKUHmffJuPA62g=
=1oiu
-----END PGP SIGNATURE-----

--Apple-Mail=_873A5B78-8179-4141-9A90-2766D40B5479--


From nobody Mon Mar 11 18:39: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 EA3E8129570 for ; Mon, 11 Mar 2019 18:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjsmkawuZG89 for ; Mon, 11 Mar 2019 18:39:25 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A68128CF2 for ; Mon, 11 Mar 2019 18:39:25 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id u9so515962pgo.7 for ; Mon, 11 Mar 2019 18:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cm5qaaOWTd8av7G4jfvj9aL90UMu1UprJKqAMGw1J2A=; b=EaezlN0E1kTPy2dCItiDGnbfK+QQP/mBVeX6G9AzAn8e7y79w92tk/GiCVpneVvXCV AfkWv1RDTiTyxDhC/mUXkUIIs3A490CHKoheWMDJsq6d/YZLDf8Q2aj19fub+3T1u+iL uIOsFpEu03Qfdv/qt2+Xm27e9Bi+ZMB6GzlGh/TU5543+ec6uFiMmxgY0EYDCOV9Ojgo P47mPeQCh1C0DRtS9Zk8PRZHdeZk2GEXtqlYOWlbsIdmPS0aK9s9+sRU7QDPWy/QGHVb i7mXk2vtKMRJTRRznUgfiaotT4T77WdlZA9Dz2xoYNpnXSL9/arxDtMwD33WmcOVI2lf 68HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cm5qaaOWTd8av7G4jfvj9aL90UMu1UprJKqAMGw1J2A=; b=VUSavBs1ko/uxX896FxwihroyqHozfvNaj9WGaJguc5YPmYqjc+pImG/r5M2/U02Tl oHLyXkg6SrdRe2EngSv2Us/+SeKifGX8yVxL4ML3ENJjKcnnM1tDy00iQ8gEvWUGpo7l 6VReb/h9OHaMmE9YRQOtrz5Q2gcrHVG2sgkrIy1KUU+F7OLVzeh3hqMCZEc8CaZjCgnl HBwUm30RUWM/fCTF0ZP9f8MAFxwz5VJgtllgO0srDVm8Nu7RF5HjrWY9dGSDTFY+YL5n /fEWAL5VqHqFIBJmoz6xs7de30wVUbW7Yav6wOQG7beCrAG0qSb338VVdBBnRyxnM3fz 7qng==
X-Gm-Message-State: APjAAAXnnxiBj1O2yP/CpgrLz9klehHimWmjaw9lNlj4XXsGSbTeWvRA FdwdO047Zt8W4eWFFwsStpw7xL4u
X-Google-Smtp-Source: APXvYqxDoS/cKI2JCO0WKWLvlrz34D2oQhC/Fchiex86llNjXd5F5ZbouU4g5z74zxyOSHSaGgOJkA==
X-Received: by 2002:a17:902:5a5:: with SMTP id f34mr6476073plf.35.1552354764603;  Mon, 11 Mar 2019 18:39:24 -0700 (PDT)
Received: from [192.168.178.30] (211.231.69.111.dynamic.snap.net.nz. [111.69.231.211]) by smtp.gmail.com with ESMTPSA id x23sm23137018pfe.0.2019.03.11.18.39.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 18:39:23 -0700 (PDT)
To: Fred Baker 
Cc: Lee Howard , v6ops@ietf.org
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com>  <11094911.y04JXqmEik@rumburak.ite.tul.cz>   
From: Brian E Carpenter 
Message-ID: <8dbe1de8-e4b2-516d-9b32-1d83e3578f6c@gmail.com>
Date: Tue, 12 Mar 2019 14:39:21 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
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] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2019 01:39:27 -0000

On 12-Mar-19 14:19, Fred Baker wrote:
> 
> 
>> On Mar 12, 2019, at 7:27 AM, Brian E Carpenter  wrote:
>>
>> Wait a minute... the I-D submission tool is supposed to block such filenames and require WG Chair approval - there was definitely a robotic or human glitch here.
> 
> There were a couple of glitches, and I'm part of one of them in that I asked the Secretariat to post the draft for discussion. Blame me.

No blame, except possibly that our newcomers' documentation doesn't properly cover the draft naming rules. You'd think it would be clear in section 7 of https://www.ietf.org/standards/ids/guidelines/ but it isn't, from a newcomer's point of view.

   Brian


From nobody Tue Mar 12 08:19: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 CDFFB1310B7 for ; Tue, 12 Mar 2019 08:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ZmneMKY31I4H for ; Tue, 12 Mar 2019 08:19:10 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 9C19713108E for ; Tue, 12 Mar 2019 08:19:09 -0700 (PDT)
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 m1h3jBL-0000ImC; Tue, 12 Mar 2019 16:19:07 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com>  <60747B6D-C9CB-4DDA-89D3-7519DCA07AB5@gmail.com> 
In-reply-to: Your message of "Tue, 12 Mar 2019 08:58:22 +0900 ." <60747B6D-C9CB-4DDA-89D3-7519DCA07AB5@gmail.com> 
Date: Tue, 12 Mar 2019 16:19:07 +0100
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2019 15:19:12 -0000

>I would invite commentary on the substance of the draft, which has to do 
>with how one determines the prefix one should use in a CLAT, and 
>proposes a solution in an SRV record. 

Let me summerize this proposal as: take the search list you get in an RA
option (or from DHCPv6), prepend some strings and use that to look up the
NAT64 translation prefix and other information in DNS.

At first glance it seems clever. And certainly RA/DHCPv6 agnostic.

What I'm worried about is overloading the DNS search list with network 
configuration.

Suppose an organisation or ISP has the same search list everywhere but
some networks have NAT64 and others don't (or different networks have different
prefixes).

You can add a dummy name to the search list, but that name will then attract
DNS lookups.

Another question, how robust is the search list. Do CPEs obtain the search list
from the upstream ISP and then announce them downstream?


From nobody Tue Mar 12 15:21: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 8E70512426E for ; Tue, 12 Mar 2019 15:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BINB--IxrKQk for ; Tue, 12 Mar 2019 15:21:30 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 014CD12762F for ; Tue, 12 Mar 2019 15:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [IPv6:2001:718:1c01:260:73fc:b828:6ebf:30fa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id CF47D18050A1C; Tue, 12 Mar 2019 23:21:24 +0100 (CET)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: Fred Baker 
Cc: IPv6 Operations 
Date: Tue, 12 Mar 2019 23:21:15 +0100
Message-ID: <8657094.6HGt6YDM17@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: <76A6C573-2DEE-41A9-89FB-9F8F02EC0F8A@gmail.com>
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> <11094911.y04JXqmEik@rumburak.ite.tul.cz> <76A6C573-2DEE-41A9-89FB-9F8F02EC0F8A@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart8515707.rcZPZpsK3C"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2019 22:21:32 -0000

--nextPart8515707.rcZPZpsK3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Yes, I suppose so. However it is not actually change in respect to RFC7050.=
 It=20
also expects network has NAT64 deployed by checking ipv4olny.arpa.

But I guess that I should explicitly wrote there what should happen in case=
=20
there is only NAT64 SRV pointing to the ".". In this case the NAT64 is not=
=20
present, so end node should not to continue with NAT64 detection (even by=20
means of RFC7050).

Idea is that it should track those changes by itself. Basically, your DNS s=
tub=20
or recursive resolver tries after the boot/connection detect NAT64 at your=
=20
upstream (by detecting local domain and asking for SRV for=20
_nat64._ipv6.). So from your example:

1) When having only HE tunnel, your ISP would not provide you with NAT64=20
service either. It would also be irrelevant as you have IPv4.
2) After you have got native IPv6, your ISP can provide you with NAT64. You=
r=20
router with DNS resolver can detect it via SRV record and use upstream DNS6=
4=20
or do DNS64 itself based upon detected prefix.
3) When the upstream NAT64 prefix changes, your resolver would eventually=20
discovers that because TTL of SRV record.
4) When you would prefer to run NAT64 locally then you would set up also DN=
S64=20
and make your computers to use it.

If you want the DoH to work with NAT64, you would need to have an actual=20
domain and have NAT64 SRV record pointing to your prefix. This is not a=20
problem in the network of a larger organization, but it would not=20
unfortunately solve DoH vs DNS64 problem for small residential networks aft=
er=20
CPE. I've just realized it while replying to you. But at least it solves th=
at=20
for those with domain. Maybe it could also work with some service like DynD=
NS=20
but with SRV, I would have to think about that little more.

Martin


Dne =C3=BAter=C3=BD 12. b=C5=99ezna 2019 2:00:42 CET, Fred Baker napsal(a):
> Chair hat off.
>=20
> The biggest concern or question that I have in this is that it appears th=
at
> networks now have an *expectation* that there is a NAT64 and a DNS64
> somewhere in the network, which to my knowledge is only a reasonable
> expectation during the transition period. To put that in context, I at one
> time used an HE tunnel to provide IPv6 service in my home, and then my
> upstream (which was first Cisco and later Cox) provided that service. So I
> *could* have had a NAT64 in my home, and then the service moved to whoever
> was upstream of me. Over time, One could imagine the service moving again.
> If I were maintaining my DNS service, they would have to track that
> changing landscape, which I could imagine becoming a headache.
>=20
> So the intent of the draft makes sense to me. I find myself wondering abo=
ut
> the operational implications. Maybe you can fill me in?
> > On Mar 11, 2019, at 6:35 PM, Martin Hunek  wrote:
> >=20
> > Signed PGP part
> > Hi,
> >=20
> > I suppose it hasn't been. I'm actually new in this, so I'm sorry if I
> > caused any confusion. I haven't found any best practice for submission,
> > so I thought it would be the best to make submission first and discuss
> > and make changes afterwards.
> >=20
> > Best Regards,
> > Martin
> >=20
> > Dne pond=C4=9Bl=C3=AD 11. b=C5=99ezna 2019 10:19:51 CET, Jordi Palet Ma=
rtinez napsal(a):
> >> Confused with this doc. Don=E2=80=99t recall having seen it before and=
 then, when
> >> it was accepted as WG item ?
> >>=20
> >> Note: Not meaning to disregard the document contents here.
> >>=20
> >> Regards,
> >> Jordi
> >>=20
> >>> El 11 mar 2019, a las 9:57, internet-drafts@ietf.org escribi=C3=B3:
> >>>=20
> >>>=20
> >>> 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 t=
he
> >>> IETF.
> >>>=20
> >>>       Title           : NAT64/DNS64 detection via SRV Records
> >>>       Author          : Martin Hunek
> >>>  =20
> >>>   Filename        : draft-ietf-v6ops-nat64-srv-00.txt
> >>>   Pages           : 8
> >>>   Date            : 2019-03-11
> >>>=20
> >>> Abstract:
> >>>  This document specifies the way of discovering the NAT64 pools in
> >>>  use as well as DNS servers providing DNS64 service to the local
> >>>  clients. The discovery is done via SRV records, which also allows
> >>>  asignment of priorities to the NAT64 pools as well as DNS64 servers.
> >>>  It also allows clients to have diferent DNS providers than NAT64
> >>>  provider, while providing a secure way via DNSSEC validation of
> >>>  provided SRV records. This way, it provides DNS64 service even in
> >>>  case where DNS over HTTPS is used.
> >>>=20
> >>> The IETF datatracker status page for this draft is:
> >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/
> >>>=20
> >>> There are also htmlized versions available at:
> >>> https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00
> >>>=20
> >>>=20
> >>> Please note that it may take a couple of minutes from the time of
> >>> submission until the htmlized version and diff are available at
> >>> tools.ietf.org.
> >>>=20
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>=20
> >>> _______________________________________________
> >>> 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
> >>=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 t=
he
> >> intended recipient be aware that any disclosure, copying, distribution
> >> or use of the contents of this information, even if partially, includi=
ng
> >> 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
> -------------------------------------------------------------------------=
=2D--
> ---- The fact that there is a highway to hell and a stairway to heaven is=
 an
> interesting comment on projected traffic volume...


--nextPart8515707.rcZPZpsK3C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlyIMNsACgkQtRBl6lEd
5Vwa3Af/bhihnfdN67NSKm5SfLBDC6gQrG4mPSDiXkDD8gUPlSTsAoO4jd7MfTRA
Xn5ah/aOgsFDXsPnLFgCdbHQe7gp61CRGSwuKcdwqZJjkte/oyKrH1ClxAlZHVdi
8usIMkLF2XUDydp7chI6ntTLdZonGAWsI6TsQnvJezs45K4v09HWmRG608WhAqWQ
8l1TT2rRxoSmQIknf/VLmL7VhuE5aKS0o7W79LbdOxtk8IFv/4cc3GQVdWyv5lg6
uks+hMFvS9jK9fMrYX9k9sTtqPKhD9TaDy3dpUmrJ9s39Tp87hMMIT20KRrEml93
KPSa6tLRUXz/Y3XYUCXfwNFKmS/AEA==
=uNZX
-----END PGP SIGNATURE-----

--nextPart8515707.rcZPZpsK3C--




From nobody Tue Mar 12 15:23: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 C5C721224E8 for ; Tue, 12 Mar 2019 15:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUhduIrhJMf7 for ; Tue, 12 Mar 2019 15:23:51 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 053F71200D7 for ; Tue, 12 Mar 2019 15:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [IPv6:2001:718:1c01:260:73fc:b828:6ebf:30fa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id CD12918050A1C for ; Tue, 12 Mar 2019 23:23:48 +0100 (CET)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: v6ops@ietf.org
Date: Tue, 12 Mar 2019 23:23:47 +0100
Message-ID: <1661479.kfQ0g9K5eE@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: <60747B6D-C9CB-4DDA-89D3-7519DCA07AB5@gmail.com>
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com>  <60747B6D-C9CB-4DDA-89D3-7519DCA07AB5@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart103527782.2fpVOsBoDr"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2019 22:23:52 -0000

--nextPart103527782.2fpVOsBoDr
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Dne =C3=BAter=C3=BD 12. b=C5=99ezna 2019 0:58:22 CET, Fred Baker napsal(a):
> > On Mar 11, 2019, at 6:19 PM, Jordi Palet Martinez
> >  wrote:
> >=20
> > Confused with this doc. Don=E2=80=99t recall having seen it before and =
then, when
> > it was accepted as WG item ?
> As Martin says, it's a brand new doc, and there's a glitch in the title. =
It
> was rejected on initial submission because the date was malformed. I took
> the executive perspective that, especially since the author is in the Cze=
ch
> Republic, it would be better to have the topic on the table and discuss it
> than get all quibbly with a new author.
>=20
> I would invite commentary on the substance of the draft, which has to do
> with how one determines the prefix one should use in a CLAT, and proposes=
 a
> solution in an SRV record. If there is working group interest, we can
> invite Martin to discuss it at IETF 104.

I would be delighted to discuss it with you and WG in person.

Martin

--nextPart103527782.2fpVOsBoDr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlyIMXMACgkQtRBl6lEd
5Vx2QAf/Z5LWtzY7A2MHPr3t4ZL9ZcoFlxlykjSWcMMd7l5ksY8TkYEd15d4sSYx
1uVsJo9Qf3IagMvXsQluB5q7bZlCy13cdlZJQ5vv4X8P20FbL/CjX/6NlLHjYac0
j1FHncxNOCM2KWF9Wg2yUb0wa2c13eYjhJPqDtsZ3W9ekbuNlakL59NJlDX+ouPG
/9zPr+tM6A3J+yTsAYkYvW1rYJUIVhG1fw0BZcCBRPUumnX6D9vYIVpaXT9vFA9/
udWTIxYwx9hvN0Tg5+0Qidq3gJwjDoRMjKHqXFjycuL9oxRaOtw0eO3bB+4Sfm2I
raDNqcUWsyDUlNXpuLWRRUTgSCuBFA==
=yDuK
-----END PGP SIGNATURE-----

--nextPart103527782.2fpVOsBoDr--




From nobody Tue Mar 12 15:45:08 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2CF1224E8 for ; Tue, 12 Mar 2019 15:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level: 
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXlaBsDHLvdU for ; Tue, 12 Mar 2019 15:45:00 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 D2F2212426E for ; Tue, 12 Mar 2019 15:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [IPv6:2001:718:1c01:260:73fc:b828:6ebf:30fa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 42047180651E1 for ; Tue, 12 Mar 2019 23:44:57 +0100 (CET)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: v6ops@ietf.org
Date: Tue, 12 Mar 2019 23:44:50 +0100
Message-ID: <2346094.e1kSnA8yxG@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: 
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> <60747B6D-C9CB-4DDA-89D3-7519DCA07AB5@gmail.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3818903.RW6JfcgKtZ"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2019 22:45:01 -0000

--nextPart3818903.RW6JfcgKtZ
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Dne =C3=BAter=C3=BD 12. b=C5=99ezna 2019 16:19:07 CET, Philip Homburg napsa=
l(a):
> >I would invite commentary on the substance of the draft, which has to do
> >with how one determines the prefix one should use in a CLAT, and
> >proposes a solution in an SRV record.
>=20
> Let me summerize this proposal as: take the search list you get in an RA
> option (or from DHCPv6), prepend some strings and use that to look up the
> NAT64 translation prefix and other information in DNS.
>=20
> At first glance it seems clever. And certainly RA/DHCPv6 agnostic.
>=20
> What I'm worried about is overloading the DNS search list with network
> configuration.
>=20
> Suppose an organisation or ISP has the same search list everywhere but
> some networks have NAT64 and others don't (or different networks have
> different prefixes).
>=20
> You can add a dummy name to the search list, but that name will then attr=
act
> DNS lookups.

I such case it could be solved by multiple views to the zone or higher orde=
r=20
subdomain in DNSSL. Like: example.net, areaXYZ.example.net. I agree that it=
=20
would attract DNS lookups so it might not be ideal.
>=20
> Another question, how robust is the search list. Do CPEs obtain the search
> list from the upstream ISP and then announce them downstream?

Yes, this is major setback for solving DoH vs. DNS64 issue as DNSSL is not=
=20
transitive through CPE (and it might brake things if it would be). I'll try=
 to=20
come up with some solution for that. It seems like I've been looking on tha=
t=20
from just one angle.

Martin


--nextPart3818903.RW6JfcgKtZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlyINmIACgkQtRBl6lEd
5Vx3Mgf/fIUUgTV4/InQIO/iQkMvd9sOBdp/BhJfNT3z7Hycs5n6FxwGWC+otXfl
RrQ4q8feNZDhctczjSESd2pE5MeXAB6IgXWEWa5M1Do4Z+Z8WIwDM2LiFCUWPTjz
MP7IBS7gSUdswoSSXhpYfjKegvxfwzAPqiODgHcRZjmU9vvyIBoqPnVk7j0uLbBk
35MSEe/Wl3xHANd+wtFhdKzO9EtFRAnUzlnR+sYDkmCpnX0Ldi5rQpIAlsA9mm5g
T74PfsCdn58zeO2T1IV8FvHF5bA/VYlqb5k7+6Tsw08b+MvNDzk46CTdgTSY1lM0
Jcj5saX3u0jz51YkuJmYIi1m+bTlmw==
=+sq+
-----END PGP SIGNATURE-----

--nextPart3818903.RW6JfcgKtZ--




From nobody Wed Mar 13 15: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 56A381200ED for ; Wed, 13 Mar 2019 15:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihXP9iZXfTRf for ; Wed, 13 Mar 2019 15:50:02 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 4528F12798D for ; Wed, 13 Mar 2019 15:50:02 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id v12so2575323pgq.1 for ; Wed, 13 Mar 2019 15:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=b6KpctTvq7LUNYVavRwIHLSF/91maA1Tszf2bW8RkUI=; b=h7Yl50Whwv7eJ0nMyEc13nx16xHkKAsykWmL4WQA6R0HfQcTKyLoJ4J7IKBCltljjG jG8yacF4N1OCrb/HaXSXqEEHy68BFlowDmsgYpYJuHl+h8sf7qOrwxBkS9TQ3FlXjqUr JqiQXY/h+NnKh8/PF2+zbxHVmKb27V+6XvhbwKb9j7OxBwom/jtMClmqsAJqxHeAZcgK xoXWR/Bw0LY4ze2nD/Ovdu9h9Nek1dHkGmLcJKPbrkIQYHouxgvixDqKTAXSV/UrV/Mt DFhurEpkV08CsgvyO6GeqMJr5WTFyrpIbFsvFvy/p30JPTE3K7YYgSFLvfL9XBlBuX0W bxCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=b6KpctTvq7LUNYVavRwIHLSF/91maA1Tszf2bW8RkUI=; b=j+GBqi6wMJprhZJNiDrMp6ndBQoZVK0bBcbwGdNNkljzg+hGxPHuJ2MM9nvFdB+lh+ 9sVJOzf2o/eO/ceWXmhKi9170up5dWWRmRxvYiv/GCKsnAqD1xrU8cHv5rJZB2lKX4Mk sDFDY/DVucrd++cEPiR7yhKObaQkRNK0kkjQYMJMb/HDw7OtabVe7oY4Je/i5H50EDTD ZPd+hWpNOWPHFdgjhevgDDuSopO5fCRhTBRBeJKG0b4hb98NdajAAIVN79zKzvyOxaWC Mp9+hwL30JnRXkFXUIc/tEmMSn3VBKRIgr5bl5hlSuECssdbXi01483t/K/hDA4ANbDO lfZw==
X-Gm-Message-State: APjAAAVqHpuTjpUFLGj8zSs8Q697pJtm3DUzJ9pzHAd/GnXLMOBCjeiY dX7yAmsNXmM08WJoVQvbW2DB7HSvpg0=
X-Google-Smtp-Source: APXvYqwJydGOd9VHErUzc/QIZDv/gzNyh3/PY6SKW+bo5Y6vguSjMsj2m+VF2cCXodC6EQfiv4ljWw==
X-Received: by 2002:a17:902:1621:: with SMTP id g30mr48013543plg.116.1552517401505;  Wed, 13 Mar 2019 15:50:01 -0700 (PDT)
Received: from [192.168.128.100] (ai126149041041.54.access-internet.ne.jp. [126.149.41.41]) by smtp.gmail.com with ESMTPSA id q62sm24848426pga.32.2019.03.13.15.49.58 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Mar 2019 15:49:59 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_DF84599D-DE45-48E5-BB04-B8E9AAB053B5"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Message-Id: <8046089A-B428-487A-B4D2-B7FCCFFAECA4@gmail.com>
Date: Thu, 14 Mar 2019 07:49:55 +0900
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: 
Subject: [v6ops] Agenda for IETF 104 posted
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 13 Mar 2019 22:50:04 -0000

--Apple-Mail=_DF84599D-DE45-48E5-BB04-B8E9AAB053B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I have just posted the proposed meeting agenda for v6ops at IETF 104; =
you will find it at =
https://datatracker.ietf.org/meeting/104/materials/agenda-104-v6ops-00. =
Now would be the time to bash it :-)
=
--------------------------------------------------------------------------=
------
The fact that there is a highway to hell and a stairway to heaven is an =
interesting comment on projected traffic volume...


--Apple-Mail=_DF84599D-DE45-48E5-BB04-B8E9AAB053B5
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+AFAlyJiRMACgkQEhdRnd2G
P+Ct0g//aCDJZJDM6xWbNK8T2soDJqSP70avzEKP+6iiP1ryyI9UyEuDfMyFkXXr
MRLGzU4mB/hJcu5lUDMMaAmrPyYYpkTtLPX8aUrdkBkLlhcZvmOhrlJZnQbQYMAP
otIqwYBaNPIUemzIBjRapt1WKhWsEiv4i3ZUEhoyR0n0dNwvJJSJBSKMK3atXvzQ
ylErztvL2G1WyF/lG2ePpFWn6wEz6zIIdHguIY2emSYTz3yM9XDCFj2mNHlkGP8c
2VmIm4P6LYzCTjVF5Hlco5jtQDyEx/YI4TSH9c3WgGZSWZYpiQoqjdZNeHdmg00k
S0tAJpub+kxAaVrVGxisN5x2r9DLd/HcRHPIGM5PDdQTtjRsl7pyXz5TVqlTijIp
SEBCQY0rKWVcgNmZuu57ARnpz50s/AqGf6VcgpQ4ZLwTVgHDNCCn6xWCJ0/z/cdC
KbgOFGWJTO9+bMmOXzprK0evntR93WNIBfCPBDbzypsr5tHkFuuBpLzGBQ5kVXNt
eM+LLNtSBnjyQIV57OqABtBBl7UhhRyU8OAE1lFJhMiNMHYJ4KA3sKVaDKIt+oTF
FMfrwzEonzLAf6OYeWskK13erG05fsfefnft0hopJZXvnoIGKCEo26qOxIHtjO6s
hK5+5fMxZxEluRb5/uEEndC5s6wPNNzpIWt5gdqV08IGthlJ/b0=
=F1gf
-----END PGP SIGNATURE-----

--Apple-Mail=_DF84599D-DE45-48E5-BB04-B8E9AAB053B5--


From nobody Thu Mar 14 15:12: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 DEA0C12426A for ; Thu, 14 Mar 2019 15:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbLnxdIE-yz6 for ; Thu, 14 Mar 2019 15:12:39 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0954B12008A for ; Thu, 14 Mar 2019 15:12:39 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id h8so4928976pgp.6 for ; Thu, 14 Mar 2019 15:12:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=UvQ7KoGkrph5KM+fJWKdhkZ4pmz4XB+rciHJ933IxOo=; b=iOGjYemLltaXcWxRc9O5zONIFIccy2iZ42eeWIW5SPZjoK5+4zIcbBlmtWEqtZdJA3 seR2Ahqi45k6qz9bxUuykM85v49qJjWxCL6rkDfbOGsCIQceCmNybx9fN/DD5eQICoXU nC+l09/ZwgSuweoPbGvI4BLWLWgWShLeKhv0GktnslVQfVT7uMnegKBRO/T48uO4HVrr bFrFfJZw8d7zwcocJZyy+MUEy9oU220iTZ/p1qTzWWif+NhTppd5jg8uAEhfQUEJ6Eac Uz1lw6HUo6H4Gdwknyc+n3JNN4C2oYCJPxRl+BxyFnC4PBdIVT84xjPrU5F3FnIreqTg SUow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=UvQ7KoGkrph5KM+fJWKdhkZ4pmz4XB+rciHJ933IxOo=; b=XFEi0pbqd+DHQg3OJoTeG1Uk5eglm+Oz9Xw1CE5b3u/odLI4Vi7p2k8d/m0jP0+vjZ trImCX30BanngndVyIUK7am8mMStIN8QR47FY8Yi8CYcwkiR+dFVtIq4hJUubiPCRB1T WuztPV6nG98zmqcgBTno/Reih5z3m/1vLoBwGo1Rd43zyy0zosOfR8+hPlYLeQwvRzfD xQ/+2Mzin0qg5oRTlIJ9kPdY18PHdaKQyoqScGcYqGiEUuRJgxSRoSMjUAQetSwTbQHr L4w2qi1nBUFryq08D8cfG9kde+R1FTmnll4nnpg5UINUWcSezb8AcTQAbmbW+H1fO9Ah MEfA==
X-Gm-Message-State: APjAAAWw0Cq+/EKX//yyHuzK3KwGPVEeN8RLPXa+tGCdv2hC/ZU/tqe7 ciM8w9TXTSwbLDmcB78IlHBycGhUgig=
X-Google-Smtp-Source: APXvYqyoMP8+sqjMfLQImOttpukYmjwrs2zFImhp/Rnuvn9ANkMMwaCIBOzj26bWT/qA9RsVdFdo5A==
X-Received: by 2002:a17:902:54f:: with SMTP id 73mr651260plf.210.1552601558336;  Thu, 14 Mar 2019 15:12:38 -0700 (PDT)
Received: from [192.168.128.100] (ai126149041041.54.access-internet.ne.jp. [126.149.41.41]) by smtp.gmail.com with ESMTPSA id d5sm272767pgv.20.2019.03.14.15.12.35 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 15:12:37 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_CED98F62-77F5-4F14-8393-01074B6BB3C7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Message-Id: 
Date: Fri, 15 Mar 2019 07:12:34 +0900
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: 
Subject: [v6ops] Thursday afternoon
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 14 Mar 2019 22:12:41 -0000

--Apple-Mail=_CED98F62-77F5-4F14-8393-01074B6BB3C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The meeting is scheduled for 13:50 Thursday afternoon. We have a posted =
agenda at =
https://datatracker.ietf.org/meeting/104/materials/agenda-104-v6ops-00. =
Ron will be in a conflicting meeting, so I will be running it solo.

We need a jabber scribe and someone to take notes during the meeting, =
please.
=
--------------------------------------------------------------------------=
------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu


--Apple-Mail=_CED98F62-77F5-4F14-8393-01074B6BB3C7
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+AFAlyK0dIACgkQEhdRnd2G
P+BpZg/7BS42sQTeIVjE8Xq+pptknbBH5qWSMwuYo2KC6W/ODJNH01jNt+53M+bF
k0KLwbp0LzBSua1bnPqfNQiKwBZK8HsfgjExUmKWT+bTbI2bnQD8Ii0PynY+etxq
/SqmL7tKe8YG3/9De35mCsZ/0LwGQC6cl+63dhqb3qw0mwqHkwNh26ODj9rd/8rz
/IXJ582B5MrAM/q51aJe/B9KXd5CQYro2hGI0s4KIeeIXsfg5NTfVXrZJuZ4oL9l
ZJHxKfrJ613FZoAySAnGmfRK/Du+VT1XjlEZiMXwZzGw5v48CXHTrEfuWPnCkYVm
PtU4ZTM7TaGwhHsmhFuogJ3JqpqCL8NtSEd5p5xUh1vCmavryJbOhMNLptdsc75e
lK1aPlwJGah05mchpYa6hXs+2wG/Ks233AnbSvyCei91uWIzISdqdn5HntyPPzjn
eIWRxfHYfuVIZTRseuw7ammyvvNTy9cxQuwju4ux8zagBwT7WGLL9Rc6SMYxnRhZ
C+ac7gak9JWr57b8sILrPemXdKReqn+/hE4eNqdfP1BAZvrMXZEIusLIlgJoYpF/
iu7Npr/m9EDP7ewVAGh7+GdMIaB8Te/XlI9Z+qaxlzXKF/PKlU/Ly6CPOsbu9HZM
BMM6fAsyzRu79b2n46p06UAiWjCHcL+U9ED1I7OuemcwxLb/k4o=
=xxkj
-----END PGP SIGNATURE-----

--Apple-Mail=_CED98F62-77F5-4F14-8393-01074B6BB3C7--


From nobody Thu Mar 21 07:18: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 93E9712798E; Thu, 21 Mar 2019 07:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdxTYhnHO_JG; Thu, 21 Mar 2019 07:18:06 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 D244B1277C9; Thu, 21 Mar 2019 07:18:05 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id w5so1518811qtb.11; Thu, 21 Mar 2019 07:18:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=EOly4+0y3aI+uZAkeKYfrv4ndyCGyBjabGI3/rV9BHo=; b=lFWcevfp/FCnfVPFRSyfU7Z62vY2WcKBJ2O9RIzeY0vR1/ehxKbvtY2JLYWukkGU6B SpZqOL4AW59WeahbIgakAXKpuMiZ0kqHFnePbGRZAS5DbatIaSpWOeCWuRxQIEX8nXG3 sh1W00MV9bS0Wcv83yxkfQYcRW2ZPjpf5IOuJALucsK1BoqIOV60OXZoCjXNAjGtPzcO A7TSU58hx3CKTXsdPTjj3HRGRryIAtWAPCWFWTQVECXpc0rdXzSYG76T6AYYCrZ6CoL/ X0rF2vXgVzK+Wf5jxIqXDNtaKHY+J/iZt+LSOawr80My3NPsExZmZ74IPDOV6iWDPDb0 tFjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=EOly4+0y3aI+uZAkeKYfrv4ndyCGyBjabGI3/rV9BHo=; b=n+3vOXG/TwiU2I6v+TlXmaNToEjgr8xoNWfY9TfKLOvglAwzX/eT894n2uf5JG15Qw /b7NgMYMZITvXtbm38AQtznJsnHuZVkOkiIMhuJqwI1Fjz2QQWx84QMWevpkPBdJXy2a c8NWqBFFkqDCmW0Y6BPWyx8qgXclUfSg2et/ItgO4AekPNcBE+bO5u5juqUutE6RPZmd RmfHI4c8qjIMCq3CqZELXbgSWht6N76yu1D08GX6vYrCuAlhHdme81dBiK8BlWj+jrwd OO77iGhrFZjHmmD4FEc2ig11GuYyCDpS5yPmuismVKdiOPDI4T3fNVhyqZaL77531AKa wlIg==
X-Gm-Message-State: APjAAAXTRs+xcBSdbA8QVIbO/BfVPr0TDuwJxDegHUx+dhXuk+dN3zES ucr0d7In+7e77dtwHcKdqryXhZCm9cAGoBqhdtriPk9t0Z0=
X-Google-Smtp-Source: APXvYqwV+6iFqyS3+MBXY+3m4tAPF7ouOPbnqL+h5QueALkPLbrnYe07s8psww89JFMR126r4dyFKT0iCPlkErVUtDU=
X-Received: by 2002:ac8:3f62:: with SMTP id w31mr3331578qtk.342.1553177884783;  Thu, 21 Mar 2019 07:18:04 -0700 (PDT)
MIME-Version: 1.0
From: Tal Mizrahi 
Date: Thu, 21 Mar 2019 16:17:53 +0200
Message-ID: 
To: IETF IPPM WG 
Cc: ipv6@ietf.org, sfc@ietf.org, v6ops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001878fc05849b68fd"
Archived-At: 
Subject: [v6ops] IETF 104 Side Meeting: Operational Aspects of IOAM
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Mar 2019 14:18:08 -0000

--0000000000001878fc05849b68fd
Content-Type: text/plain; charset="UTF-8"

Time: Tuesday, 18:30.
Place: Tyrolka.
Details:
In this side meeting we will discuss some of the operational aspects of In
situ OAM (IOAM). While the specification of IOAM is in progress in the IPPM
working group, including a wide set of features and encapsulation types, it
is likely that in practice IOAM will be used in a few common deployment
scenarios, potentially using a subset of the IOAM capabilities that have
been defined. The goal of this meeting is to stir up discussion about the
deployment aspects of IOAM, including potential use cases and deployment
challenges.

We would like to solicit operators to come and share their thoughts. If you
would like to present some slides - please reply to me off-list.
Other interested parties are also welcome, of course.

Cheers,
Tal.

--0000000000001878fc05849b68fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Time: Tuesday, 18:30.
Plac=
e: Tyrolka.
Details:=C2=A0
In this side meeting we will=
 discuss some of the operational aspects of In situ OAM (IOAM). While the s=
pecification of IOAM is in progress in the IPPM working group, including a =
wide set of features and encapsulation types, it is likely that in practice=
 IOAM will be used in a few common deployment scenarios, potentially using =
a subset of the IOAM capabilities that have been defined. The goal of this =
meeting is to stir up discussion about the deployment aspects of IOAM, incl=
uding potential use cases and deployment challenges.=C2=A0

We would like to solicit operators to come and share their thought=
s. If you would like to present some slides - please reply to me off-list.=
=C2=A0
Other interested parties are also welcome, of course.

Cheers,
Tal.


--0000000000001878fc05849b68fd--


From nobody Fri Mar 22 13:23:45 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F6412AF7A for ; Fri, 22 Mar 2019 13:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l42Y4s20CVjq for ; Fri, 22 Mar 2019 13:23:41 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 AA8D9126C87 for ; Fri, 22 Mar 2019 13:23:41 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id a22so2231375pgg.13 for ; Fri, 22 Mar 2019 13:23:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=u26I2STDwSf1BdlnC+NmOCcDuwJinBZKnycSG5/lZLk=; b=C62bcEqqQE0XrrxndU7h8payF+24TB2XpUuTf/7kafHeB1K/5wdzGL7vrZhKqXFSHg 8cQdvfvasIyGESjJ0DxV4VJzs1iWAxIAMDuqN7eLK7vt7pgcsoVZnqqA113fIm4WmDBH mPo/Gl5jMnL8+1CgLdFT/bvhgpAIF/XQgQauq3vEs0VXDzKJB8uCUYsXifUd3YevLguO Aq8LiTU+IaeGL4sF2eDJ606o8H+UopGCwykF7hKXEKgHw20a2n/IqXf2cKNPpPx4Zx3a PPRoZvGb3MCxLJrf+cxtlbu1C0No8VjgMxIduxxLd5DRywqFMastYwFV5qYpj+oNEDQo KJvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=u26I2STDwSf1BdlnC+NmOCcDuwJinBZKnycSG5/lZLk=; b=k47uu8ssvuqDq+0yZjFOkjIgUwy/GnduC3mTxVkmL7/1R0rkKHYY7bNW4p4YrXSj28 ALRLHnlD+Fy+jBfpQ08KpX5hKBaM+CCN1LhjNwwHRFCqYV0XJeb49ebCzPR0GI7elhz5 V+BB+9gCqHMTRgwdDMOa7Y/wsw/A/W+6rF1u5+xpAIU66P9CLnV4jixYOcQzUJCHcEr2 MDJNwYAiskaE7Rcy2RkSJ6ndEEMZrZWGrpA/8iMl9NaHGjZaatP47zkRKTgOjOi/WqnB 2d71AQ9wCb4V3cZ2kst/clG3c2X6k7nnrHvKS6IWk4CLpJQzorHt7jXl1yxHM8QSYMfP vXDg==
X-Gm-Message-State: APjAAAVkjwAARkqPf8/7SnNFaW9LG/h319ZljEwDkbMBDkp8N2Tr/PTQ AYj5+fNhxdFsrAAKU6ENb2+xZpiG
X-Google-Smtp-Source: APXvYqwSuGr0a1chnsmied/VlrMzQRgr4tVoZ66kRrffccDJmkbzl3OgbEs/Xogi3VTmyYXlL3WUpw==
X-Received: by 2002:a63:145b:: with SMTP id 27mr10616919pgu.74.1553286221140;  Fri, 22 Mar 2019 13:23:41 -0700 (PDT)
Received: from [172.26.32.242] ([76.14.1.154]) by smtp.gmail.com with ESMTPSA id b6sm9959817pgl.49.2019.03.22.13.23.40 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 13:23:40 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_B823BF7E-7C60-4F4B-B68D-DE7F2F64170F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: 
Date: Fri, 22 Mar 2019 13:23:39 -0700
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Functions needed 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: Fri, 22 Mar 2019 20:23:44 -0000

--Apple-Mail=_B823BF7E-7C60-4F4B-B68D-DE7F2F64170F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

We will need two volunteers for v6ops at IETF 104: Massimiliano Stucchi =
has offered to take notes, but I still need a jabber scribe. Any =
volunteers?



--Apple-Mail=_B823BF7E-7C60-4F4B-B68D-DE7F2F64170F
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+AFAlyVREsACgkQEhdRnd2G
P+A3Tw/8CiMtmIvJeS3XImyIQGeAsgZQXPg9SpsfoDrdr448vj8iMuZJRwSSN0ft
hk3UaQXhHkTi0gnVOJIAH/1rR7ZanSFYyU9XAC35I96ZkelZeSBxTdzt5ivaYCFe
f98c7CiHC72W175mShHjNOnziLhyF7Azvn+7v0TwyBvQbCmaULTqwqQjrBT9f201
fy63W99h16JLKnOK1RlQuDlfNECGzALVqhQcr0w+fP+OtG2qMm73RVL1jhq+7z64
tIqc7K9UCo/bYDIAqn7zmCDTya5JJClWtlunwtpPtfaE1zHJVtpwcrLDexON7oT1
Jaj/whILuBUNwKSIGOWDp83KVEp7UDPatdn1JozEHch9+ua5C/mLe50WBBf9cYex
TDJXmC1TJ++naRyDvwECOcGRywp0UH2K3WUFQWcmwo7B6ZB5iLkKsYjcfOUIEoBk
OR0qrIAMG2WoqB6oGtEgCBHKgucbF8bnzgyjFHt9/z7bvvUevgBpW54pi0aCcOse
IlEAWwq+84mlw4AoIx0XGya3tKH3yhc0SiuvkbPJILXwutE85r8Ar2+imdNvVVEb
4pAl8tggc4y4Lk/z8BzFvSw+y7Vm6nq5VofoEY2y26JBZjHP/nKtb6PElOnDqG6V
Qq/gaLuXFiieUOklymXzyOqqR4hg6G2MO3U3+/LoMW1sUb1yMeA=
=uTYQ
-----END PGP SIGNATURE-----

--Apple-Mail=_B823BF7E-7C60-4F4B-B68D-DE7F2F64170F--


From nobody Sat Mar 23 00:59:56 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8BD1279B0 for ; Sat, 23 Mar 2019 00:59:55 -0700 (PDT)
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 OTbBbQgLf6B0 for ; Sat, 23 Mar 2019 00:59:53 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A7912785F for ; Sat, 23 Mar 2019 00:59:52 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 54C1BB0; Sat, 23 Mar 2019 08:59:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1553327989; bh=IMpDVXfbUP4ojiTOU7TZfLcoIREk41pM+J4jirYrBro=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qmLHuW5AN6CWWH4Wuvza0fP6Q3P24uZQ21yjtM0TiChA9VNTYJh1p7Az5JdXG8heT YxlM8HxKsCi/wWTSUojeHHYozHCo0hSB9mXehjK0xE5jQrbXn6bU/gHNZIO5HEzOB3 LiyBi1DAyUy5keukcflxMvSoda8NRflG6B9/LEbk=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 52BA5AF; Sat, 23 Mar 2019 08:59:49 +0100 (CET)
Date: Sat, 23 Mar 2019 08:59:49 +0100 (CET)
From: Mikael Abrahamsson 
To: Fred Baker 
cc: IPv6 Operations 
In-Reply-To: 
Message-ID: 
References: 
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] Thursday afternoon
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2019 07:59:56 -0000

On Fri, 15 Mar 2019, Fred Baker wrote:

> We need a jabber scribe and someone to take notes during the meeting, please.

If someone can jabber scribe while I am doing my presentation, I can 
jabber scribe the rest of the meeting.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sat Mar 23 02:41:45 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27BE12D4F2 for ; Sat, 23 Mar 2019 02:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=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 tpjXSxckmBLK for ; Sat, 23 Mar 2019 02:41:42 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 46188127AC2 for ; Sat, 23 Mar 2019 02:41:42 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id l11so3134195pgq.10 for ; Sat, 23 Mar 2019 02:41:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=content-transfer-encoding:from:mime-version:subject:message-id:date :to:cc; bh=4yJfXTN/5/FCwY4k3yrc2KoKkFu3bIb34qylmz4uVEs=; b=cTIfBn3/89zpG4eH4we419cJPSGQyhp1xtvUYdR00dxtj2l8hkA/1LyeotvWGD+64m UvsiO+N2IiN4qTnr/MFHslL+EZ/f1hH5AAfQlpL9NvVGW+zAeMPQNwSQY0LRR3a1QFUp 9Un40SmER/DfAcWRpMvf1bE3Ps2pGU8EswnUErCxCbN/4lcL4c5/KVVmXg6FmG5vIkQj zdI+EO7i7rwBn2xQri5U9cUzEFw2CyWq4G9JprrAbMcj68zJTr6PHaCBpoQWfyMdd7Tb O6MEOCFlMPmW0C14wktFOpmOk8pMdMsKC80fY9pEC3Ul7baK2IcO+YWUtboATvOc3hEA z1uQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:to:cc; bh=4yJfXTN/5/FCwY4k3yrc2KoKkFu3bIb34qylmz4uVEs=; b=J9slGemLHCfDV/HHY3E/elPMgzTqQ2oRnHYImR1lLhfL6wpX9uQxGKqfrOG15D4A9p /z8a0W8Nc7HGd/Gbpo8pfdCDQDvruGwBuo5bj/+pFehso/5oYm8pxP5avkx2gwuv5YlR b+GCAlsjk8jA6Xcvv1tYg8cK47U5YozxEkBgXv7ie8gc4dMGp+FpYxgT6VW+MmodG/tF RuQOmkaBLL5hRP1n7+tUBhyeCTgZ5geOKCH86QvhJKK/a9A+iVMM+aME8hWOk/12v+cC 7tA5/SuZa8k16uhUdCYHSKE6N7i5Lt4hBHRmytthL//qTlrpg68QrlkbiMvTDc1WL/0s H4eQ==
X-Gm-Message-State: APjAAAWh79fd0GAkovZpZpf/Z+md1t1xz5xR8WzrpaGpHqdhSZ77KF3Q Z3V1QgZp3/UIjvjHaOJaO3u7s8Ro
X-Google-Smtp-Source: APXvYqxgnramwfXSx6SSu5JkiQ4Zrn/DzmyzD4OtrL3ur+rwMSrNY3dfhr6hH0pimNK36VOPm7JqSg==
X-Received: by 2002:a62:cd8c:: with SMTP id o134mr13590477pfg.84.1553334101719;  Sat, 23 Mar 2019 02:41:41 -0700 (PDT)
Received: from [172.20.10.8] ([172.56.30.24]) by smtp.gmail.com with ESMTPSA id n9sm10185292pff.43.2019.03.23.02.41.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Mar 2019 02:41:40 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Fred Baker 
Mime-Version: 1.0 (1.0)
Message-Id: 
Date: Sat, 23 Mar 2019 02:40:05 -0700
To: JORDI PALET MARTINEZ 
Cc: v6ops@ietf.org
X-Mailer: iPad Mail (16D57)
Archived-At: 
Subject: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2019 09:41:44 -0000

In at least two cases, you use the word =E2=80=9Cprecedent=E2=80=9D in the d=
raft. I=E2=80=99m pretty sure you meant =E2=80=9Cpreceding=E2=80=9D.

In one place, you also used an address 2001:db8::192.0.5.1 or something like=
 that. I had a case recently in which I Really Really wanted to use an addre=
ss like that, but as I understand the Addressing Architecture, it=E2=80=99s n=
o defined. ::192.0.5.1 is defined, and ::ffff:192.0.5.1 is defined, but usin=
g an IPv4 address in the IID of a generalized /96 prefix is not defined. I=E2=
=80=99m not sure what to do about that besides adding a sentence to the effe=
ct that the reader is expected to understand the intent in the example.

A little less nit-picky - you mention =E2=80=9Cforcing=E2=80=9D a client to r=
equest a AAAA record in some cases. Why not simply carry the indicated AAAA r=
ecord, whatever its address might be, as =E2=80=9Cadditional information=E2=80=
=9D in the DNS response? If the host is IPv6-capable, it has the option of u=
sing it...=


From nobody Sat Mar 23 03:07:45 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6956D130E30 for ; Sat, 23 Mar 2019 03:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 ZokUYUuwzCXb for ; Sat, 23 Mar 2019 03:07:40 -0700 (PDT)
Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0511293B1 for ; Sat, 23 Mar 2019 03:07:39 -0700 (PDT)
Received: from [192.168.1.119] (host-79-121-38-138.kabelnet.hu [79.121.38.138]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x2NA7U4g098403 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 23 Mar 2019 11:07:35 +0100 (CET) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-38-138.kabelnet.hu [79.121.38.138] claimed to be [192.168.1.119]
To: v6ops@ietf.org
References: 
From: =?UTF-8?Q?Lencse_G=c3=a1bor?= 
Message-ID: 
Date: Sat, 23 Mar 2019 11:07:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------79AB017EF702859308B9B7A4"
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.38.138; 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] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2019 10:07:43 -0000

This is a multi-part message in MIME format.
--------------79AB017EF702859308B9B7A4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Fred,

I think Jordi uses IPv4-embedded IPv6 addresses defined in RFC 6052. 
Besides the NAT64 "Well-Known Prefix" (64:ff9b::/96), one can use a 
"Network-Specific Prefix", please refer to: 
https://tools.ietf.org/html/rfc6052#page-5

So, IMHO, it is correct:

        EAMT entry                     192.0.2.1  2001:db8::192.0.2.1

Best regards,

Gábor


3/23/2019 10:40 AM keltezéssel, Fred Baker írta:
> In at least two cases, you use the word “precedent” in the draft. I’m pretty sure you meant “preceding”.
>
> In one place, you also used an address 2001:db8::192.0.5.1 or something like that. I had a case recently in which I Really Really wanted to use an address like that, but as I understand the Addressing Architecture, it’s no defined. ::192.0.5.1 is defined, and ::ffff:192.0.5.1 is defined, but using an IPv4 address in the IID of a generalized /96 prefix is not defined. I’m not sure what to do about that besides adding a sentence to the effect that the reader is expected to understand the intent in the example.
>
> A little less nit-picky - you mention “forcing” a client to request a AAAA record in some cases. Why not simply carry the indicated AAAA record, whatever its address might be, as “additional information” in the DNS response? If the host is IPv6-capable, it has the option of using it...
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


--------------79AB017EF702859308B9B7A4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Fred,

    

    I think Jordi uses IPv4-embedded IPv6 addresses defined in RFC 6052.
    Besides the NAT64 "Well-Known Prefix" (64:ff9b::/96), one can use a
    "Network-Specific Prefix", please refer to:
    https://tools.ietf.org/html/rfc6052#page-5

    

    So, IMHO, it is correct:

    
       EAMT entry                     192.0.2.1  2001:db8::192.0.2.1


    Best regards,

    

    Gábor

    

    

    
3/23/2019 10:40 AM keltezéssel, Fred
      Baker írta:

    

    

      
In at least two cases, you use the word “precedent” in the draft. I’m pretty sure you meant “preceding”.

In one place, you also used an address 2001:db8::192.0.5.1 or something like that. I had a case recently in which I Really Really wanted to use an address like that, but as I understand the Addressing Architecture, it’s no defined. ::192.0.5.1 is defined, and ::ffff:192.0.5.1 is defined, but using an IPv4 address in the IID of a generalized /96 prefix is not defined. I’m not sure what to do about that besides adding a sentence to the effect that the reader is expected to understand the intent in the example.

A little less nit-picky - you mention “forcing” a client to request a AAAA record in some cases. Why not simply carry the indicated AAAA record, whatever its address might be, as “additional information” in the DNS response? If the host is IPv6-capable, it has the option of using it...
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



    

    

  


--------------79AB017EF702859308B9B7A4--


From nobody Sat Mar 23 10:16:25 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30111277DE for ; Sat, 23 Mar 2019 10:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 M8H-pbltEEZL for ; Sat, 23 Mar 2019 10:16:21 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99DA1277CE for ; Sat, 23 Mar 2019 10:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553361377; x=1553966177; 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=i0TH6SrxYiHxwHeYvUx0hlOr+NlACHWt1XKfO26svGU=; b=cywHH8H+aIa2p 7ieBKlHuknw6y2eDVgrTFStmfWeyOe+DtNDofVnKG18+bxT/xe1WAvlXEILe7wro OKPrQ+0f/ICh+CNIWE06SaZRPpL+FhFZH7IsKB2RR1LLgN8xWi3eFRbzYaJdOSVo qX/krywrHHxXuFtrALX/L30shbaTqw=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sat, 23 Mar 2019 18:16:17 +0100
X-Spam-Processed: mail.consulintel.es, Sat, 23 Mar 2019 18:16:17 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006196046.msg for ; Sat, 23 Mar 2019 18:16:17 +0100
X-MDRemoteIP: 2001:470:1f09:495:1012:117c:9cb4:9684
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Sat, 23 Mar 2019 18:16:17 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1985af621e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Sat, 23 Mar 2019 18:16:14 +0100
From: JORDI PALET MARTINEZ 
To: Fred Baker 
CC: 
Message-ID: <6AED47A0-2C67-4142-97C6-9EE5397F9A2E@consulintel.es>
Thread-Topic: nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
References: 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2019 17:16:24 -0000

Hi Fred,

=EF=BB=BFEl 23/3/19 10:41, "Fred Baker"  escribi=
=C3=B3:

    In at least two cases, you use the word =E2=80=9Cprecedent=E2=80=9D in =
the draft. I=E2=80=99m pretty sure you meant =E2=80=9Cpreceding=E2=80=9D.

-> right and corrected in my internal draft-01
   =20
    In one place, you also used an address 2001:db8::192.0.5.1 or something=
 like that. I had a case recently in which I Really Really wanted to use an=
 address like that, but as I understand the Addressing Architecture, it=E2=
=80=99s no defined. ::192.0.5.1 is defined, and ::ffff:192.0.5.1 is defined=
, but using an IPv4 address in the IID of a generalized /96 prefix is not d=
efined. I=E2=80=99m not sure what to do about that besides adding a sentenc=
e to the effect that the reader is expected to understand the intent in the=
 example.

-> I believe this is correct, and actually Lencse explained it in another e=
mail (thanks for that !). I will include a note to explain it in the draft,=
 so it is more evident.
   =20
    A little less nit-picky - you mention =E2=80=9Cforcing=E2=80=9D a clien=
t to request a AAAA record in some cases. Why not simply carry the indicate=
d AAAA record, whatever its address might be, as =E2=80=9Cadditional inform=
ation=E2=80=9D in the DNS response? If the host is IPv6-capable, it has the=
 option of using it...

-> reworded it thanks ! I think this makes it:

4.  CLAT/DNS-proxy-EAMT-based Solution Approach
   If the CLAT, as commonly is the case, is also a DNS proxy/stub
   resolver, it may be possible to modify the behavior, so when there is
   a query for an A record, and there is not a query for the AAAA record
   from the same source, the DNS resolver can actually perform an AAAA,
   unless the information is not already present in the Additional
   Section, as per Section 3 of [RFC3596].  If the response doesn't
   contain the WKP or NSP, it means that the destination is
   IPv6-capable, so the CLAT can create/update an entry for an Explicit
   Address Mapping [RFC7757].

   This way, an EAMT is maintained automatically by the DNS proxy/stub
   resolver in the CLAT, and the CLAT is responsible to prioritize any
   available entries in the EAMT, versus the use of the synthetic AAAA.

   Following this approach, the IPv6-native path will take precedence
   and traffic will not be forwarded to the NAT64.






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

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Sat Mar 23 10:33: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 A79F712894E for ; Sat, 23 Mar 2019 10:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbKj6rqH6CO0 for ; Sat, 23 Mar 2019 10:32:59 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB97127963 for ; Sat, 23 Mar 2019 10:32:58 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id w10so5669035wrm.4 for ; Sat, 23 Mar 2019 10:32:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jNQprCQ2BQSVFGUZzvUMyP2O78kAD9YW1OKtgSXlwws=; b=tGnO99BtDt2mSh2RpOtg4kawPB+xbWB/HWcd5Mu32mR9Vhi2YW9VmLvtz6MpzIZbWu IJ0bBRO7AthNue7sgLzyik/jlcUVvcoVwrfXsIEOIg9ivsFJ2/6bUeUdS797nwRcmuh7 8u7qL6g+GTuYy2M/Hz2Lzgfo+Ipb3+yeurg9IN5lRZ/Qr98hAWDXt4y6vwGJ3DEQ+qMy yuMUsORg0ZtAzz9UquPN28RRDB4y+PAcKGqxiJmcLO1IZEsKz5VqR0e94ZpYdQqvhwF3 5Pn60ill9M2NZF0zeszNKmLAngBGYZLiqENJWky5zE/VTrDnQQd5AYqbin11b1f3oQda fGvg==
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=jNQprCQ2BQSVFGUZzvUMyP2O78kAD9YW1OKtgSXlwws=; b=RbyPdRc3miINpT2735U/21l/8aoLcfYhstqs2S12Ta30UNP8/22U/e5QbTRZWlELbE h4oBfOnImy0y/v/+VabboLwO3NkdB3jLZL/FKAxJzKCHMhwOtxuYqOzELQBaYoQPF7BV R+OG+EM3n8WZIkUbiWSKnN3pttJd9puz5sB24fFshqciSE7caK6v1xihSc6el6qoriKJ DaQm6rY9jZSEGAKHSupmEi1Ais5ACPfM1WXQe3Z37Vr00vrqvOPOUEa9Bbr5UWUEiQgp kE7IK1UfnmsAvnVXGz2yGSgredSsjvvE4Fnqe0FX97Z+KUiRRpj4bhbtbmp0MDfEgWL3 JJtA==
X-Gm-Message-State: APjAAAVgxerVEADHxOb3E1RZmbBxv1aVtFDH1Fa6vUf9rthwU0JGmYG6 3ruoYVujH1TrVr9FnTZmkBo=
X-Google-Smtp-Source: APXvYqw3mHCw765BD8mne5LTidddG8714p9S6RoG/t8KGS4t0gelShY4xSUVvH4QeDqO8w9vh1mIlw==
X-Received: by 2002:a5d:6889:: with SMTP id h9mr10414685wru.12.1553362377472;  Sat, 23 Mar 2019 10:32:57 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:55be:6cba:14ea:bdb5? ([2001:67c:1232:144:55be:6cba:14ea:bdb5]) by smtp.gmail.com with ESMTPSA id f128sm17822526wme.28.2019.03.23.10.32.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Mar 2019 10:32:56 -0700 (PDT)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_C71D029C-47BD-4B1A-A501-4D6DA7B5E485"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Sat, 23 Mar 2019 18:32:54 +0100
In-Reply-To: 
Cc: v6ops@ietf.org
To: =?utf-8?Q?Lencse_G=C3=A1bor?= 
References:  
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2019 17:33:04 -0000

--Apple-Mail=_C71D029C-47BD-4B1A-A501-4D6DA7B5E485
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Mar 23, 2019, at 11:07 AM, Lencse G=C3=A1bor  =
wrote:
>=20
> Hi Fred,
>=20
> I think Jordi uses IPv4-embedded IPv6 addresses defined in RFC 6052. =
Besides the NAT64 "Well-Known Prefix" (64:ff9b::/96), one can use a =
"Network-Specific Prefix", please refer to: =
https://tools.ietf.org/html/rfc6052#page-5
>=20
> So, IMHO, it is correct:
>        EAMT entry                     192.0.2.1  2001:db8::192.0.2.1
>=20
> Best regards,
>=20
> G=C3=A1bor

I don't think so. RFC 6052 lays out where bits go; yes, that's what =
Jordi intends. I'm commenting on the *text* in the document, not the =
bits the text represents.

Observe https://tools.ietf.org/html/rfc4291#section-2.2 and =
https://tools.ietf.org/html/rfc4291#section-2.5.5. It only applies the =
format to ipv4-embedded (IPv4-Compatible and IPv4-Mapped) addresses, =
which RFC 4291 deprecates.

Happy to be wrong; I called it a nit. But I want to make sure we're on =
the same topic before we call it an error...

> 3/23/2019 10:40 AM keltez=C3=A9ssel, Fred Baker =C3=ADrta:
>> In at least two cases, you use the word =E2=80=9Cprecedent=E2=80=9D =
in the draft. I=E2=80=99m pretty sure you meant =E2=80=9Cpreceding=E2=80=9D=
.
>>=20
>> In one place, you also used an address 2001:db8::192.0.5.1 or =
something like that. I had a case recently in which I Really Really =
wanted to use an address like that, but as I understand the Addressing =
Architecture, it=E2=80=99s no defined. ::192.0.5.1 is defined, and =
::ffff:192.0.5.1 is defined, but using an IPv4 address in the IID of a =
generalized /96 prefix is not defined. I=E2=80=99m not sure what to do =
about that besides adding a sentence to the effect that the reader is =
expected to understand the intent in the example.
>>=20
>> A little less nit-picky - you mention =E2=80=9Cforcing=E2=80=9D a =
client to request a AAAA record in some cases. Why not simply carry the =
indicated AAAA record, whatever its address might be, as =E2=80=9Caddition=
al information=E2=80=9D in the DNS response? If the host is =
IPv6-capable, it has the option of using it...
>> _______________________________________________
>> v6ops mailing list
>>=20
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

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


--Apple-Mail=_C71D029C-47BD-4B1A-A501-4D6DA7B5E485
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+AFAlyWbcYACgkQEhdRnd2G
P+DDOQ/9HHnhAlRilBpkg2aK93nQBs/pBeRDjDQNMU/iJMioSNJi/gWlvY1En7vo
il2JLJDF6xGmyjAUiPpOWtgN85vrVkPWdk88YdcG0qa7Y+xcmmu4Eh/mN5flrCtS
Md4BSB7OcK+VqU6Q95uIV05XD1RY6IRS6mjA8zE2lBh4Xm0L+SmlW8M/rwLCOIki
7SjrbbT+IWEEElgMriPLD1u+E8JL7nkGXJ/xb2PQlp+11vlVfUUvsX/YAGVfGKe9
zU7Rzf6Vhv6WXh1ggaDoTzTn+jqxJS/SD3I5j/L3QcEA16z+1ck4ojxEXqwXG7Hu
BwVw7AXTI/bHzFT0PZoEAbvjbrLlF+CqBWYTha6wGi1Yi24tCfNwliZH0KlTQIxk
05sYy40DFsXtF11bdW+yf/v/L3oMGY8rNQzbPZliXKGB2zk0KVuJ0s4ARbVE81Q7
4cDXYL7Rynrc0yolJu4WwpFCq9f8qcMmSylM4DEHmInFHrWL85/aQR0aFmTU7q+F
bzhB7yOval/M1z7LY3X4lePsQKIGhJTvUiLT1ody155p/EYbgrPrr6KA1jpDmYs6
K6yhj56WOj3xEM0nSDEfb2v9N7UE9e615keLYmxQxXL0d2f2E39ggUvdjyIaxn4n
raRXp1sSh+8iVjbQlZXiAGP0+RPheyczC86i+Tk74c9u5UWM+EY=
=Y8aE
-----END PGP SIGNATURE-----

--Apple-Mail=_C71D029C-47BD-4B1A-A501-4D6DA7B5E485--


From nobody Sat Mar 23 10:42: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 E4E4D130EE7 for ; Sat, 23 Mar 2019 10:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 I6JDrAP0_R_g for ; Sat, 23 Mar 2019 10:42:17 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA01126DFA for ; Sat, 23 Mar 2019 10:42:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553362934; x=1553967734; 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=70ctD8C2uvTaldKh6Dpa4XPgB2Adc9fLt70vFBUW4NE=; b=THSWvaxNUpIZL S8tfPXmLQQBnDGC6W1R3ndTYxkTSBAye5nDVt/+CPdbz/icJgZv5Gu5WeKsVwAR6 tC2FdFX4RElDb7LDJeMx8ODrbhlC7tOV5eJidkUKeKANz8KqHA5aNSlUrmZ8+dx9 zK2IEPLr7bJNtf2AtmVcJiijgWZsLc=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sat, 23 Mar 2019 18:42:14 +0100
X-Spam-Processed: mail.consulintel.es, Sat, 23 Mar 2019 18:42:13 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006196070.msg for ; Sat, 23 Mar 2019 18:42:12 +0100
X-MDRemoteIP: 2001:470:1f09:495:1012:117c:9cb4:9684
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Sat, 23 Mar 2019 18:42:12 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1985af621e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Sat, 23 Mar 2019 18:42:11 +0100
From: JORDI PALET MARTINEZ 
To: Fred Baker , Lencse =?UTF-8?B?R8OhYm9y?= 
CC: 
Message-ID: 
Thread-Topic: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
References:   
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2019 17:42:25 -0000

Hi Fred,

After responding you, I decided to change it, because it may confuse folks =
with an NSP case, which is not what I'm describing.

If I was showing examples with the NSP it will be correct to use the RFC605=
2 format (it is still correct for the examples using the WKP).

So, I keep:

       www.example.com                   A       192.0.2.1
       CLAT translated to                        64:ff9b::192.0.2.1
       CDN IPv6 interface must be                64:ff9b::192.0.2.1
       Operator must have a specific route to    64:ff9b::192.0.2.1

But moved the other one to regular documentation addresses:

        www.example.com                   A       192.0.2.1
                                          AAAA    2001:db8::a:b:c:d
        EAMT entry                     192.0.2.1  2001:db8::a:b:c:d
        CLAT translated to                        2001:db8::a:b:c:d
        CDN IPv6 interface already is             2001:db8::a:b:c:d
        Operator already has a specific route to  2001:db8::a:b:c:d

Regards,
Jordi
=20
=20

=EF=BB=BFEl 23/3/19 18:33, "v6ops en nombre de Fred Baker"  escribi=C3=B3:

   =20
   =20
    > On Mar 23, 2019, at 11:07 AM, Lencse G=C3=A1bor  w=
rote:
    >=20
    > Hi Fred,
    >=20
    > I think Jordi uses IPv4-embedded IPv6 addresses defined in RFC 6052. =
Besides the NAT64 "Well-Known Prefix" (64:ff9b::/96), one can use a "Networ=
k-Specific Prefix", please refer to: https://tools.ietf.org/html/rfc6052#pa=
ge-5
    >=20
    > So, IMHO, it is correct:
    >        EAMT entry                     192.0.2.1  2001:db8::192.0.2.1
    >=20
    > Best regards,
    >=20
    > G=C3=A1bor
   =20
    I don't think so. RFC 6052 lays out where bits go; yes, that's what Jor=
di intends. I'm commenting on the *text* in the document, not the bits the =
text represents.
   =20
    Observe https://tools.ietf.org/html/rfc4291#section-2.2 and https://too=
ls.ietf.org/html/rfc4291#section-2.5.5. It only applies the format to ipv4-=
embedded (IPv4-Compatible and IPv4-Mapped) addresses, which RFC 4291 deprec=
ates.
   =20
    Happy to be wrong; I called it a nit. But I want to make sure we're on =
the same topic before we call it an error...
   =20
    > 3/23/2019 10:40 AM keltez=C3=A9ssel, Fred Baker =C3=ADrta:
    >> In at least two cases, you use the word =E2=80=9Cprecedent=E2=80=9D =
in the draft. I=E2=80=99m pretty sure you meant =E2=80=9Cpreceding=E2=80=9D=
..
    >>=20
    >> In one place, you also used an address 2001:db8::192.0.5.1 or someth=
ing like that. I had a case recently in which I Really Really wanted to use=
 an address like that, but as I understand the Addressing Architecture, it=
=E2=80=99s no defined. ::192.0.5.1 is defined, and ::ffff:192.0.5.1 is defi=
ned, but using an IPv4 address in the IID of a generalized /96 prefix is no=
t defined. I=E2=80=99m not sure what to do about that besides adding a sent=
ence to the effect that the reader is expected to understand the intent in =
the example.
    >>=20
    >> A little less nit-picky - you mention =E2=80=9Cforcing=E2=80=9D a cl=
ient to request a AAAA record in some cases. Why not simply carry the indic=
ated AAAA record, whatever its address might be, as =E2=80=9Cadditional inf=
ormation=E2=80=9D in the DNS response? If the host is IPv6-capable, it has =
the option of using it...
    >> _______________________________________________
    >> v6ops mailing list
    >>=20
    >> v6ops@ietf.org
    >> https://www.ietf.org/mailman/listinfo/v6ops
    >>=20
    >>=20
    >>=20
    >=20
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =20
    -----------------------------------------------------------------------=
---------
    The fact that there is a highway to hell and a stairway to heaven is an=
 interesting comment on projected traffic volume...
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://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 Sat Mar 23 16:24: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 2CF2A12D4EF for ; Sat, 23 Mar 2019 16:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Level: 
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_ECII3JngLl for ; Sat, 23 Mar 2019 16:24:44 -0700 (PDT)
Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F861277E6 for ; Sat, 23 Mar 2019 16:24:43 -0700 (PDT)
Received: by mail-wm1-f51.google.com with SMTP id z11so5462171wmi.0 for ; Sat, 23 Mar 2019 16:24:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8jByxwlxchboocUihgxTHlvsnpXBnLmDNETRi9FkkqY=; b=O9rpUNCbStef1SbxDeTk54LwKdsZW64gFrZHTRX1ZLLWfGY921WQHmxfNEWcJ4quZU uJ7yrEiDSSbXapXjzuujsJ1Sv1o9ct+5BAWbO+v4aI5A35U9dX4VvrBFRS877HhGePd1 gyrytM848YO87uV28IVkCzPaqjHlyuxyxG9jbWJ1k8CdpFdq6yxRXPUkELjjByrpymwN B8SJJYVSOAGKpzjCbKJhcn6sYzDSALRTp++st9xLFusCdKksZXL0zxJCW8kZ/fQr6Rrk 0iRJpDKFMRRFdp7wBs8f8d/HsEy84VTKyYtbR09H+qUX41o163Tt5fXhEY3eTwJHMAEo JxiA==
X-Gm-Message-State: APjAAAVPGss+02SuAzwn690ria7MVee7NaEXtz7J7PpZMQtMrlAxw50J /yZ5hdvzHTHn8J0H2I00tbfbDTw2W6yRQPUHJfw=
X-Google-Smtp-Source: APXvYqz4ozlVwowd9f3ydZuBydK7sPRRERFUesnO1XsyrRrXIN8CW7WyDX+57lagEcurssNgg7XnG9E/MA/643sm+WE=
X-Received: by 2002:a1c:44:: with SMTP id 65mr6569922wma.127.1553383482049; Sat, 23 Mar 2019 16:24:42 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Sat, 23 Mar 2019 16:24:30 -0700
Message-ID: 
To: Fred Baker 
Cc: =?UTF-8?Q?Lencse_G=C3=A1bor?= ,  IPv6 Operations 
Content-Type: multipart/alternative; boundary="000000000000a5c97f0584cb463f"
Archived-At: 
Subject: Re: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2019 23:24:46 -0000

--000000000000a5c97f0584cb463f
Content-Type: text/plain; charset="UTF-8"

At Sat, 23 Mar 2019 18:32:54 +0100,
Fred Baker  wrote:

> I don't think so. RFC 6052 lays out where bits go; yes, that's what Jordi
intends. I'm commenting on the *text* in the document, not the bits the
text represents.
>
> Observe https://tools.ietf.org/html/rfc4291#section-2.2 and
https://tools.ietf.org/html/rfc4291#section-2.5.5. It only applies the
format to ipv4-embedded (IPv4-Compatible and IPv4-Mapped) addresses, which
RFC 4291 deprecates.
>
> Happy to be wrong; I called it a nit. But I want to make sure we're on
the same topic before we call it an error...

I'm confused.  Are you saying 2001:db8::192.0.5.1 is not a valid
textual IPv6 address?  In my understanding that's perfectly valid
(probably quite uncommon, though).  I'm especially confused as you
referred to Section 2.2 of RFC4291... It states:

   3. An alternative form that is sometimes more convenient when dealing
      with a mixed environment of IPv4 and IPv6 nodes is
      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
      the six high-order 16-bit pieces of the address, and the 'd's are
      the decimal values of the four low-order 8-bit pieces of the
      address (standard IPv4 representation).  Examples:
[...]

Although the "examples" only show the case of x:x:x:x:x:x being either
0:0:0:0:0:0 or 0:0:0:0:0:FFFF, I interpret the above text as 'x' can
be any hexadecimal value.

And btw, RFC4291 does not deprecate IPv4-mapped IPv6 addresses (it
only deprecated IPv4-compatible IPv6 addresses).

--
JINMEI, Tatuya

--000000000000a5c97f0584cb463f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


At Sat, 23 Mar 2019 18:32:54 +0100,
Fr=
ed Baker <fredbaker.ietf@gma=
il.com> wrote:

> I don't think so. RFC 6052 lays out w=
here bits go; yes, that's what Jordi intends. I'm commenting on the=
 *text* in the document, not the bits the text represents.
> 
>=
 Observe https:=
//tools.ietf.org/html/rfc4291#section-2.2 and https://tools.ietf.org/html/rfc4291#se=
ction-2.5.5. It only applies the format to ipv4-embedded (IPv4-Compatib=
le and IPv4-Mapped) addresses, which RFC 4291 deprecates.
> 
> =
Happy to be wrong; I called it a nit. But I want to make sure we're on =
the same topic before we call it an error...

I'm confused.=C2=A0=
 Are you saying 2001:db8::192.0.5.1 is not a valid
textual IPv6 address?=
=C2=A0 In my understanding that's perfectly valid
(probably quite un=
common, though).=C2=A0 I'm especially confused as you
referred to Se=
ction 2.2 of RFC4291... It states:

=C2=A0=C2=A0 3. An alternative fo=
rm that is sometimes more convenient when dealing
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 with a mixed environment of IPv4 and IPv6 nodes is
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 x:x:x:x:x:x:d.d.d.d, where the 'x's are the h=
exadecimal values of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the six high-order 1=
6-bit pieces of the address, and the 'd's are
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 the decimal values of the four low-order 8-bit pieces of the=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 address (standard IPv4 representation).=C2=
=A0 Examples:
[...]

Although the "examples" only show t=
he case of x:x:x:x:x:x being either
0:0:0:0:0:0 or 0:0:0:0:0:FFFF, I int=
erpret the above text as 'x' can
be any hexadecimal value.
And btw, RFC4291 does not deprecate IPv4-mapped IPv6 addresses (it
onl=
y deprecated IPv4-compatible IPv6 addresses).

--
JINMEI, Tatuya


--000000000000a5c97f0584cb463f--


From nobody Sat Mar 23 19:22: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 449CE12958B for ; Sat, 23 Mar 2019 19:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 (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 oVM9OYG9Y3t7 for ; Sat, 23 Mar 2019 19:22:38 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1055F1277E5 for ; Sat, 23 Mar 2019 19:22:38 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id g8so4069844pgf.2 for ; Sat, 23 Mar 2019 19:22:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BVPXgiBhLHFK+ofivDK4KXvu346bsokeUFQ1iYgLJOU=; b=DOqIwbu9WQ+/17IAD9DgGSvqixpaghvOzar08O9+5pWWARty6jlA+r2A9f/6/3kT+j 0YtA/aSS4GlehYZRWdljs2c/DoFXuAR7aGrx0Xs8n09mvbX2yLbF+ZJ8X3XXjH74MlSl 28tk/TfGmKAyoeOI99n4zyriCQz2sdTR6VdsiwBEfa9eizrssWaIQjUZVFWw6bdwya3c +t58eJ11Vp7wUtsKePdPIHZweYD3Sreq+TJT157CpO3n9cAg0OTDLSLWFEif4yceMOxq YnG6NtKvdtzCCY0pMWosz/xbFT3Iv/kvmqdNum7F8WjqDYlrQyZphMGjdGWgk3NnLikI SvBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BVPXgiBhLHFK+ofivDK4KXvu346bsokeUFQ1iYgLJOU=; b=hRB1MOHaTxorOXPwKKgPcy0SUHEpn/HaN4oI+QXziiQRqc9kQF8UU6Tv/jRpUO1ooS UzIc8LDlWjURIjTgZRQcgX5YLZIsbV0FR0pPWNfy9za45l39amXyKhta0byPpPuxYrYW +mUXcxfSS/leL44QDi6pR1tWJu7FBC+YIjHRGDg5sdT8+EglFAkNkEdJTHEPS/GcmMdN RXG3qWb2wyInb8t06rJANlbDMDcVBVK5SqwX7mJcclfn4J/e2bBYINAx+WglFQ9ux2nD LYlEHLscqKGTvM4U//PLHsumoYGjwUG6zHeNLHhmvSiepbInjLgTir/hn/Ftj7AZnU/L KibQ==
X-Gm-Message-State: APjAAAVTanYzucSrNRbmsz7WZfg/qamijdWZYJz+djQvhFCt6NrUR0Oj 0rUiBpSMMJizPOELfyWtnk8Fvq6T
X-Google-Smtp-Source: APXvYqxGZzHqKmYZtSmZ8WrHT//IDUVPkWkVcTXtHUO8sb7gaLCgaYApue8RNIST2JoEYsrZsMHlMQ==
X-Received: by 2002:a17:902:bd90:: with SMTP id q16mr11638653pls.162.1553394157290;  Sat, 23 Mar 2019 19:22:37 -0700 (PDT)
Received: from [192.168.178.30] (211.231.69.111.dynamic.snap.net.nz. [111.69.231.211]) by smtp.gmail.com with ESMTPSA id c2sm24737524pfm.187.2019.03.23.19.22.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Mar 2019 19:22:36 -0700 (PDT)
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Fred Baker 
Cc: IPv6 Operations 
References:    
From: Brian E Carpenter 
Message-ID: <8b418ebb-6ad3-6be5-b4e2-499a5dcd138d@gmail.com>
Date: Sun, 24 Mar 2019 15:22:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2019 02:22:39 -0000

On 24-Mar-19 12:24, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote:
> At Sat, 23 Mar 2019 18:32:54 +0100,
> Fred Baker >=
 wrote:
>=20
>> I don't think so. RFC 6052 lays out where bits go; yes, that's what Jo=
rdi intends. I'm commenting on the *text* in the document, not the bits t=
he text represents.
>>
>> Observe https://tools.ietf.org/html/rfc4291#section-2.2 and https://to=
ols.ietf.org/html/rfc4291#section-2.5.5. It only applies the format to ip=
v4-embedded (IPv4-Compatible and IPv4-Mapped) addresses, which RFC 4291 d=
eprecates.
>>
>> Happy to be wrong; I called it a nit. But I want to make sure we're on=
 the same topic before we call it an error...
>=20
> I'm confused.=C2=A0 Are you saying 2001:db8::192.0.5.1 is not a valid
> textual IPv6 address?=C2=A0 In my understanding that's perfectly valid

I agree. It's just another way of writing 2001:db8::c000:501

    Brian

> (probably quite uncommon, though).=C2=A0 I'm especially confused as you=

> referred to Section 2.2 of RFC4291... It states:
>=20
> =C2=A0=C2=A0 3. An alternative form that is sometimes more convenient w=
hen dealing
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with a mixed environment of IPv4 and IPv=
6 nodes is
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x:x:x:x:x:x:d.d.d.d, where the 'x's are =
the hexadecimal values of
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the six high-order 16-bit pieces of the =
address, and the 'd's are
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the decimal values of the four low-order=
 8-bit pieces of the
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 address (standard IPv4 representation).=C2=
=A0 Examples:
> [...]
>=20
> Although the "examples" only show the case of x:x:x:x:x:x being either
> 0:0:0:0:0:0 or 0:0:0:0:0:FFFF, I interpret the above text as 'x' can
> be any hexadecimal value.
>=20
> And btw, RFC4291 does not deprecate IPv4-mapped IPv6 addresses (it
> only deprecated IPv4-compatible IPv6 addresses).
>=20
> --
> JINMEI, Tatuya
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From nobody Sat Mar 23 20:49: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 0AEB0130DD8 for ; Sat, 23 Mar 2019 20:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQQSqk14SzZN for ; Sat, 23 Mar 2019 20:49:13 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE29A1279A3 for ; Sat, 23 Mar 2019 20:49:12 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id o25so5612841wmf.5 for ; Sat, 23 Mar 2019 20:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cWG1hFt+XwkaDnzdMr3KwMKPtdR4yb310kOkfc09+FU=; b=aEJZeubjiGLzNPL81G5CdXmXToXaD7E/GDn6zHreCz51ftcsUoGTO/6eTaV/Npltbm x3g7eYETnTtKda0Ayho1UUdFTWmAfA2tArFKqot1K92kBcAeIRTtAlklz2FDIu6acTRv oH8PWFlHKESl93YE7xeAJkLoXgugaKltP+t0imKMUIErl4iDBLBh/LpnT/CoT4Q9lUks PW6EJ60ekshbwDv1enPdunbcd/QJXjRrYmfuBfPcJUNqwIAppZtxd/g+/Aj7ooduYD1u 67RgPretV8JC1gN9Yj46cgktt+91Ljviz+a3cxxxCCFUr9KaMf9bqBi086zpG4hDJEqj eG4w==
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=cWG1hFt+XwkaDnzdMr3KwMKPtdR4yb310kOkfc09+FU=; b=KhDIXosw+bUsgO8/irzsBge7d1/Bj1KDuDEU8dRKQPo39zFt7NksfRQBg8u7TPBYVe HdWBlbeieMknma7KeszEGP2xkhseLCVGFvX8khGmZST/LfuHsNkc3coc0nWZa+pwHQNW kgM4NHNcqTgTmewX5JhnpAN7+0RUHxZuMhIRP3f3c3VyAqVdZ1g1Tj6SQXW6Jqh23bLO xMLf5P4qE9mtvKMa2WNDhXczXQgBQ1GXNZ5DX71R4sVrmVZFb69gqQHDcxe1lcWxEBjd N23NrRo1xydLlaXFmrIJrM6f13uhNL6jVsI+IMLBSxqgFM0HTctQKBh/E67FIY2jCNvs SEgg==
X-Gm-Message-State: APjAAAWH1xR9AULDi9Finxe/kaKHG6Dg7GsVFtuSebEVtCwbGqAJWmc3 j0cbG/i8+qiD0VMc6G03YSU=
X-Google-Smtp-Source: APXvYqy+I+7kf7y2bPP2oYfaXOFzaXuUNQCqabLGKUvhJNJ0j2AY2N27wjOpVo4oguQ36gbAMtGBLA==
X-Received: by 2002:a1c:cb0f:: with SMTP id b15mr7268801wmg.88.1553399351408;  Sat, 23 Mar 2019 20:49:11 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:55be:6cba:14ea:bdb5? ([2001:67c:1232:144:55be:6cba:14ea:bdb5]) by smtp.gmail.com with ESMTPSA id 3sm15593873wrk.68.2019.03.23.20.49.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Mar 2019 20:49:10 -0700 (PDT)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_E23A8D1F-0E50-4314-BD09-5639CCCB21EA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Sun, 24 Mar 2019 04:49:08 +0100
In-Reply-To: 
Cc: =?utf-8?Q?Lencse_G=C3=A1bor?= , IPv6 Operations 
To: =?utf-8?B?56We5piO6YGU5ZOJ?= 
References:    
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2019 03:49:16 -0000

--Apple-Mail=_E23A8D1F-0E50-4314-BD09-5639CCCB21EA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If I'm wrong, I'm wrong.

> On Mar 24, 2019, at 12:24 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 =
 wrote:
>=20
> At Sat, 23 Mar 2019 18:32:54 +0100,
> Fred Baker  wrote:
>=20
> > I don't think so. RFC 6052 lays out where bits go; yes, that's what =
Jordi intends. I'm commenting on the *text* in the document, not the =
bits the text represents.
> >
> > Observe https://tools.ietf.org/html/rfc4291#section-2.2 and =
https://tools.ietf.org/html/rfc4291#section-2.5.5. It only applies the =
format to ipv4-embedded (IPv4-Compatible and IPv4-Mapped) addresses, =
which RFC 4291 deprecates.
> >
> > Happy to be wrong; I called it a nit. But I want to make sure we're =
on the same topic before we call it an error...
>=20
> I'm confused.  Are you saying 2001:db8::192.0.5.1 is not a valid
> textual IPv6 address?  In my understanding that's perfectly valid
> (probably quite uncommon, though).  I'm especially confused as you
> referred to Section 2.2 of RFC4291... It states:
>=20
>    3. An alternative form that is sometimes more convenient when =
dealing
>       with a mixed environment of IPv4 and IPv6 nodes is
>       x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values =
of
>       the six high-order 16-bit pieces of the address, and the 'd's =
are
>       the decimal values of the four low-order 8-bit pieces of the
>       address (standard IPv4 representation).  Examples:
> [...]
>=20
> Although the "examples" only show the case of x:x:x:x:x:x being either
> 0:0:0:0:0:0 or 0:0:0:0:0:FFFF, I interpret the above text as 'x' can
> be any hexadecimal value.
>=20
> And btw, RFC4291 does not deprecate IPv4-mapped IPv6 addresses (it
> only deprecated IPv4-compatible IPv6 addresses).
>=20
> --
> JINMEI, Tatuya

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


--Apple-Mail=_E23A8D1F-0E50-4314-BD09-5639CCCB21EA
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+AFAlyW/jQACgkQEhdRnd2G
P+BpUxAAxf161sG68+efD8sHtOl7uTATBc0Qy2RyoZ7ZiTtp9cB1oftgr0xYkP/a
g888kIDw6Cg3lntfwkBGbB2luOaSHpIB+0G7wvUdl9TZZLpQeJ1T5kSHVFype1Sk
cOKSf1+jj4DxJEwqRni7JFGh/9phoV5lzyP3AZBcpqOFfLZwGcxj/DWlOTIJ6P8s
6NIa/MHpBqNkgyIiBFoubvPU60b8PXh8GCvHXDSPidutzFBTAB++qEc+E1ORaf/R
0zZ+r5e39P/bHBZWajidmpeuJDvvqTTq1DbwSLxd8OVNsUy9LjlhVKnFgdeqfFO8
+QliW+tnBvliXfT3714DY0xhETbJ9D8b+m265xo2Go97FcZUqqJpoXyM7ltiWOci
t8teALiFWNmaTwHo29JG+BeGivt3TESjSKO1MMdMH5R2hcmRBCvT/Kc4JzdFUKGQ
di7M91VKZMQB24clkmlGr3L6Wz9aq9yQN9cZcFkPs7gT7T3S+Lg4ij34aqmS+7U8
bD00LNojqhL/baZbmLqbSg8PORNwrJAh9y9H0h/i8hyxYY7Qo0bTZwkGGWnMEjNE
QQoxUt3SKdsHsMDxF8gEP0PKGQdGr2b5AyhdPek+bY69QxoOZOs5nRtJtHUx5eSO
fPnr69lrunFdWKlFeSTgcIEp1thCV8kHY0RC4+x60VepYX80+gk=
=/xBM
-----END PGP SIGNATURE-----

--Apple-Mail=_E23A8D1F-0E50-4314-BD09-5639CCCB21EA--


From nobody Sun Mar 24 00:25: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 2FDF112796B for ; Sun, 24 Mar 2019 00:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofY_eya0NmJr for ; Sun, 24 Mar 2019 00:25:53 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778471277D8 for ; Sun, 24 Mar 2019 00:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553412350; x=1554017150; 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=FLLl2DQLCuENQytzgFX99+Jm0UOD6E7ef0 Z/jzZDLOs=; b=iQUtqDTAzVcNmsJP+0ekMOiQPnL1icYEuq3HgUzWKHjcKVbSWl jk9+qv8emyaS2gacpVV4ZpTXg1KyvQHs/bhD8vTn+z9DxlbAL/lWhrqgN/pt4hWP bi6o7xmljrJulORB6XOiV84OJsoMpFmpwY3jOg8cTrHt+OE6u/l2u1c58=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sun, 24 Mar 2019 08:25:50 +0100
X-Spam-Processed: mail.consulintel.es, Sun, 24 Mar 2019 08:25:50 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006196612.msg for ; Sun, 24 Mar 2019 08:25:50 +0100
X-MDRemoteIP: 2001:470:1f09:495:c453:1fd9:d8e0:6431
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Sun, 24 Mar 2019 08:25:50 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1986a4697c=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Sun, 24 Mar 2019 08:25:49 +0100
From: JORDI PALET MARTINEZ 
To: IPv6 Operations 
Message-ID: 
Thread-Topic: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
References:    
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3636260749_1042665947"
Archived-At: 
Subject: Re: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2019 07:25:55 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3636260749_1042665947
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Let me try again =E2=80=A6

=20
Only IPv4-compatible IPv6 addresses are deprecated, and that means only ::I=
Pv4 is deprecated (so only if starts with 96 cero-bits).
Representing an IPv4/IPv6 translated address in this way is explicitly ment=
ion in RFC6052, for both cases, the WKP and NSP.
However, my example in draft-palet-v6ops-464xlat-opt-cdn-caches (section 4)=
 by using that textual representation and the same IPv4 address in the AAAA=
 record, may be interpreted as an NSP, which is not the case. The example a=
t Section 3 is clear because it is a WKP.
=20

So, in the next version (-01) I=E2=80=99ve changed the example at section 4=
. I=E2=80=99d previously already added a similar example at section 5.

=20

It will be nice if there are any new comments, as I plan to upload today/to=
morrow a new version :-)


Regards,

Jordi

=20

=20

=20

El 24/3/19 0:25, "v6ops en nombre de =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" =
 escribi=C3=B3:

=20

At Sat, 23 Mar 2019 18:32:54 +0100,
Fred Baker  wrote:

> I don't think so. RFC 6052 lays out where bits go; yes, that's what Jordi=
 intends. I'm commenting on the *text* in the document, not the bits the te=
xt represents.
>=20
> Observe https://tools.ietf.org/html/rfc4291#section-2.2 and https://tools=
.ietf.org/html/rfc4291#section-2.5.5. It only applies the format to ipv4-em=
bedded (IPv4-Compatible and IPv4-Mapped) addresses, which RFC 4291 deprecat=
es.
>=20
> Happy to be wrong; I called it a nit. But I want to make sure we're on th=
e same topic before we call it an error...

I'm confused.  Are you saying 2001:db8::192.0.5.1 is not a valid
textual IPv6 address?  In my understanding that's perfectly valid
(probably quite uncommon, though).  I'm especially confused as you
referred to Section 2.2 of RFC4291... It states:

   3. An alternative form that is sometimes more convenient when dealing
      with a mixed environment of IPv4 and IPv6 nodes is
      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
      the six high-order 16-bit pieces of the address, and the 'd's are
      the decimal values of the four low-order 8-bit pieces of the
      address (standard IPv4 representation).  Examples:
[...]

Although the "examples" only show the case of x:x:x:x:x:x being either
0:0:0:0:0:0 or 0:0:0:0:0:FFFF, I interpret the above text as 'x' can
be any hexadecimal value.

And btw, RFC4291 does not deprecate IPv4-mapped IPv6 addresses (it
only deprecated IPv4-compatible IPv6 addresses).

--
JINMEI, Tatuya

_______________________________________________ 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_3636260749_1042665947
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Let me try again =E2=80=A6=

 
  1. Only IPv4-compatible IPv6 addresses are deprecate=
d, and that means only ::IPv4 is deprecated (so only if starts with 96 cero=
-bits).
  2. Representing an IPv4/IPv6 translated addres=
s in this way is explicitly mention in RFC6052, for both cases, the WKP and=
 NSP.
  3. However, my example in draft-palet-v6ops-464x=
lat-opt-cdn-caches (section 4) by using that textual representation and the=
 same IPv4 address in the AAAA record, may be interpreted as an NSP, which =
is not the case. The example at Section 3 is clear because it is a WKP.
 
So, in the next version (-01) I=E2=80=99ve changed the examp=
le at section 4. I=E2=80=99d previously already added a similar example at =
section 5.
 =

It will be nice if there are any new comments, as I =
plan to upload today/tomorrow a new version :-)
<=
p class=3DMsoNormal>
Regards,
Jordi
 
 
 <=
/o:p>
El 24/3/19 0:25, "v6ops en nombre de =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" &l=
t;v6ops-bounces@ietf.org en n=
ombre de jinmei@wide.ad.jp> esc=
ribi=C3=B3:
 
At Sat, 23 Mar 2019 18:32:54 +0100,
Fred B=
aker <fredbaker.ietf@gmail.c=
om> wrote:

> I don't think so. RFC 6052 lays out where bit=
s go; yes, that's what Jordi intends. I'm commenting on the *text* in the d=
ocument, not the bits the text represents.
> 
> Observe https://tools.ietf.org=
/html/rfc4291#section-2.2 and https://tools.ietf.org/html/rfc4291#section-2.5.5.=
 It only applies the format to ipv4-embedded (IPv4-Compatible and IPv4-Mapp=
ed) addresses, which RFC 4291 deprecates.
> 
> Happy to be wron=
g; I called it a nit. But I want to make sure we're on the same topic befor=
e we call it an error...

I'm confused.  Are you saying 2001:db8::192.0.5.1 is not a valid
textual IPv6 address?  In my underst=
anding that's perfectly valid
(probably quite uncommon, though).  I=
'm especially confused as you
referred to Section 2.2 of RFC4291... It s=
tates:

   3. An alternative form that is sometimes more co=
nvenient when dealing
      with a mixed enviro=
nment of IPv4 and IPv6 nodes is
      x:x:x:x:x=
:x:d.d.d.d, where the 'x's are the hexadecimal values of
  &nb=
sp;   the six high-order 16-bit pieces of the address, and the 'd=
's are
      the decimal values of the four low=
-order 8-bit pieces of the
      address (stand=
ard IPv4 representation).  Examples:
[...]

Although the &quo=
t;examples" only show the case of x:x:x:x:x:x being either
0:0:0:0:=
0:0 or 0:0:0:0:0:FFFF, I interpret the above text as 'x' can
be any hexa=
decimal value.

And btw, RFC4291 does not deprecate IPv4-mapped IPv6 =
addresses (it
only deprecated IPv4-compatible IPv6 addresses).

--=

JINMEI, Tatuya
_______________________________________________ v6ops m=
ailing 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_3636260749_1042665947--


From nobody Mon Mar 25 07:08: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 7C0A012038C for ; Mon, 25 Mar 2019 07:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 a0c70DfrV2tO for ; Mon, 25 Mar 2019 07:08:54 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C3D1203F0 for ; Mon, 25 Mar 2019 07:08:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553522931; x=1554127731; 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=z0obfuLq 2pNWWLJgq6wDTxVhfilbF2pKtrew3ucTeTY=; b=HnfrHCMW2F4O0UyC7v5SPKYK OvggN360TCcDTs9fJOJfUiHFM33vZGkRxyib8bHwG+RZoCUlmU/Vmclyaj9kJ9BW GvhlRyAx6ifmJTjChOeK7WKDhqe2QU2T8zTAAwNIVh6ggw22VtQrLuM39Koq6mAy Gkq2Y+2QiLunkAe4kCs=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 25 Mar 2019 15:08:51 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 25 Mar 2019 15:08:51 +0100
Received: from [31.133.151.187] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006198146.msg for ; Mon, 25 Mar 2019 15:08:51 +0100
X-MDRemoteIP: 2001:67c:1232:144:dfb:e37b:54e7:e754
X-MDHelo: [31.133.151.187]
X-MDArrival-Date: Mon, 25 Mar 2019 15:08:51 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=19872fddb8=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Mon, 25 Mar 2019 15:08:50 +0100
From: JORDI PALET MARTINEZ 
To: IPv6 Operations 
Message-ID: 
Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>
In-Reply-To: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Mon, 25 Mar 2019 14:08:57 -0000

Hi all,

We have published a new version of this document, taking in consideration a=
 few inputs, clarified some examples, nits, etc.

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

Regards,
Jordi
=20
=20


=EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:

   =20
    A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
    has been successfully submitted by Jordi Palet Martinez and posted to t=
he
    IETF repository.
   =20
    Name:		draft-palet-v6ops-464xlat-opt-cdn-caches
    Revision:	01
    Title:		464XLAT Optimization for CDNs/Caches
    Document date:	2019-03-25
    Group:		Individual Submission
    Pages:		10
    URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-=
464xlat-opt-cdn-caches-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-464x=
lat-opt-cdn-caches/
    Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat-o=
pt-cdn-caches-01
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6ops=
-464xlat-opt-cdn-caches
    Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-4=
64xlat-opt-cdn-caches-01
   =20
    Abstract:
       This document describes the drawbacks of IP/ICMP Translation
       Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
       applications initiate traffic flows to dual-stack CDNs (Content
       Delivery Networks) or Caches, which are forced to be translated back
       to IPv4 by a NAT64.  The document proposes possible solutions to
       avoid that.
   =20
                                                                           =
          =20
   =20
   =20
    Please note that it may take a couple of minutes from the time of submi=
ssion
    until the htmlized version and diff are available at tools.ietf.org.
   =20
    The IETF Secretariat
   =20
   =20



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

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Wed Mar 27 04:03:44 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26630120559; Wed, 27 Mar 2019 04:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gzPriKM8eaU8; Wed, 27 Mar 2019 04:03:39 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E60120621; Wed, 27 Mar 2019 04:03:36 -0700 (PDT)
Received: from [IPv6:2a02:8308:40:3000:b044:9b9a:327d:b750] (unknown [IPv6:2a02:8308:40:3000:b044:9b9a:327d:b750]) (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 65ECB8057E; Wed, 27 Mar 2019 12:03:31 +0100 (CET)
To: "6man@ietf.org" <6man@ietf.org>
Cc: Erik Kline , "Jan Zorz @ go6.si" , =?UTF-8?Q?Ole_Tr=c3=b8an?= , IPv6 Operations , "iepg@iepg.org" 
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: Wed, 27 Mar 2019 12:03:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [v6ops] TODAY's side meeting about slaac renumbering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Mar 2019 11:03:43 -0000

Folks,

Some of us we'll be meeting today to talk about slaac renumbering
(draft-gont-6man-slaac-renum). If you're interested on the topic, it
would be great if you could join.

When: Today (Wednesday (March 27)) at 13:30
Where: IETF Registration desk


I'm aware some of you will not be able to make it -- apologies for the
short notice, btw). In any case, this will not be the only and last talk
on the topic, but rather one attempt to help us converge on something.

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 Wed Mar 27 05:33: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 2C01F1202B5; Wed, 27 Mar 2019 05:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80p9Wa8rZyCe; Wed, 27 Mar 2019 05:33:11 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423C11202AA; Wed, 27 Mar 2019 05:33:10 -0700 (PDT)
Received: from [IPv6:2001:67c:1232:144:b044:9b9a:327d:b750] (unknown [IPv6:2001:67c:1232:144:b044:9b9a:327d:b750]) (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 F063182EEF; Wed, 27 Mar 2019 13:33:06 +0100 (CET)
From: Fernando Gont 
To: "6man@ietf.org" <6man@ietf.org>
Cc: Erik Kline , "Jan Zorz @ go6.si" , =?UTF-8?Q?Ole_Tr=c3=b8an?= , IPv6 Operations , "iepg@iepg.org" 
References: 
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: <2d879049-fb9b-2424-c055-196918ea3b5b@si6networks.com>
Date: Wed, 27 Mar 2019 13:33:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] TODAY's side meeting about slaac renumbering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Mar 2019 12:33:14 -0000

Folks,

FWIW, we are heading to the "Code Longue" (Chez Louis room) to have the
meeting there.

Cheers,
Fernando




On 27/3/19 12:03, Fernando Gont wrote:
> Folks,
> 
> Some of us we'll be meeting today to talk about slaac renumbering
> (draft-gont-6man-slaac-renum). If you're interested on the topic, it
> would be great if you could join.
> 
> When: Today (Wednesday (March 27)) at 13:30
> Where: IETF Registration desk
> 
> 
> I'm aware some of you will not be able to make it -- apologies for the
> short notice, btw). In any case, this will not be the only and last talk
> on the topic, but rather one attempt to help us converge on something.
> 
> 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 Mar 28 03:31: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 9A147120299; Thu, 28 Mar 2019 03:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiWIpCzi7k52; Thu, 28 Mar 2019 03:30:52 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB72F1203ED; Thu, 28 Mar 2019 03:30:51 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id z17so22346711qts.13; Thu, 28 Mar 2019 03:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=2PZMr3gFuNw3t51mJu+czAkrI41QVOsZdGg29MW/sfE=; b=PBCTOzvFEsnnQBlSIibs74IAN8eqMIDVAjmOPj3KGfb660CPC8fn//nFq8zENY+hsB IfQaB0/JKRI4zOCK1r2t/u44Np+R/xp/AVedpDGjFYC7he91KIWOk6ZRoDs/PTD+k28i LntMAI4cXdJtbVpKu2p9uwdIzwIewjI2RliNEsJV6WiWKDBBeJ/Xkh7bGyVgvAieNqA8 43GvNegNCvAxBNX9Q/SduFypdZqwaXHMaIB1Un773WS2dhuMAzCb/zQSw7lEX77Tha/I AwGeZbUSLSvWaqQiInKUX99q2bfdEU4CbjWmjieQot9YaH1oqMk7HMdsDhNu+woISYgD C1rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2PZMr3gFuNw3t51mJu+czAkrI41QVOsZdGg29MW/sfE=; b=eb6S1p3SJhepyLTmbelcj7EhRu0Ln6WI1rHSnP3yD9ZpsdMz+jhlE6Qesj0CN5mJFV /6L9drOsVhq4Dt2x65Bg9uR1m+QeNWwZTmOxTikUkHAGa/Rk93t0WYJNbGqWJJGrExyZ EjGKEPTkYi9ZbWO1JXxIB0Y5LdckT+JZ6hVEyjKRC8YPh4BoUjzElmrppwjUfWG22if4 7u/ArEgPN+AeE5/W8qDpQBQC24JXBwYZjIFWxGtaJdw0SsdYheTnhxKvOG8DPXHn28G0 52z3h0lsaJfNGscwGuudPg5Z1iivSf1jDllv/Tong0hAY5iMfTdQbO+ODS7DV7s5W85P 4mCw==
X-Gm-Message-State: APjAAAWJCB0VHvDWFG0w6rlohoRo1Ma6CqpGb2UFJmFpBT64RUu6WWrG /es/wisYlMjTOkelTwHA15tjs3u5UE85YvKj10BLaquIiCw=
X-Google-Smtp-Source: APXvYqwge0MERyOGZvPHxXwdcxUIfmQVgz2wh9oPxn9eUlB9N76lr/aAb+3O0LNt+uw3BgqrspSN9eLcz9WxB3jVH8M=
X-Received: by 2002:aed:35e4:: with SMTP id d33mr33593669qte.58.1553769050450;  Thu, 28 Mar 2019 03:30:50 -0700 (PDT)
MIME-Version: 1.0
From: Jen Linkova 
Date: Thu, 28 Mar 2019 21:30:39 +1100
Message-ID: 
To: V6 Ops List , 6man 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [v6ops] Thoughts on draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 10:31:01 -0000

I've been thinking about the draft and the renumbering/prefix failure
problem in general...

IMHO there is no a single silver bullet so maybe it makes sense to
look at issues caused by misbehaving CPEs which are not invalidating
"old" prefixes after getting new prefix (or network  address change in
general) and prioritize them. All issues are painful but some are more
painful than others for operators...

Here is what I've come up with for the scenario when the network
prefix has changed and the host has now two (or more) addresses from
different prefixes and not all them belong to the network anymore -
based on the draft and my experience with that problem:.

#1: High priority/must have: ensure that the host selects an address
from the "working" prefix for new sessions.

#2: Med/High priority, nice to have: preserving existing connections
or at least explicitly quickly terminate them instead of letting them
timing out.

#3: Med/Low priority: ensuing that if the old prefix is reassigned to
another part of the network, the host can communicate to new owners of
the prefix

#4: Preventing the host from exceeding the number of allowed/supported
# of addresses on the interface.

Obviously it would be highly desirable to minimize the disruptive
changes to the protocol.

So what can we do to address those issues:

Problem #1:

1.0) Consider doing Happy Eyeballs for source addresses if the host
has GUAs from more than one /64. What do the host implementors think?
It would help with other blackholing cases as well..

1.1) whatever caused the issue, in many scenarious (esp.
residential/hotsopt deployments) it does not make much sense to have
PIO lifetime being significantly higher that default router lifetime.
Therefore two things could be done:


1.1.1) Update RFC4861 with smth like:

    the default value for AdvPreferredLifetime should be Max
(1.2*AdvDefaultLifetime; 3*MaxRtrAdvInterval)

    the default value for AdvValidLifetime should be
Max(1.5**AdvDefaultLifetime; 3*MaxRtrAdvInterval, 2hrs)

(MAX is used to ensure that deprecating the router does not
automtically deprecate the prefix if the PIO lifetime is not
explicitly configured)

1.2.2) Provide guidleines to operators recommenting putting sensible
values for the corresponding timers for DHCP-PD leases and CPE
configs.

1.3) [additional crazy idea I was playing with...] changing the
network addressing could be considering as changing the PvD. What if a
router, when sending RAs, uses LLA which is a stateless hash function
of PIOs?

So then let's say the router has a prefix P1 configured on the
interface. It sends RAs with the PIO1 using LLA1 = f(P1).

Then the prefix has changed (reboot, crash, uplink flap - or even
worse, the whole CPE was replaced). The router (the same or new one)
has now another prefix P2 on the interface. Then it wll be sending RAs
from LLA2 = f(P2). RFC8028-compliant hosts (aka supporting rule 5.5)
would invalidate LLA1 as a next-hop by using NUD and by starting using
LLA2 they would select addresses from P2 as the source addresses.


Problem #2:

2.1) Would it be reasonable to expect a CPE (or an operator, at BNG
level, for example) to implement a kind of basic BCP38 and send ICMPv6
error back if the packet coming from the downstream has the source
IPv6 address from the prefix which is not delegated to that network?
At least it would give the hosts some clear signal...

Problem #3

Not sure how much it's a problem really but 1.1) (see above) should
help as well as addresses would be invalidated much faster than in 30
days.

Problem #4:

Would it be really a problem if problems 1-3 are fixed? If the OS
limit for valid addresses is too low, maybe the OS needs to be fixed?

One might say that there is no point of propising any changes on CPEs
as if they are not doing the right things now they are very unlikely
to implement the proposed changes correctly. However the main issue is
related to keeping the state between reboots and/or coordinating
different components (DHCPv6 client and radvd etc) - and there is a
case of CPE replacement. Changes which are limited to default values
changes or modifying just one component (BCP38) might be more
successful.

Thoughts?

-- 
SY, Jen Linkova aka Furry


From nobody Thu Mar 28 03:43:17 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DB01202C9; Thu, 28 Mar 2019 03:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ12-poQ5Kcu; Thu, 28 Mar 2019 03:42:59 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2182C120487; Thu, 28 Mar 2019 03:42:59 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id w10so22230236wrm.4; Thu, 28 Mar 2019 03:42:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pboN2Pz2cSwd7sJFHpbPz55g7LXD2Z5TDLRfuVfQPkg=; b=Ejeir8d819XNx1hW6Pl/0wZSqzDg1HBUBmFb/3ZqiglynMon8ROsN3QUK6um26mz75 2+YaQWKcOpN/uyQFLSWMHYCN3HAUTkegy/U+dD04vACW1lQlqWTutnu3ozzc/9L59YnU HTSJbSo2uTGsB7wm3C28q8gwcojDsRNRxYXh4BPBZXNUtGwOBgSy979flNsX2liPfYKR RK04HXAJWimY+ybuAUto1/USKJ9meLl6m3cNgttD5A+OM3TSGtt4NJXz78/D5pmNTds1 9KZEy7GX1CMv62OdkUYxdaVzZbz8NlMzRd5W/cZNieJK+qWyJ/3/f9idPMYnh+VBprNZ 9qyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pboN2Pz2cSwd7sJFHpbPz55g7LXD2Z5TDLRfuVfQPkg=; b=AsHrHGhqYMTZF+aOZV406UpU8pfrCoOkcNFX24NhY0RMiCH+f0uFkrcn9/h9J4H405 PvALUohuWIwXZcJAD9sq3JcUZ99+Hrl2b97z27Nd6HjN3UAcdPxtsVOfwWVac8URjAvY QUFw7ZS8kNaPNpBMmGeS1f7QmV4V6eG4XDssfUS6rmY2VqgPdKcmrN8Z7kZm7SZyIYtU a+6tdRN1g5np43C2BYC23MSZJVYMo90KwPBEkiUVtqE7q4M8t8lxvV0yXGscILVPrK0b jojanFsJHnnkrSrn8AlyWTdkU0jysGnH6cxJkRRnN0nICgL8ZwDrh4nXsRBooAZz7QH0 C/Ng==
X-Gm-Message-State: APjAAAUVIoofgfjmXiGJfTa+FRz+9iph5MVnmQrnbSTeAedI2rWAhSLd qhg0HiaG0nE3+1HIwgqUcrM=
X-Google-Smtp-Source: APXvYqydUgQOpEikciLt/4iBOI7cDdOfMeUYTct6ljFMoJeAUyemjTBXyyNgLQXDwFT/13DZs16FpQ==
X-Received: by 2002:a5d:6681:: with SMTP id l1mr5291530wru.186.1553769777632;  Thu, 28 Mar 2019 03:42:57 -0700 (PDT)
Received: from dhcp-9503.meeting.ietf.org (dhcp-9503.meeting.ietf.org. [31.133.149.3]) by smtp.gmail.com with ESMTPSA id u14sm1829019wrr.1.2019.03.28.03.42.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 03:42:56 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Bob Hinden 
In-Reply-To: 
Date: Thu, 28 Mar 2019 11:42:54 +0100
Cc: Bob Hinden , V6 Ops List , IPv6 List 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F22335E-414E-4A76-8ABE-640B8B6382BF@gmail.com>
References: 
To: Jen Linkova 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [v6ops] Thoughts on draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 10:43:10 -0000

Jen,

This is useful.

It reminded me to say, this draft would be better if it didn=E2=80=99t =
use the word renumbering.   Renumbering is a much bigger topic that =
includes updating DNS records, updating filter/firewall rules, and any =
other place where prefixes are recorded.   I think this draft is focused =
on a specific issue.  =20

However, there will be related issues if a site's prefix changes =
quickly.

Bob


> On Mar 28, 2019, at 11:30 AM, Jen Linkova  wrote:
>=20
> I've been thinking about the draft and the renumbering/prefix failure
> problem in general...
>=20
> IMHO there is no a single silver bullet so maybe it makes sense to
> look at issues caused by misbehaving CPEs which are not invalidating
> "old" prefixes after getting new prefix (or network  address change in
> general) and prioritize them. All issues are painful but some are more
> painful than others for operators...
>=20
> Here is what I've come up with for the scenario when the network
> prefix has changed and the host has now two (or more) addresses from
> different prefixes and not all them belong to the network anymore -
> based on the draft and my experience with that problem:.
>=20
> #1: High priority/must have: ensure that the host selects an address
> from the "working" prefix for new sessions.
>=20
> #2: Med/High priority, nice to have: preserving existing connections
> or at least explicitly quickly terminate them instead of letting them
> timing out.
>=20
> #3: Med/Low priority: ensuing that if the old prefix is reassigned to
> another part of the network, the host can communicate to new owners of
> the prefix
>=20
> #4: Preventing the host from exceeding the number of allowed/supported
> # of addresses on the interface.
>=20
> Obviously it would be highly desirable to minimize the disruptive
> changes to the protocol.
>=20
> So what can we do to address those issues:
>=20
> Problem #1:
>=20
> 1.0) Consider doing Happy Eyeballs for source addresses if the host
> has GUAs from more than one /64. What do the host implementors think?
> It would help with other blackholing cases as well..
>=20
> 1.1) whatever caused the issue, in many scenarious (esp.
> residential/hotsopt deployments) it does not make much sense to have
> PIO lifetime being significantly higher that default router lifetime.
> Therefore two things could be done:
>=20
>=20
> 1.1.1) Update RFC4861 with smth like:
>=20
>    the default value for AdvPreferredLifetime should be Max
> (1.2*AdvDefaultLifetime; 3*MaxRtrAdvInterval)
>=20
>    the default value for AdvValidLifetime should be
> Max(1.5**AdvDefaultLifetime; 3*MaxRtrAdvInterval, 2hrs)
>=20
> (MAX is used to ensure that deprecating the router does not
> automtically deprecate the prefix if the PIO lifetime is not
> explicitly configured)
>=20
> 1.2.2) Provide guidleines to operators recommenting putting sensible
> values for the corresponding timers for DHCP-PD leases and CPE
> configs.
>=20
> 1.3) [additional crazy idea I was playing with...] changing the
> network addressing could be considering as changing the PvD. What if a
> router, when sending RAs, uses LLA which is a stateless hash function
> of PIOs?
>=20
> So then let's say the router has a prefix P1 configured on the
> interface. It sends RAs with the PIO1 using LLA1 =3D f(P1).
>=20
> Then the prefix has changed (reboot, crash, uplink flap - or even
> worse, the whole CPE was replaced). The router (the same or new one)
> has now another prefix P2 on the interface. Then it wll be sending RAs
> from LLA2 =3D f(P2). RFC8028-compliant hosts (aka supporting rule 5.5)
> would invalidate LLA1 as a next-hop by using NUD and by starting using
> LLA2 they would select addresses from P2 as the source addresses.
>=20
>=20
> Problem #2:
>=20
> 2.1) Would it be reasonable to expect a CPE (or an operator, at BNG
> level, for example) to implement a kind of basic BCP38 and send ICMPv6
> error back if the packet coming from the downstream has the source
> IPv6 address from the prefix which is not delegated to that network?
> At least it would give the hosts some clear signal...
>=20
> Problem #3
>=20
> Not sure how much it's a problem really but 1.1) (see above) should
> help as well as addresses would be invalidated much faster than in 30
> days.
>=20
> Problem #4:
>=20
> Would it be really a problem if problems 1-3 are fixed? If the OS
> limit for valid addresses is too low, maybe the OS needs to be fixed?
>=20
> One might say that there is no point of propising any changes on CPEs
> as if they are not doing the right things now they are very unlikely
> to implement the proposed changes correctly. However the main issue is
> related to keeping the state between reboots and/or coordinating
> different components (DHCPv6 client and radvd etc) - and there is a
> case of CPE replacement. Changes which are limited to default values
> changes or modifying just one component (BCP38) might be more
> successful.
>=20
> Thoughts?
>=20
> --=20
> SY, Jen Linkova aka Furry
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Mar 28 06:55: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 3CBC0120477; Thu, 28 Mar 2019 06:55:45 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmeZaIJMtUaT; Thu, 28 Mar 2019 06:55:42 -0700 (PDT)
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 031341204B0; Thu, 28 Mar 2019 06:55:42 -0700 (PDT)
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 m1h9VVK-0000J5C; Thu, 28 Mar 2019 14:55:38 +0100
Message-Id: 
To: v6ops@ietf.org
Cc: Jen Linkova 
Cc: 6man 
From: Philip Homburg 
Sender: pch-b9D3CB0F5@u-1.phicoh.com
In-reply-to: Your message of "Thu, 28 Mar 2019 21:30:39 +1100 ."  
Date: Thu, 28 Mar 2019 14:55:37 +0100
Archived-At: 
Subject: Re: [v6ops] Thoughts on draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 13:55:53 -0000

>#1: High priority/must have: ensure that the host selects an address
>from the "working" prefix for new sessions.

I'd like to add that this should happen relatively quickly. Say within
one minute of the old prefix not working anymore.

>#2: Med/High priority, nice to have: preserving existing connections
>or at least explicitly quickly terminate them instead of letting them
>timing out.

Here I'd like to add be conservative, do not break connection unless
the connection cannot work anymore. Do not break a connection because,
for example, one RA got lost.

>#3: Med/Low priority: ensuing that if the old prefix is reassigned to
>another part of the network, the host can communicate to new owners of
>the prefix

I think there are two cases here:
- the old prefix is reassigned after any DHCP lease has expired
- or, two overlapping leases for the prefix exist.

>Problem #1:
>
>1.0) Consider doing Happy Eyeballs for source addresses if the host
>has GUAs from more than one /64. What do the host implementors think?
>It would help with other blackholing cases as well..

My experience with Happy Eyeballs is that it is already hard to do
for destination addresses. It would be nice to have a standard algorithm
that also includes source addresses, but I think it is unlikely anything
would both get concensus and get widely deploy on a reasonable time scale.

To consider just one corner case, take the DNS stub resolver in a C library
(for example glibc). Now make that also deal with probing multiple source
addresses.

>1.1) whatever caused the issue, in many scenarious (esp.
>residential/hotsopt deployments) it does not make much sense to have
>PIO lifetime being significantly higher that default router lifetime.
>Therefore two things could be done:

With the requirement that the old prefix should not be used on a time scale
of minutes, making those changes will not have the desired effect unless
Max(1.2*AdvDefaultLifetime; 3*MaxRtrAdvInterval) is in the order of one
minute. Which requires a huge increase in RA multicast rate.

>1.2.2) Provide guidleines to operators recommenting putting sensible
>values for the corresponding timers for DHCP-PD leases and CPE
>configs.

Again that doesn't solve problem number 1 in a timely matter.

>1.3) [additional crazy idea I was playing with...] changing the
>network addressing could be considering as changing the PvD. What if a
>router, when sending RAs, uses LLA which is a stateless hash function
>of PIOs?

It seems to me that this could work.

>Problem #2:
>
>2.1) Would it be reasonable to expect a CPE (or an operator, at BNG
>level, for example) to implement a kind of basic BCP38 and send ICMPv6
>error back if the packet coming from the downstream has the source
>IPv6 address from the prefix which is not delegated to that network?
>At least it would give the hosts some clear signal...

The tricky thing here is for the host to figure out that it is the 
source address that causes problems. Though I guess destination unreachable
codes could be allocated.

>Problem #3
>
>Not sure how much it's a problem really but 1.1) (see above) should
>help as well as addresses would be invalidated much faster than in 30
>days.

I think it would be good to have a CPE spec recommend defaulting to 
valid lifetimes on the order of hours.

Having the host limit the valid lifetime may result in hosts not having
any global addresses if a router goes down for a long time. Given the
complexity of dealing with link local addresses, that could leave hosts
with no network.

So in my opinion it is best if the network controls the lifetimes.

>Problem #4:
>
>Would it be really a problem if problems 1-3 are fixed? If the OS
>limit for valid addresses is too low, maybe the OS needs to be fixed?

It shouldn't be too hard for hosts to expire old addresses in case there
are too many.



From nobody Thu Mar 28 07:35:44 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4928F12042D for ; Thu, 28 Mar 2019 07:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=plonka-us.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYIbEZLL2XL3 for ; Thu, 28 Mar 2019 07:35:38 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370461204B0 for ; Thu, 28 Mar 2019 07:35:21 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id e80so18534826ote.5 for ; Thu, 28 Mar 2019 07:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plonka-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Oooc7Ztj24q4Zs4KyfsJEHokQFPKWOo1ko374nW39gY=; b=tlA7h2LgnwSITmyGto7zMYBiUb4qyITnN6FIzkn4VlxxqJO7bMjhSJlQceVaZbuIUc yj8BPLY1t8HRiKj0ytXXDWdWWHmjZkU1Il7XRrZTHsUDvmZvc0+dSknpTrXfrVInKyeC aYc/x48/OISskwwE3y6M1OkElrP/snW5WOn7GnQk76ZRCHtCUiUhH94+rXaH96zXnzYp G5rZRQ9XmXAh9/tVePA0eozI6uitijAMqNxZtml2Ycxuj8bprzmk1Zyhik6eGworp2AA IxKBabFDkf26zQzE0FmExjl0T1LrH13WVh7sgYjIslkxqTnctpGNZOzdP71LfUEJT1hk wVOw==
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=Oooc7Ztj24q4Zs4KyfsJEHokQFPKWOo1ko374nW39gY=; b=PJgnja2qIweq5HP0kS0zSUmb5l69u5LgzcnwRzMte6yHHEtwwVvsy2risWrGQavCyq rQBZKnRp79FD7a+RYeDFLm0JF+DYjcMwjzHWIVVo/ATOLArWPnBE3raT6pN9JMZtpEu7 5zFA5Mj9QSIWcwtZ3p5WAaH64o7bN+5lTFyJbknV3Vi4svJ/SKlVTISfD8VYDnC82IgV Xv+aDdwxugqcDs7UURM4k6pkNW3p/nWyIg+cVmICqz9bJctqyqsmNNEaG5R0LfTUSo0A zXzt1hqNZZkNxUlK6jEBp4CWzYgM4K6K33llQPME9OWBqawQKwnYi8OL8l1yOdUzplbz NgcQ==
X-Gm-Message-State: APjAAAXUdixTDK5Ey8zWzdJjEgtAIwqO4YIoF4HTiKWhNRzDkxquht8C oN/NmuwVlWFcXbLJ8EPFkW0nf09lCo2p6tRgTE15/w==
X-Google-Smtp-Source: APXvYqzoRcJeNkIhFQZKOwLtiMj+GMzuyh+aILtUVoYKeg/Yr8c+vhJCiCal/NZZytiOb4HllrwMHRYZ08EIguIVPRE=
X-Received: by 2002:a05:6830:1446:: with SMTP id w6mr19076830otp.157.1553783720417;  Thu, 28 Mar 2019 07:35:20 -0700 (PDT)
MIME-Version: 1.0
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com> 
In-Reply-To: 
From: Dave Plonka 
Date: Thu, 28 Mar 2019 15:35:09 +0100
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Operations 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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, 28 Mar 2019 14:35:44 -0000

Hi Jordi -

Thanks for this draft presentation in v6ops.

As we mentioned in the v6ops meeting, I don't think a CPE (or any
remote host) can reliably determine if a given IPv4 DNS client is an
IPv4-only host.

For one, this is because dual-stack hosts have at least two different
IP addresses (v4 and v6), as you know, and there isn't a simple way to
remotely determine that a given IPv4 address and a given IPv6 address
are actually bound to the same host's interface(s), or even to enforce
that a dual-stack host will query the same DNS recursive service when
using two (or more) different client (IPv4 and IPv6) addresses.

However, for your draft, couldn't we just eliminate any attempt to
determine if any hosts are v4-only or not, and always synthesize the
IPv4 DNS answers?

I'm not saying I'm in favor of the mechanism overall, just saying we
could avoid the unnecessary and error-prone step of trying to
determine if a host is v4 only.

Does that make sense?

Thanks,
Dave


On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
 wrote:
>
> Hi all,
>
> We have published a new version of this document, taking in consideration=
 a few inputs, clarified some examples, nits, etc.
>
> https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches=
/?include_text=3D1
>
> Regards,
> Jordi
>
>
>
>
> =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
>
>
>     A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
>     has been successfully submitted by Jordi Palet Martinez and posted to=
 the
>     IETF repository.
>
>     Name:               draft-palet-v6ops-464xlat-opt-cdn-caches
>     Revision:   01
>     Title:              464XLAT Optimization for CDNs/Caches
>     Document date:      2019-03-25
>     Group:              Individual Submission
>     Pages:              10
>     URL:            https://www.ietf.org/internet-drafts/draft-palet-v6op=
s-464xlat-opt-cdn-caches-01.txt
>     Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-46=
4xlat-opt-cdn-caches/
>     Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat=
-opt-cdn-caches-01
>     Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6o=
ps-464xlat-opt-cdn-caches
>     Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops=
-464xlat-opt-cdn-caches-01
>
>     Abstract:
>        This document describes the drawbacks of IP/ICMP Translation
>        Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
>        applications initiate traffic flows to dual-stack CDNs (Content
>        Delivery Networks) or Caches, which are forced to be translated ba=
ck
>        to IPv4 by a NAT64.  The document proposes possible solutions to
>        avoid that.
>
>
>
>
>     Please note that it may take a couple of minutes from the time of sub=
mission
>     until the htmlized version and diff are available at tools.ietf.org.
>
>     The IETF Secretariat
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or c=
onfidential. The information is intended to be for the exclusive use of the=
 individual(s) named above and further non-explicilty authorized disclosure=
, copying, distribution or use of the contents of this information, even if=
 partially, including attached files, is strictly prohibited and will be co=
nsidered a criminal offense. If you are not the intended recipient be aware=
 that any disclosure, copying, distribution or use of the contents of this =
information, even if partially, including attached files, is strictly prohi=
bited, will be considered a criminal offense, so you must reply to the orig=
inal sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--

dave@plonka.us  http://www.cs.wisc.edu/~plonka/


From nobody Thu Mar 28 07:58:35 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D4F1204C0 for ; Thu, 28 Mar 2019 07:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=telecentro.net.ar
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MesvXamG7pQH for ; Thu, 28 Mar 2019 07:58:26 -0700 (PDT)
Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFBB120004 for ; Thu, 28 Mar 2019 07:58:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 2106D3201F64; Thu, 28 Mar 2019 11:58:24 -0300 (-03)
Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Gu4kdG2pVaEe; Thu, 28 Mar 2019 11:58:22 -0300 (-03)
Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 177663201DE2; Thu, 28 Mar 2019 11:58:22 -0300 (-03)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 177663201DE2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1553785102; bh=McE1UCTqbfdhv73X9GNECsTp5+ECI/8JXhH1xPYa6mA=; h=Date:From:To:Message-ID:MIME-Version; b=kVssLFBA9lDWNSxj65huwKUaC3mteEJfkz41vII9Q+ceflvl6drMwm53sO74/aM1T t1T+Gvs50ZgKkuaxLe1R6FYZXw60dNX/dHRhHirN923CyjZZp4/fNOgIaYopnd7ctr 7uRHMWwb/Lpq2k2GPUTslG4/LCM+OXlIyW2P7IZfwgSxUc8mVQtJi849AGlc97Q9SY A1jgeWs11ZdhjTL2JitVwSRuxfz1krVCwUqDLFlqhJEfU6o3MwQCJ93k3OqkXuGigC K/7U/aMNOHPNnUb5MDiZhhoH/0xSHgqg6/7hvuCqYUx1AZXLH34eadb1L7SBq1jcQL Cb4HSdhxkBWlw==
X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local
Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id choobAhYlAHQ; Thu, 28 Mar 2019 11:58:22 -0300 (-03)
Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id EE02E3201DD6; Thu, 28 Mar 2019 11:58:21 -0300 (-03)
Date: Thu, 28 Mar 2019 11:58:21 -0300 (ART)
From: Alejandro D'Egidio 
To: Dave Plonka 
Cc: JORDI PALET MARTINEZ ,  "v6ops@ietf.org list" 
Message-ID: <1983027669.228739476.1553785101842.JavaMail.zimbra@telecentro.net.ar>
In-Reply-To: 
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.210.50.96]
X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC73 (Win)/8.8.8_GA_1703)
Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
Thread-Index: PYsL1VDoNd8BTj3Qog9poqJzexwDDQ==
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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, 28 Mar 2019 14:58:33 -0000

Hello Dave,
I hope you are doing well.
Is you question related to approach 4 where we suggest to use DNS?
The idea was to share the idea of what happens on different scenarios when =
we have a IPv4-only device/app and how can we solve the issue with differen=
t approaches.

Using DNS, yes, I think also could be a good idea to always check if there =
is an AAAA record for any A record requested and add that relationship to t=
he EAMT.


Regards,
Alejandro


----- Mensaje original -----
De: "Dave Plonka" 
Para: "JORDI PALET MARTINEZ" 
CC: "v6ops@ietf.org list" 
Enviados: Jueves, 28 de Marzo 2019 11:35:09
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464x=
lat-opt-cdn-caches-01.txt

Hi Jordi -

Thanks for this draft presentation in v6ops.

As we mentioned in the v6ops meeting, I don't think a CPE (or any
remote host) can reliably determine if a given IPv4 DNS client is an
IPv4-only host.

For one, this is because dual-stack hosts have at least two different
IP addresses (v4 and v6), as you know, and there isn't a simple way to
remotely determine that a given IPv4 address and a given IPv6 address
are actually bound to the same host's interface(s), or even to enforce
that a dual-stack host will query the same DNS recursive service when
using two (or more) different client (IPv4 and IPv6) addresses.

However, for your draft, couldn't we just eliminate any attempt to
determine if any hosts are v4-only or not, and always synthesize the
IPv4 DNS answers?

I'm not saying I'm in favor of the mechanism overall, just saying we
could avoid the unnecessary and error-prone step of trying to
determine if a host is v4 only.

Does that make sense?

Thanks,
Dave


On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
 wrote:
>
> Hi all,
>
> We have published a new version of this document, taking in consideration=
 a few inputs, clarified some examples, nits, etc.
>
> https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches=
/?include_text=3D1
>
> Regards,
> Jordi
>
>
>
>
> =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
>
>
>     A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
>     has been successfully submitted by Jordi Palet Martinez and posted to=
 the
>     IETF repository.
>
>     Name:               draft-palet-v6ops-464xlat-opt-cdn-caches
>     Revision:   01
>     Title:              464XLAT Optimization for CDNs/Caches
>     Document date:      2019-03-25
>     Group:              Individual Submission
>     Pages:              10
>     URL:            https://www.ietf.org/internet-drafts/draft-palet-v6op=
s-464xlat-opt-cdn-caches-01.txt
>     Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-46=
4xlat-opt-cdn-caches/
>     Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat=
-opt-cdn-caches-01
>     Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6o=
ps-464xlat-opt-cdn-caches
>     Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops=
-464xlat-opt-cdn-caches-01
>
>     Abstract:
>        This document describes the drawbacks of IP/ICMP Translation
>        Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
>        applications initiate traffic flows to dual-stack CDNs (Content
>        Delivery Networks) or Caches, which are forced to be translated ba=
ck
>        to IPv4 by a NAT64.  The document proposes possible solutions to
>        avoid that.
>
>
>
>
>     Please note that it may take a couple of minutes from the time of sub=
mission
>     until the htmlized version and diff are available at tools.ietf.org.
>
>     The IETF Secretariat
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or c=
onfidential. The information is intended to be for the exclusive use of the=
 individual(s) named above and further non-explicilty authorized disclosure=
, copying, distribution or use of the contents of this information, even if=
 partially, including attached files, is strictly prohibited and will be co=
nsidered a criminal offense. If you are not the intended recipient be aware=
 that any disclosure, copying, distribution or use of the contents of this =
information, even if partially, including attached files, is strictly prohi=
bited, will be considered a criminal offense, so you must reply to the orig=
inal sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--

dave@plonka.us  http://www.cs.wisc.edu/~plonka/

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


From nobody Thu Mar 28 07:58: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 1A5D11204DE for ; Thu, 28 Mar 2019 07:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 ABZptzg-gABi for ; Thu, 28 Mar 2019 07:58:31 -0700 (PDT)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0: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 7D99D12001B for ; Thu, 28 Mar 2019 07:58:31 -0700 (PDT)
Received: by mail-it1-x132.google.com with SMTP id z126so6455720itd.5 for ; Thu, 28 Mar 2019 07:58:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=AASf/IBTHTwMmrp5sRNUtN+SjqBpuI/5eYsgb35s8Bs=; b=s6sI3nj8s6SKdBkB0viuQDlolewbAf2WmIfYuu7uM/Kco2Gs6llNI4ImSlarz5uMrg VDMGbBKLjaTcGLCVoHp1cr31aLUf/VW3QtvIczbLE0/YSWgP6wIA0eHFoaQ3Jf4y+DDW x7r5JLmX+Ra21bePphyntuVZg8cEBchJ9DoAZoZpb/kr2KQ6OtYn/C2T4eL4znWyAM80 BdNN9YjaVGLeocAS9uyNTIh3MXfjbq7z8MEU3zd6odu73znI8MNupDteOdjCoTdVQyXh PhqwQpMtbHTEkF5Im0CjCxyghCn6b2WhyjokE+v5kQwe/NHg1tdHD1lkYabpw2Wm8t+Z svZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AASf/IBTHTwMmrp5sRNUtN+SjqBpuI/5eYsgb35s8Bs=; b=cj1mdQPgiWZdYc50XUJobEdjeROyzsTH7g5LHS+DZaXxhkjtAQpvMCEIZVEqgDGuW3 MFzUeGTT6OyB0VCCeH/Hho0nBLIfRKTDHoY8SOzcLSqq7n8OfoxjFBJxuhGcBMgApI4m muXPtFYmX9U7RAaiKhaqYWpvd6DWYs+zwo/7nD+EqywZWEH7ZcUAJa20MdmDdKSTCeHK fGlVWJwOswUGemSuuwHXlZnrRw/CfzxT9ROmQ/M55vqQcrer7OR+wnsacckekk0Ij8b5 wdwOtA1gGIL67uulEBd8pesb+G9dKde4EyqyO05NYLEghfTR/a7lUzZMV73V3JIrRV/f Pe8w==
X-Gm-Message-State: APjAAAX13MmJ/Jfzqsoh+/ZaOD2wo7pEmRrnWAPUzYtXvxmMQccRd9Yt mtJ9oDjT2QqxSC8lBfYyx8owWrchruZOf6aWFTCPrQ==
X-Google-Smtp-Source: APXvYqy8iA3HO2Hm9MAZxwByBQ9D6cIUqqn9JZy66exuYKrRtyVMxAssSuJndUbzRVwqtLZHnsWPumZ51LGOXxwL4n0=
X-Received: by 2002:a24:7688:: with SMTP id z130mr348031itb.57.1553785110618;  Thu, 28 Mar 2019 07:58:30 -0700 (PDT)
MIME-Version: 1.0
From: Ca By 
Date: Thu, 28 Mar 2019 07:58:19 -0700
Message-ID: 
To: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary="000000000000936676058528c96d"
Archived-At: 
Subject: [v6ops] 464XLAT in wireless home broadband
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 14:58:34 -0000

--000000000000936676058528c96d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just FYI since people in this group may be interested in on-going ipv6
deployments.  Also, i am not a spokesperson for anyone.

According to Reddit (which you may not cite for your end to term homework
assignment), T-Mobile US has launched a 464XLAT LTE home broadband product.
T-Mobile=E2=80=99s handset portfolio has been 100% 464xlat (or similar) for=
 a few
years now, so not surprising that architecrure is being reused in the home
context.


https://www.reddit.com/r/tmobile/comments/b66f15/home_internet_kit_has_arri=
ved_and_setup_and_using/?sort=3Dnew

--000000000000936676058528c96d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Just FYI since people in this group may be interested in =
on-going ipv6 deployments.=C2=A0 Also, i am not a spokesperson for anyone.=
=C2=A0

According to Redd=
it (which you may not cite for your end to term homework assignment), T-Mob=
ile US has launched a 464XLAT LTE home broadband product. T-Mobile=E2=80=99=
s handset portfolio has been 100% 464xlat (or similar) for a few years now,=
 so not surprising that architecrure is being reused in the home context.=
=C2=A0





--000000000000936676058528c96d--


From nobody Thu Mar 28 08:01:58 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05CD12003E for ; Thu, 28 Mar 2019 08:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiljzoxvgN1k for ; Thu, 28 Mar 2019 08:01:53 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 AAE22120013 for ; Thu, 28 Mar 2019 08:01:52 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id w15so4428380wmc.3 for ; Thu, 28 Mar 2019 08:01:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=23YvWVd8vt6jUKdJp3okLkI9C1+tJ+joeyKFF4EEVvY=; b=DGlIE9l52HXIM6T1ljeRUMVlFxJoKL9zVVvNU/v/QvHyHJVNsbCcYWm4jFXbQSekIL Fp2zq8OorXk7nTGSKWiT/W1ouKz/0C+Smi/lVUAd5ajoav1U5X6+HIj+MzT34hus78s8 zKsXovb/JRrpy6pIKk21rffYw6NQteRDFmCdY8Zqm8mvWXHyOJXbrDSxdW1ffgcieBmN zT3mWVo6brDSYUZaIcmbA3ttBuynsw99gkzUr5D8R3NFG3AhC7VfNT7LzNO70Tjef+cx xkqD5x2Rrugq/2VK3yRhSeOdRJzOfF3SsBebDWeaEYBEAqdukjLa9DCyetpFVc8wgZQK QkNw==
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=23YvWVd8vt6jUKdJp3okLkI9C1+tJ+joeyKFF4EEVvY=; b=nGQayhblsBkyrBurszkc5fjyIZo9moOG0SfInYYUPP5MbJ4qWf9aTH3K11GtElrk7a 36k4KKCl0ibXRYNO3whrpn5tfRTZsij+F9L6bb1FQd2UAmXhFbcWKbej43bg64v2kd+d iuCdAjylA3XyC6gTMHlL6Rd1sj6O0fN7aAXxBk5bfgidn2Flp6m7uC3pyx/o93VUVBS5 v9dLD0ZKoLzx6ZFqvQvcVE7EjyHMMAs8fPhlLQNeEl1FMMCqHl3OQpsvcJK3Y3uecqvP O/X6uR6jCRiHgog/1F75xPH9hL/+Nxa1ncu8QTKydUihlMmZUAOGjGgM3deikq5OHc5p VUMw==
X-Gm-Message-State: APjAAAXXuNl1g+st9jkdLeo2A5y1WJTBEH/qOUwWdoeImqGzbNR5rFsn NVvqfcI+4ZQsYCxiaRdQk/KDQx0WbISrb83R0umBaLfzQ5SLhx9U
X-Google-Smtp-Source: APXvYqw1SvOeKzR4kyi1dLfMbVQT9hPk97O6rHqVAGxp6rwmeE+g9odymMB7K/15vtWadmKxkzT/Q9gZJiVv4y3aRAc=
X-Received: by 2002:a1c:a993:: with SMTP id s141mr297806wme.152.1553785310881;  Thu, 28 Mar 2019 08:01:50 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Lorenzo Colitti 
Date: Fri, 29 Mar 2019 00:01:37 +0900
Message-ID: 
To: Ca By 
Cc: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary="00000000000083a4b6058528d574"
Archived-At: 
Subject: Re: [v6ops] 464XLAT in wireless home broadband
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 15:01:56 -0000

--00000000000083a4b6058528d574
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Heh. 464xlat is pretty much the worst transition mechanism, but hey, IPv4
is legacy, so...

BTW, thoughts on
https://tools.ietf.org/html/draft-pref64folks-6man-ra-pref64-02 ? Seems to
fit very well with this sort of thing.

On Fri, Mar 29, 2019 at 12:00 AM Ca By  wrote:

> Just FYI since people in this group may be interested in on-going ipv6
> deployments.  Also, i am not a spokesperson for anyone.
>
> According to Reddit (which you may not cite for your end to term homework
> assignment), T-Mobile US has launched a 464XLAT LTE home broadband produc=
t.
> T-Mobile=E2=80=99s handset portfolio has been 100% 464xlat (or similar) f=
or a few
> years now, so not surprising that architecrure is being reused in the hom=
e
> context.
>
>
>
> https://www..reddit.com/r/tmobile/comments/b66f15/home_internet_kit_has_a=
rrived_and_setup_and_using/?sort=3Dnew
> 
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--00000000000083a4b6058528d574
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Heh. 464xlat is pretty much the worst tra=
nsition mechanism, but hey, IPv4 is legacy, so...

BTW, t=
houghts on https://tools.ietf.org/html/draft-pref64folks-6man-ra-pref64-02=
 ? Seems to fit very well with this sort of thing.
On Fri, M=
ar 29, 2019 at 12:00 AM Ca By <cb.=
list6@gmail.com> wrote:
Just FYI since people in this group may be=
 interested in on-going ipv6 deployments.=C2=A0 Also, i am not a spokespers=
on for anyone.=C2=A0

Acc=
ording to Reddit (which you may not cite for your end to term homework assi=
gnment), T-Mobile US has launched a 464XLAT LTE home broadband product. T-M=
obile=E2=80=99s handset portfolio has been 100% 464xlat (or similar) for a =
few years now, so not surprising that architecrure is being reused in the h=
ome context.=C2=A0



--00000000000083a4b6058528d574--


From nobody Thu Mar 28 08:14:15 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8985A1204C2 for ; Thu, 28 Mar 2019 08:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 ZLnyrdJ9uuJy for ; Thu, 28 Mar 2019 08:14:04 -0700 (PDT)
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 08E781204AF for ; Thu, 28 Mar 2019 08:14:04 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id w15so6653924itc.0 for ; Thu, 28 Mar 2019 08:14:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aMWnufrbrFgj3lDNsnELwmgU2z5sXjcD4wd9o6l7NtE=; b=mcoT6mM+KC6asWQgQlhI/EBItfOH036mSQCZ2dST3mOfXb15KzGMeClTVgps02C0PU kJpXUdSRCR8Ouig6eM3cyt9Y0xbOONSqYrMs06zUj8mttl9MQBmezRVmAUT/H2tyn7u9 VygJxoyt6IQHgQiQNkF1CKQyqzJfXHu6o1on4dDCw5G0++Avo9V6nW9uwwbkS+iXYUI3 cI+Pb2QeIXmtVpG/kjARcVhzTLF0tB1dgwGty5GeVr3XPSy5dPJh+/NraY593zJdjrh9 wtD3qnCmzw6zpOw8ms/f4lz5a8nSe8YtcZ/88Cujt0R/ZI3Olmz7aev6nYXuUwwpaJBx iXUA==
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=aMWnufrbrFgj3lDNsnELwmgU2z5sXjcD4wd9o6l7NtE=; b=JzrvMx1gSTzNimQd8U1/1+xtWiSnPD+LrgyCd/2HBhdSUlgqKHoFt/dl5zdD1IlpoP +aS7Q3c7FMDpITmJAtfYJm9f58Huu9PsLtlwwRGfIbHnifJoowtrzcG0S4kSnkYDQvy+ ACmSnVSQY9YMxtFcGRKMVNZu5G3aFP9kcUzBlaKApoH2g1R79fPhCcYNDuUh8sRMFZs/ /AxWqymNCkPJYQJriLnu3uK0WTbkSS5y9h2EPZj8e1ClsNJ4pxg2VA9eI6UCtjHIUTX5 oB4q2qon2fV85D7fsb9oUrTOwV+r6hbOhRsyBYj3AYcio9Xb6xRzXTZqv+lw1+pGQvr3 p0RQ==
X-Gm-Message-State: APjAAAWkT/gz+7EVvznFtpTvj7QE+W6btiJjNZAK/40K4t1p7O0ggK04 +ATUjcTlatLPOw+MRRrs6WcRWu+3T4l8/DSZ3aHyOQ==
X-Google-Smtp-Source: APXvYqyxSfzBruZXrLpBSHghtKsKu02ZmEmIi8ehpBIlmFpcRMH/FvftnATgk2Xd6jbdco6/k6QoYa7ZyrcmWqPREK8=
X-Received: by 2002:a24:2a88:: with SMTP id w130mr402861itw.95.1553786043312;  Thu, 28 Mar 2019 08:14:03 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Ca By 
Date: Thu, 28 Mar 2019 08:13:52 -0700
Message-ID: 
To: Lorenzo Colitti 
Cc: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary="0000000000002b311905852901c8"
Archived-At: 
Subject: Re: [v6ops] 464XLAT in wireless home broadband
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 15:14:14 -0000

--0000000000002b311905852901c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 28, 2019 at 8:01 AM Lorenzo Colitti  wrote:

> Heh. 464xlat is pretty much the worst transition mechanism, but hey, IPv4
> is legacy, so...
>

 Vint Cerf took the blame for ipv4 being poorly designed =E2=80=94 =E2=80=
=9Cit was only an
experiment=E2=80=9D.

Fortunately, the Reddit people say that the ipv6 is unencumbered. I will
note that  rfc7278 is also in use, aka 64share.

RA pref64 is fine, i support.  Perhaps it will be included in 6G or 7G. As
we know, IETF first.


> BTW, thoughts on
> https://tools.ietf.org/html/draft-pref64folks-6man-ra-pref64-02 ? Seems
> to fit very well with this sort of thing.
>
> On Fri, Mar 29, 2019 at 12:00 AM Ca By  wrote:
>
>> Just FYI since people in this group may be interested in on-going ipv6
>> deployments.  Also, i am not a spokesperson for anyone.
>>
>> According to Reddit (which you may not cite for your end to term homewor=
k
>> assignment), T-Mobile US has launched a 464XLAT LTE home broadband produ=
ct.
>> T-Mobile=E2=80=99s handset portfolio has been 100% 464xlat (or similar) =
for a few
>> years now, so not surprising that architecrure is being reused in the ho=
me
>> context.
>>
>>
>>
>> https://www..reddit.com/r/tmobile/comments/b66f15/home_internet_kit_has_=
arrived_and_setup_and_using/?sort=3Dnew
>> 
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>

--0000000000002b311905852901c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Mar 28, 2019 at 8:01 AM Lorenzo Colitti <lorenzo@google.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
Heh. 464xla=
t is pretty much the worst transition mechanism, but hey, IPv4 is legacy, s=
o...

=
=C2=A0Vint Cerf took the blame for ipv4 being poorly designed =E2=80=94 =E2=
=80=9Cit was only an experiment=E2=80=9D. =C2=A0
Fortunately, the Reddit people say that the ipv6 i=
s unencumbered. I will note that =C2=A0rfc7278 is also in use, aka 64share.=
=C2=A0

RA pref64 is fine=
, i support.=C2=A0 Perhaps it will be included in 6G or 7G. As we know, IET=
F first.=C2=A0


BTW, thoughts on =
https://tools.ietf.org/html/draft-pref64folks-6man-ra-pr=
ef64-02 ? Seems to fit very well with this sort of thing.

On=
 Fri, Mar 29, 2019 at 12:00 AM Ca By <cb.list6@gmail.com> wrote:
Just FYI since pe=
ople in this group may be interested in on-going ipv6 deployments.=C2=A0 Al=
so, i am not a spokesperson for anyone.=C2=A0

According to Reddit (which you may not cite for your =
end to term homework assignment), T-Mobile US has launched a 464XLAT LTE ho=
me broadband product. T-Mobile=E2=80=99s handset portfolio has been 100% 46=
4xlat (or similar) for a few years now, so not surprising that architecrure=
 is being reused in the home context.=C2=A0




--0000000000002b311905852901c8--


From nobody Thu Mar 28 08:49: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 D8265120270 for ; Thu, 28 Mar 2019 08:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ezIiLh4BRRKY for ; Thu, 28 Mar 2019 08:49:32 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80317120114 for ; Thu, 28 Mar 2019 08:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553788169; x=1554392969; 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=E0M/vWsA DE91yAYfuPZrKdQcMG2bAGp8oFqvLExWf0k=; b=Ls29nf503ySkdeGRP9679+14 SBYDtLQZ1tbzUpxMfNzgnDq2YDfdLBkgvj+nf4J2AIdlQ74KqfOZ41fu7bZ+sbvq Z7vEbSEm8UI/0HFfXXObHtf6QhGM6MiRFjkk+rzg2LOUSEOfEVFYOWzQPtW6VhTt rZeOsQW1LG5yJVpMVT4=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 28 Mar 2019 16:49:29 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 28 Mar 2019 16:49:29 +0100
Received: from [31.133.128.251] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006201769.msg for ; Thu, 28 Mar 2019 16:49:27 +0100
X-MDRemoteIP: 2001:67c:370:128:dd46:ef30:3f8:a45e
X-MDHelo: [31.133.128.251]
X-MDArrival-Date: Thu, 28 Mar 2019 16:49:27 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1990f428a0=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Thu, 28 Mar 2019 16:49:24 +0100
From: JORDI PALET MARTINEZ 
To: IPv6 Operations 
Message-ID: 
Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
References: <155352271867.29069.14575634631344292386.idtracker@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] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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, 28 Mar 2019 15:49:35 -0000

Hi Dave,

After the meeting, I figured out that that's probably easier and no need to=
 determine if it is an IPv4-only host.

We can just create the EAMT entry for any A request if there is a correspon=
ding AAAA which doesn't contain the WKP or NSP. This means that the end-hos=
t (CDN) is dual-stacked.

Then any host using the A record will automatically get the NAT46 translate=
d to the "real" AAAA, not the one with the WKP or NSP, so we fulfil the int=
ended optimization not requiring knowing if the host is IPv4-only.

I think that's what you are meaning?

The other think is how to select what AAAA to use if there are several.

I really think it will be interesting to get some co-authors, or at least g=
ood inputs from CDN/caches operators on this.

Regards,
Jordi
=20
=20

=EF=BB=BFEl 28/3/19 15:35, "Dave Plonka"  escribi=C3=B3:

    Hi Jordi -
   =20
    Thanks for this draft presentation in v6ops.
   =20
    As we mentioned in the v6ops meeting, I don't think a CPE (or any
    remote host) can reliably determine if a given IPv4 DNS client is an
    IPv4-only host.
   =20
    For one, this is because dual-stack hosts have at least two different
    IP addresses (v4 and v6), as you know, and there isn't a simple way to
    remotely determine that a given IPv4 address and a given IPv6 address
    are actually bound to the same host's interface(s), or even to enforce
    that a dual-stack host will query the same DNS recursive service when
    using two (or more) different client (IPv4 and IPv6) addresses.
   =20
    However, for your draft, couldn't we just eliminate any attempt to
    determine if any hosts are v4-only or not, and always synthesize the
    IPv4 DNS answers?
   =20
    I'm not saying I'm in favor of the mechanism overall, just saying we
    could avoid the unnecessary and error-prone step of trying to
    determine if a host is v4 only.
   =20
    Does that make sense?
   =20
    Thanks,
    Dave
   =20
   =20
    On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
     wrote:
    >
    > Hi all,
    >
    > We have published a new version of this document, taking in considera=
tion a few inputs, clarified some examples, nits, etc.
    >
    > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-ca=
ches/?include_text=3D1
    >
    > Regards,
    > Jordi
    >
    >
    >
    >
    > =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
    >
    >
    >     A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-01=
.txt
    >     has been successfully submitted by Jordi Palet Martinez and poste=
d to the
    >     IETF repository.
    >
    >     Name:               draft-palet-v6ops-464xlat-opt-cdn-caches
    >     Revision:   01
    >     Title:              464XLAT Optimization for CDNs/Caches
    >     Document date:      2019-03-25
    >     Group:              Individual Submission
    >     Pages:              10
    >     URL:            https://www.ietf.org/internet-drafts/draft-palet-=
v6ops-464xlat-opt-cdn-caches-01.txt
    >     Status:         https://datatracker.ietf.org/doc/draft-palet-v6op=
s-464xlat-opt-cdn-caches/
    >     Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464=
xlat-opt-cdn-caches-01
    >     Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet=
-v6ops-464xlat-opt-cdn-caches
    >     Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v=
6ops-464xlat-opt-cdn-caches-01
    >
    >     Abstract:
    >        This document describes the drawbacks of IP/ICMP Translation
    >        Algorithm (SIIT), when used as a NAT46, and IPv4-only devices =
or
    >        applications initiate traffic flows to dual-stack CDNs (Conten=
t
    >        Delivery Networks) or Caches, which are forced to be translate=
d back
    >        to IPv4 by a NAT64.  The document proposes possible solutions =
to
    >        avoid that.
    >
    >
    >
    >
    >     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.o=
rg.
    >
    >     The IETF Secretariat
    >
    >
    >
    >
    >
    > **********************************************
    > 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 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.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
    --
   =20
    dave@plonka.us  http://www.cs.wisc.edu/~plonka/
   =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 Mar 28 09:11: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 512C01202AD for ; Thu, 28 Mar 2019 09:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 IXLAdWwwsduZ for ; Thu, 28 Mar 2019 09:11:21 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475A312008A for ; Thu, 28 Mar 2019 09:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553789470; x=1554394270; 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=9zyZ8VF3 d8a7gJdtzU0eatvXbyEmAacU4ae7TboB5Oo=; b=dhICeaonRq4bg4+cihd3ANg3 XyNWQ1BjIElc7eIqEvnCXK7DWreDBTEtyVO4zSeJTfPaKxuwwRXICEnAAucIA4Dh ECvlen2TZW9+u+sBbkT9OKe/HQqliRCRhjfoVwRx2E7PAznKv++cLpoPJbePtrix Rgg193AM+6TfktegV4w=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 28 Mar 2019 17:11:10 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 28 Mar 2019 17:11:09 +0100
Received: from [31.133.128.251] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006201793.msg for ; Thu, 28 Mar 2019 17:11:09 +0100
X-MDRemoteIP: 2001:67c:370:128:dd46:ef30:3f8:a45e
X-MDHelo: [31.133.128.251]
X-MDArrival-Date: Thu, 28 Mar 2019 17:11:09 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1990f428a0=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Thu, 28 Mar 2019 17:11:03 +0100
From: JORDI PALET MARTINEZ 
To: IPv6 Operations 
Message-ID: 
Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
References: <155352271867.29069.14575634631344292386.idtracker@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] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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, 28 Mar 2019 16:11:26 -0000

Reading more questions raised in the meeting from the etherpad:

1) Mikael mention that Chromecast (and other devices), use a manually confi=
gured DNS such as 8.8.8.8. I'm not sure if Chromecast is dual-stack, if tha=
t's the case, then they will prefer IPv6, so not an issue. Also, if they ar=
e IPv4-only, they still get the optimization with the small change that I m=
ention in my previous email. Instead of creating the EAMT entries by "guess=
ing" if the device is IPv4 only, we just create the entries when there is a=
n A request and the corresponding AAAA is available with a GUA (i.e., not u=
sing the NSP or WKP).

2) Jared indicated that there is more and more work to move DNS from host c=
ontrol to apps. I agree. However, the problem that we are solving is OLD IP=
v4-only (like smartTVs and STBs) that aren't updated to IPv6, even less upd=
ated to use DTLS or DoH, etc.

Once more, the solution must not affect those apps that are dual-stack or u=
se their own "DNS", they just will not get any optimization if they try to =
reach an IPv4 destination.

Regards,
Jordi
=20
=20

=EF=BB=BFEl 28/3/19 16:50, "v6ops en nombre de JORDI PALET MARTINEZ"  escribi=C3=B3:

    Hi Dave,
   =20
    After the meeting, I figured out that that's probably easier and no nee=
d to determine if it is an IPv4-only host.
   =20
    We can just create the EAMT entry for any A request if there is a corre=
sponding AAAA which doesn't contain the WKP or NSP. This means that the end=
-host (CDN) is dual-stacked.
   =20
    Then any host using the A record will automatically get the NAT46 trans=
lated to the "real" AAAA, not the one with the WKP or NSP, so we fulfil the=
 intended optimization not requiring knowing if the host is IPv4-only.
   =20
    I think that's what you are meaning?
   =20
    The other think is how to select what AAAA to use if there are several.
   =20
    I really think it will be interesting to get some co-authors, or at lea=
st good inputs from CDN/caches operators on this.
   =20
    Regards,
    Jordi
    =20
    =20
   =20
    =EF=BB=BFEl 28/3/19 15:35, "Dave Plonka"  escribi=C3=B3=
:
   =20
        Hi Jordi -
       =20
        Thanks for this draft presentation in v6ops.
       =20
        As we mentioned in the v6ops meeting, I don't think a CPE (or any
        remote host) can reliably determine if a given IPv4 DNS client is a=
n
        IPv4-only host.
       =20
        For one, this is because dual-stack hosts have at least two differe=
nt
        IP addresses (v4 and v6), as you know, and there isn't a simple way=
 to
        remotely determine that a given IPv4 address and a given IPv6 addre=
ss
        are actually bound to the same host's interface(s), or even to enfo=
rce
        that a dual-stack host will query the same DNS recursive service wh=
en
        using two (or more) different client (IPv4 and IPv6) addresses.
       =20
        However, for your draft, couldn't we just eliminate any attempt to
        determine if any hosts are v4-only or not, and always synthesize th=
e
        IPv4 DNS answers?
       =20
        I'm not saying I'm in favor of the mechanism overall, just saying w=
e
        could avoid the unnecessary and error-prone step of trying to
        determine if a host is v4 only.
       =20
        Does that make sense?
       =20
        Thanks,
        Dave
       =20
       =20
        On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
         wrote:
        >
        > Hi all,
        >
        > We have published a new version of this document, taking in consi=
deration a few inputs, clarified some examples, nits, etc.
        >
        > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cd=
n-caches/?include_text=3D1
        >
        > Regards,
        > Jordi
        >
        >
        >
        >
        > =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
        >
        >
        >     A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-cache=
s-01.txt
        >     has been successfully submitted by Jordi Palet Martinez and p=
osted to the
        >     IETF repository.
        >
        >     Name:               draft-palet-v6ops-464xlat-opt-cdn-caches
        >     Revision:   01
        >     Title:              464XLAT Optimization for CDNs/Caches
        >     Document date:      2019-03-25
        >     Group:              Individual Submission
        >     Pages:              10
        >     URL:            https://www.ietf.org/internet-drafts/draft-pa=
let-v6ops-464xlat-opt-cdn-caches-01.txt
        >     Status:         https://datatracker.ietf.org/doc/draft-palet-=
v6ops-464xlat-opt-cdn-caches/
        >     Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops=
-464xlat-opt-cdn-caches-01
        >     Htmlized:       https://datatracker.ietf.org/doc/html/draft-p=
alet-v6ops-464xlat-opt-cdn-caches
        >     Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-pal=
et-v6ops-464xlat-opt-cdn-caches-01
        >
        >     Abstract:
        >        This document describes the drawbacks of IP/ICMP Translati=
on
        >        Algorithm (SIIT), when used as a NAT46, and IPv4-only devi=
ces or
        >        applications initiate traffic flows to dual-stack CDNs (Co=
ntent
        >        Delivery Networks) or Caches, which are forced to be trans=
lated back
        >        to IPv4 by a NAT64.  The document proposes possible soluti=
ons to
        >        avoid that.
        >
        >
        >
        >
        >     Please note that it may take a couple of minutes from the tim=
e of submission
        >     until the htmlized version and diff are available at tools.ie=
tf.org.
        >
        >     The IETF Secretariat
        >
        >
        >
        >
        >
        > **********************************************
        > 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 privile=
ged or confidential. The information is intended to be for the exclusive us=
e of the individual(s) named above and further non-explicilty authorized di=
sclosure, copying, distribution or use of the contents of this information,=
 even if partially, including attached files, is strictly prohibited and wi=
ll 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 strict=
ly 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
       =20
       =20
       =20
        --
       =20
        dave@plonka.us  http://www.cs.wisc.edu/~plonka/
       =20
   =20
   =20
   =20
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.theipv6company.com
    The IPv6 Company
   =20
    This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the exclusive use of t=
he individual(s) named above and further non-explicilty authorized disclosu=
re, copying, distribution or use of the contents of this information, even =
if partially, including attached files, is strictly prohibited and will be =
considered a criminal offense. If you are not the intended recipient be awa=
re that any disclosure, copying, distribution or use of the contents of thi=
s information, even if partially, including attached files, is strictly pro=
hibited, will be considered a criminal offense, so you must reply to the or=
iginal sender to inform about this communication and delete it.
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20



**********************************************
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 Mar 28 09:23:23 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBEA1202FA; Thu, 28 Mar 2019 09:23:13 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 W0QHL1hchC7f; Thu, 28 Mar 2019 09:23:11 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 087541202DC; Thu, 28 Mar 2019 09:22:52 -0700 (PDT)
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 m1h9Xnk-0000JfC; Thu, 28 Mar 2019 17:22:48 +0100
Message-Id: 
To: v6ops@ietf.org
Cc: Jen Linkova 
Cc: 6man 
From: Philip Homburg 
Sender: pch-b9D3CB0F5@u-1.phicoh.com
In-reply-to: Your message of "Thu, 28 Mar 2019 21:30:39 +1100 ."  
Date: Thu, 28 Mar 2019 17:22:48 +0100
Archived-At: 
Subject: Re: [v6ops] Thoughts on draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 16:23:14 -0000

>1.3) [additional crazy idea I was playing with...] changing the
>network addressing could be considering as changing the PvD. What if a
>router, when sending RAs, uses LLA which is a stateless hash function
>of PIOs?

It just occurred to me that generating a new random link local address upon
boot would also work. 


From nobody Thu Mar 28 09:50:31 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6D612030E; Thu, 28 Mar 2019 09:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8NbECrJ1D62; Thu, 28 Mar 2019 09:50:16 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49111120366; Thu, 28 Mar 2019 09:50:14 -0700 (PDT)
Received: from [IPv6:2001:67c:1232:144:b044:9b9a:327d:b750] (unknown [IPv6:2001:67c:1232:144:b044:9b9a:327d:b750]) (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 EDDD6826AE; Thu, 28 Mar 2019 17:50:10 +0100 (CET)
To: Jen Linkova , V6 Ops List , 6man 
References: 
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: <30dc60cb-3704-7bb4-d5bc-f54074f4ae58@si6networks.com>
Date: Thu, 28 Mar 2019 17:49:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Thoughts on draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 16:50:28 -0000

Hello, Jen,

Thanks so much for your feedback! Comments in-line....

On 28/3/19 11:30, Jen Linkova wrote:
> I've been thinking about the draft and the renumbering/prefix failure
> problem in general...
> 
> IMHO there is no a single silver bullet so maybe it makes sense to
> look at issues caused by misbehaving CPEs which are not invalidating
> "old" prefixes after getting new prefix (or network  address change in
> general) and prioritize them. All issues are painful but some are more
> painful than others for operators...

Agreed.



> Here is what I've come up with for the scenario when the network
> prefix has changed and the host has now two (or more) addresses from
> different prefixes and not all them belong to the network anymore -
> based on the draft and my experience with that problem:.
> 
> #1: High priority/must have: ensure that the host selects an address
> from the "working" prefix for new sessions.
> 
> #2: Med/High priority, nice to have: preserving existing connections
> or at least explicitly quickly terminate them instead of letting them
> timing out.
> 
> #3: Med/Low priority: ensuing that if the old prefix is reassigned to
> another part of the network, the host can communicate to new owners of
> the prefix

#2 and #3 are essentially the same thing. If you want to talk to the new
owner of the prefix, you have to tear down connections that employ the
stale prefix. i.e., what you do on #2 is an implicit decision on what
you do on #3.



> #4: Preventing the host from exceeding the number of allowed/supported
> # of addresses on the interface.

This is somehow tied to #2-#3 too. If you don't do proper "garbage
collection", eventually you'll hit the limit.



> Problem #1:
> 
> 1.0) Consider doing Happy Eyeballs for source addresses if the host
> has GUAs from more than one /64. What do the host implementors think?
> It would help with other blackholing cases as well..

I wouldn't go this path... at least for *this* issue.




> 1.1) whatever caused the issue, in many scenarious (esp.
> residential/hotsopt deployments) it does not make much sense to have
> PIO lifetime being significantly higher that default router lifetime.
> Therefore two things could be done:
> 
> 
> 1.1.1) Update RFC4861 with smth like:
> 
>     the default value for AdvPreferredLifetime should be Max
> (1.2*AdvDefaultLifetime; 3*MaxRtrAdvInterval)
> 
>     the default value for AdvValidLifetime should be
> Max(1.5**AdvDefaultLifetime; 3*MaxRtrAdvInterval, 2hrs)
> 
> (MAX is used to ensure that deprecating the router does not
> automtically deprecate the prefix if the PIO lifetime is not
> explicitly configured)

This is essentially what Section 5.1.1.2 proposes. We are updating the
I-D so that Section 5.1.1.1 is replaced with a proposal to set the PIO
valid lifetime to the router lifetime.

FWIW, while it would seem to me that there's no need to set the PIO
valid lifetime to a value longer than the router lifetime, I wouldn't
mind to increase it a bit over that, as you suggest.





> 1.2.2) Provide guidleines to operators recommenting putting sensible
> values for the corresponding timers for DHCP-PD leases and CPE
> configs.

Agreed. ANy proposals here?



> 1.3) [additional crazy idea I was playing with...] changing the
> network addressing could be considering as changing the PvD. What if a
> router, when sending RAs, uses LLA which is a stateless hash function
> of PIOs?
> 
> So then let's say the router has a prefix P1 configured on the
> interface. It sends RAs with the PIO1 using LLA1 = f(P1).
> 
> Then the prefix has changed (reboot, crash, uplink flap - or even
> worse, the whole CPE was replaced). The router (the same or new one)
> has now another prefix P2 on the interface. Then it wll be sending RAs
> from LLA2 = f(P2). RFC8028-compliant hosts (aka supporting rule 5.5)
> would invalidate LLA1 as a next-hop by using NUD and by starting using
> LLA2 they would select addresses from P2 as the source addresses.

Might be worth exploring, but would seem overkill to address just this
issue.





> Problem #2:
> 
> 2.1) Would it be reasonable to expect a CPE (or an operator, at BNG
> level, for example) to implement a kind of basic BCP38 and send ICMPv6
> error back if the packet coming from the downstream has the source
> IPv6 address from the prefix which is not delegated to that network?
> At least it would give the hosts some clear signal...

Problem here is the semantics of ICMP error messages: they signal soft
errors, rather than hard errors.



> Problem #3
> 
> Not sure how much it's a problem really but 1.1) (see above) should
> help as well as addresses would be invalidated much faster than in 30
> days.

This can be addressed with some version of what we propose in Section
5.1.3 of our I-D.

One variant of that would be to count (say in variable "n")the number of
consecutive RAs that contain PIOs other than the previously advertised
prefix.

we specify N1 and N2.

when n >= N1, we unprefer the address
when N >= N2, we remove the corresponding addresses



> Problem #4:
> 
> Would it be really a problem if problems 1-3 are fixed? If the OS
> limit for valid addresses is too low, maybe the OS needs to be fixed?

Well, I would understand OS vendors arguing: do you really want more
than , say 16 configured prefixes?



> One might say that there is no point of propising any changes on CPEs
> as if they are not doing the right things now they are very unlikely
> to implement the proposed changes correctly. However the main issue is
> related to keeping the state between reboots and/or coordinating
> different components (DHCPv6 client and radvd etc) - and there is a
> case of CPE replacement. Changes which are limited to default values
> changes or modifying just one component (BCP38) might be more
> successful.
> 
> Thoughts?

I do agree that there's no silver bullet and that it would be correct to
attack the problem from different angles.

Your suggestions don't seem to be far from what we are proposing in our
I-D, though. -- we hope that the next rev of the I-D will be more
clearly in line with that...

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 Mar 28 11:55:25 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36DF120314 for ; Thu, 28 Mar 2019 11:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=telecentro.net.ar
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QthRC7hFIbQa for ; Thu, 28 Mar 2019 11:55:21 -0700 (PDT)
Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A6C120313 for ; Thu, 28 Mar 2019 11:55:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0DCF03201FAA; Thu, 28 Mar 2019 15:55:19 -0300 (-03)
Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mhiMWaSvO1rx; Thu, 28 Mar 2019 15:55:18 -0300 (-03)
Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0960E3201FA9; Thu, 28 Mar 2019 15:55:17 -0300 (-03)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 0960E3201FA9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1553799318; bh=UtXeT8bJkqRpr8giIvCwfcV669qax8YRYqPcgdOx7sg=; h=Date:From:To:Message-ID:MIME-Version; b=DBbvFti2R+gySBwp4/P0cfF+wFYMX4rSGj8eE588SuzYzCIeLv3w1mOqAUXk0DTq1 SRa1E/FFyBTVwqrVFDcrjAmXOmLDyZtigqJWhnMMNPnT5srHgjRBhtnoTOJh3OgXn2 +UiuLuA1Jrn2XGB3UQ/ycZg8bhc/LwUUCXJXlg109VOW2ZhHajHX/40u3Rfjj0ZXre 8YhwMEZtaqo+KfJNY+5B9n2+Kx91NjMAfSw4VzXkWNNefrmkRrYD3bH9AhSWKOuX2r ZAPWKjZWkfL+EcxSA/8X0KF02TCADmTzy1dCqsTEI+pRKbdURrOblMYueuESuUhIJK dykSJB66k3fAg==
X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local
Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ixe4C8gn8x9t; Thu, 28 Mar 2019 15:55:17 -0300 (-03)
Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 805F13201FC5; Thu, 28 Mar 2019 15:55:17 -0300 (-03)
Date: Thu, 28 Mar 2019 15:55:16 -0300 (ART)
From: Alejandro D'Egidio 
To: JORDI PALET MARTINEZ 
Cc: "v6ops@ietf.org list" 
Message-ID: <1407270537.230326012.1553799316814.JavaMail.zimbra@telecentro.net.ar>
In-Reply-To: 
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>   
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.210.50.96]
X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC73 (Win)/8.8.8_GA_1703)
Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
Thread-Index: 95l7kMLWb2ymQ4IRtHHpt0iFNkDIzQ==
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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, 28 Mar 2019 18:55:24 -0000

Hello,
Just an additional comment...

----- Mensaje original -----
> De: "JORDI PALET MARTINEZ" 
> Para: "v6ops@ietf.org list" 
> Enviados: Jueves, 28 de Marzo 2019 12:49:24
> Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt

> Hi Dave,
> 
> After the meeting, I figured out that that's probably easier and no need to
> determine if it is an IPv4-only host.
> 
> We can just create the EAMT entry for any A request if there is a corresponding
> AAAA which doesn't contain the WKP or NSP. This means that the end-host (CDN)
> is dual-stacked.
> 
> Then any host using the A record will automatically get the NAT46 translated to
> the "real" AAAA, not the one with the WKP or NSP, so we fulfil the intended
> optimization not requiring knowing if the host is IPv4-only.
> 
> I think that's what you are meaning?
> 
> The other think is how to select what AAAA to use if there are several.
Regarding this, If I'm not wrong in general CDNs offer one Answer because they need to manage the load balancing between servers with DNS answers.


> 
> I really think it will be interesting to get some co-authors, or at least good
> inputs from CDN/caches operators on this.
> 
> Regards,
> Jordi
> 
> 
> 


From nobody Thu Mar 28 13:20: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 92605120344; Thu, 28 Mar 2019 13:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level: 
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyrrH7TaPlX8; Thu, 28 Mar 2019 13:20:29 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 741E1120273; Thu, 28 Mar 2019 13:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [147.230.11.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 7BCA918289EE8; Thu, 28 Mar 2019 21:20:25 +0100 (CET)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: ipv6@ietf.org, V6 Ops List 
Date: Thu, 28 Mar 2019 21:20:16 +0100
Message-ID: <4572212.CHxXTUUyl0@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2609254.40K7Zl7Iqc"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] Thoughts on draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Mar 2019 20:20:32 -0000

--nextPart2609254.40K7Zl7Iqc
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hi,

please see reply inline for mentioned issues.
Dne =C4=8Dtvrtek 28. b=C5=99ezna 2019 11:30:39 CET, Jen Linkova napsal(a):=
=20
> #1: High priority/must have: ensure that the host selects an address
> from the "working" prefix for new sessions.

Wouldn't be just better to add a rule to RFC6724 which would say the longer=
=20
Preferred lifetime wins? Let say between rule #7 and #8?
>=20
> #2: Med/High priority, nice to have: preserving existing connections
> or at least explicitly quickly terminate them instead of letting them
> timing out.

Question is if unknown prefix to the router should be treated according to =
BCP=20
38 - dropped or if it should be treated as special case (for let say home=20
router) and should get rejected. And if so, what should be the code.
>=20
> #3: Med/Low priority: ensuing that if the old prefix is reassigned to
> another part of the network, the host can communicate to new owners of
> the prefix

As valid lifetime should not be longer than PD lease time, then it should n=
ot=20
be a problem. As it should not be leased to another holder before the first=
=20
lease expires.
>=20
> #4: Preventing the host from exceeding the number of allowed/supported
> # of addresses on the interface.

I don't think that we would be able to do that. What I know such limitation=
s=20
were placed there (at least in Linux) as reaction to RA flood attacks. By=20
rising that limitations, OS would became more vulnerable to those.

I think that if we are talking mainly about home network after the CPE. It =
is=20
the false presumption that RA guard is reality there. We as a network peopl=
e=20
might have RA guard deployed at home, but at least what I can tell usual ho=
me=20
network has one router (cheapest available option) and sometimes one=20
unmanageable L2 switch. Same applies to some small enterprises or even some=
=20
medium ones outside telco.

Just a few thoughts:
Do we really need to change the constant of default Pref./valid lifetime by=
=20
another constant? Would it fit all?

Wouldn't be better to specify CPE behavior towards the prefixes received by=
=20
DHCPv6-PD? Like valid lifetime should not exceed in any single moment 1/2 o=
f=20
original lease time and preferred lifetime should not exceed 1/4 and either=
=20
should be valid longer then the lease itself (we have that already). Those=
=20
fractions are just example.

=46rom ISP point of view, I'm quite happy to lease the clients prefix for=20
several days (probably not for the whole month), as I give client stable=20
prefixes, it is not problem for me. In this case having valid lifetime to b=
e a=20
fraction of lease time would at least protect clients devices from=20
deconfiguration of valid prefix by the RA flood (at least for 2 hours). Eve=
n=20
that it doesn't save them the internet connection, at least they would be a=
ble=20
to receive packets.

Maybe it has been already discussed here, in that case I apologies. But 30/=
10=20
minutes seems too strict and uncalled for.

Martin
--nextPart2609254.40K7Zl7Iqc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlydLIAACgkQtRBl6lEd
5VxGQggAtkAdG81P2aAlqkRf++ALwzqdUd/sAyOpT+dPVM2jM9oiuLEIAO01ikT+
Ir5gljSg9yYtUNV0eDT2guEn/cWl8WihbcxWpD8ZGv5Le4jD5rFn9OeoNJTl1BXq
M6Nb61KwpP+45Af139Pp6g//AmZR4uZsdOVqGoMfsl6gO0EeZozVNsoLTJwmvqgq
zDnoA/vfpkq8BPIaYY2EAzk4PK+lBSlWkfchqLt76pr4bX94kus9kL1i/e44ktYq
r0d3xTV4xlGMICXofBIlLDelRY7d40XBw7Fde9Y7lfy7f0REftJ8W07tHw3LRA7/
RZwt5vSFY9FjtqJHBl8NCbghEttV6g==
=fBeQ
-----END PGP SIGNATURE-----

--nextPart2609254.40K7Zl7Iqc--




From nobody Thu Mar 28 14:36: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 933B51202C1 for ; Thu, 28 Mar 2019 14:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kel3weBAR5-U for ; Thu, 28 Mar 2019 14:36:02 -0700 (PDT)
Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B59120255 for ; Thu, 28 Mar 2019 14:36:02 -0700 (PDT)
Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id B8A3A27304; Thu, 28 Mar 2019 22:36:00 +0100 (CET)
Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 84F512E7B3C; Thu, 28 Mar 2019 22:36:00 +0100 (CET)
Received: by ws26.ernw.net (Postfix, from userid 1002) id 639F537F04; Thu, 28 Mar 2019 22:36:00 +0100 (CET)
Date: Thu, 28 Mar 2019 22:36:00 +0100
From: Enno Rey 
To: v6ops@ietf.org
Cc: merike@doubleshotsecurity.com, kk.chittimaneni@gmail.com, evyncke@cisco.com
Message-ID: <20190328213600.GF70134@ernw.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.11.3 (2019-02-01)
Archived-At: 
Subject: [v6ops] draft-ietf-opsec-v6-16
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 21:36:06 -0000

Hi,

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

best

Enno

-- 
Enno Rey

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

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

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


From nobody Thu Mar 28 22:08: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 8EB00120286 for ; Thu, 28 Mar 2019 22:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcQWQcNjvJyK for ; Thu, 28 Mar 2019 22:08:21 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 650DB1201DA for ; Thu, 28 Mar 2019 22:08:21 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id o10so8775673wmc.1 for ; Thu, 28 Mar 2019 22:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=qYE5qR/bh/jrRi4SsEnta+o3TFN7CylR2Vfq0u6jYgE=; b=N8eVeK9DEW8Xm9vxQ0m5RTM0kq89+WsLcnlvyuItDfxoINZAqLgvXLaHOQB/sYtFpi kq9Dq0ErDSA7QXTFc29I/Yqb1JWbuZoGQDMXPphVMUxyq5/A5PLcwXm7W7D+YRbvzM7h Z5PwQC7ZFIEhTXDyAp8STcAnsb187pjN8Cvn9psNvwk+uWjcz4Xrzl99zFLSbknjb9IK oN/xSvSCRU+ge0lA1kTXl4aIUjQsHMMkN7Ot2XWsRQ+T8ES0vqYAb2JmkVbvyPI/mWH1 eQRCN+g8Ttk1cMav81X5n4BRIY3Tipa7cDo44aNrAzWP0QuJW5dk+vIxarlXMM/PG/Dq tzzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=qYE5qR/bh/jrRi4SsEnta+o3TFN7CylR2Vfq0u6jYgE=; b=m3CcV/BdExp9SZjvi2h+d42gNpCaQvUgI7gxBvK3EUj55n/ujNh0KzM6pLQCH0q36o bdsihnFoC8qs5w0PQF2vBV/sPhoMih7TiSw+f+ffTai58cTL3wJi3MD2JoSi2t56Kcm/ CtAPi9avC+0rmXb3t6qjZ+dScajMXbeMHuf5EG/xsSr/TnfNLFgLoAQMyp+kA+pt4Tcm A5PJZGY0a9CtOp/7Pxn9IUFAv903+sVGlc+h/WVulUNtMsdTQARVCdpMSKNdwtAmMTey yVxxAM1Pmtg8JbvgnPSB8aaDJmWJvAQQs7WxaA94aEObN+CYujScVsnDxiHSd/ztai51 AM7Q==
X-Gm-Message-State: APjAAAW7klpMYtMou8ZLdAVeYs2/3DsdDJTyrdla+HRQBFmYrkDej/Q1 lkJwf6dkywm8RYFS01miSFe5FCwnbnw=
X-Google-Smtp-Source: APXvYqwEXyaJ1+jFaJiSiZr2uDehny/ZIo9q3mEo/cvcT4OXG7/1P8AV7HvX8i2DiXYGx/bUFAPB5A==
X-Received: by 2002:a05:600c:2055:: with SMTP id p21mr1290390wmg.118.1553836099532;  Thu, 28 Mar 2019 22:08:19 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id e193sm1763557wmg.18.2019.03.28.22.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:08:18 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_40CEEB21-818A-4E4C-9DEA-ECE71EB25409"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: 
Date: Fri, 29 Mar 2019 06:08:15 +0100
Cc: Massimiliano Stucchi , "STARK, BARBARA H" 
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Minutes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:08:24 -0000

--Apple-Mail=_40CEEB21-818A-4E4C-9DEA-ECE71EB25409
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I have uploaded minutes from yesterday's meeting at =
https://datatracker.ietf.org/doc/minutes-104-v6ops/. If it needs edits, =
please copy the list on your thoughts.

Thanks Barbara and Massimiliano!
=
--------------------------------------------------------------------------=
------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu


--Apple-Mail=_40CEEB21-818A-4E4C-9DEA-ECE71EB25409
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+AFAlydqD8ACgkQEhdRnd2G
P+C1vw//fAbKj7th4VjCZEBiyt6G00rWWBSNYevVqeqI5Xk2g9oyAKMfCbefHaR/
MDvpZRxUQ2m4CI7wI5MR4yPbFS/un8rVoyvegZsLGWsRpyaCF43YV6ijJd8+vGzV
+9oE29es0LwJZiE/LUVOaJMOSDNx+r7W4tUfGANA1kTHdiTx8k9TQRuIA2gEkeE4
BYL0JlwoiA1PzZToo3hyjAmbYURyv3yVc3hfJ+wACwv2m6LFPgUeDYSZbwhdXqyg
NuuUAY6AOENFZzr8JtuaVRSz/I+FnjjeNxd0Rz6T2UAnfp5x+00vzHZwvunqMCde
4Wg8rwWG3iOoZfkVTu1MrxB7LJojp5na4W3bVEXRoG7sWbJTC5MMQRkT//VNVp5M
AcktjRKDz6WJxqo4FRMUtJBwwYjTT4gocQQOE5ulvHlvQNMLHrn0tS8JigGGYXSt
3Evwx4C5KvUWQ1Rn9pQ8q8q9kvvGPFE98mShEJrTSkuH33sRu0UbJ03vzicZpvfa
1mCakTt5dugRQMCXL9Jxt/ImsGQ2Wpb7+VaIA5PHHjegxylMZKUK+1hVFS90rN/2
JGzx+BAQpjroKZPIQGzHvruT3wm3ORl3IGxGXYqQ+6w7Fgu3ujPCO0NCExlDAKSN
9sZWelP+9bFq5JzkGvWR0zHEZdryrBk9vjbm3Dvk7jASX57D6ng=
=6pQx
-----END PGP SIGNATURE-----

--Apple-Mail=_40CEEB21-818A-4E4C-9DEA-ECE71EB25409--


From nobody Thu Mar 28 22:18: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 89AB212018F for ; Thu, 28 Mar 2019 22:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BkHrjEWDNmg for ; Thu, 28 Mar 2019 22:18:43 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A961120158 for ; Thu, 28 Mar 2019 22:18:43 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id w10so973506wrm.4 for ; Thu, 28 Mar 2019 22:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=wKRD84ylwBXAJKQbz1UD1Lz8OXOXPwvMq+HlPO/IwYM=; b=d75sktfuBDW5stkrb7DhGbsjQCOP1xiXoD1smqRczKVc9gbw56ssoKsfg7f+9Z7wCb VGpPU16AyU2FXOSUrXBDvuLWMBRjfruI/404vk1WUDDP0BlLzGr934dN84utrAgFrC8d kUFBQDLmiDO5N3Ggq6vMjfuCQut3U9353+HwYND5aX+Swsh3Xkg4O002ujf+sqlABAng mR7FwdGI/cXOTwdRnJJhEKIWPtAOWogrrOsHQClPyI503S6vsJ9nghbXDlt8WaImsGiA Ahpb1TdCBgChbvRiQr9Z4ZwVdtCdXjiJ6Y5da7hNMNvjV/3id4XHX8LsNNQHvkJbtIrI tM5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=wKRD84ylwBXAJKQbz1UD1Lz8OXOXPwvMq+HlPO/IwYM=; b=mk/YDufW53ioBZi6nkwDNoWPTCTuq4NLTf8GrX6ui7Nf251Wnu0vRn0LJhbEsg0jy3 s/fT9fa3N/Dj2bCUl/iUSgYz54dA7b1IzCpyttLv34MK0ilacDF3oCwQLY/JLWjEKLRB 3Fa1uPrWbsE9I2zrAQAAUhmUu1hzWRX76xmw9+PGZhbZoWJjVW+SOyqSEN2YJLWglLP8 oTqJOV2FCNObAvRCWuDIGQETDqd8e0AoXOk3uEu8WvDGf6JX9KR4bHgEXqNh4xdFdhng wZlCXX9H5zytHSax//K6NB+lOBKD5mVkjzg4vk2j9yrW701gSPt2UbZNUCaPWjJyiB6g 9+GA==
X-Gm-Message-State: APjAAAUApVpcYr7seApktrx0Ms3jtXPiBE7FA8m8bWbMVikE33pk1yGJ kpOFq9YZuX+LCIRZbCr4lCiS3OmVvys=
X-Google-Smtp-Source: APXvYqwe5osSZ6tL7X91HHUFHEFp6ArAZwO0zijHlM9O6RfOtHvI2x+NMMM3e1/EnUDUCLJplzaqDw==
X-Received: by 2002:a5d:684e:: with SMTP id o14mr31157302wrw.138.1553836721835;  Thu, 28 Mar 2019 22:18:41 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id x14sm1160037wmj.3.2019.03.28.22.18.39 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:18:40 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_9A666857-70EB-4861-A4D9-4AE90E41F066"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: 
Date: Fri, 29 Mar 2019 06:18:37 +0100
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] draft-ietf-opsec-v6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:18:45 -0000

--Apple-Mail=_9A666857-70EB-4861-A4D9-4AE90E41F066
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Yesterday, the authors of an opec draft asked us for comments on their =
draft, which is in a second WGLC in opec (opsec@ietf.org). You may have =
missed the character string:

https://datatracker.ietf.org/doc/draft-ietf-opsec-v6
https://tools.ietf.org/html/draft-ietf-opsec-v6
  "Operational Security Considerations for IPv6 Networks", Eric Vyncke,
  Chittimaneni Kk, Merike Kaeo, Enno Rey, 2019-03-11,

I'd encourage people to read it and comment on the opec list.

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


--Apple-Mail=_9A666857-70EB-4861-A4D9-4AE90E41F066
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+AFAlydqq0ACgkQEhdRnd2G
P+BV4RAAnYEPkGeyBrXGWWLRcP2LfCVhONVVI/0mX8wQLllNzWim5UF+0yjGGZ9w
tbPlmeiwhp74kiA7tSSq/4wNT1LaQ99dMleqtY27OP6G1PsYgmMLGMbrsvx6xmHd
xGalTPSh3061pkF5OBNot79effzc2/Ak0vOEOvN8/ZprkfyGilBWJgCNy1M0EDcV
37YgCta2OUAM6mkzxRAXQ8H4g3VwZvk4r6+RwVvUc7bKQGYlXGVeJY0G/06biuvw
PxjWZD49h5gKDskU+zGi9wk6pEk8hbbZvzxz0edVISYfEHXuClIczscf2SnatC6E
ANoQlOQs//nBgglIWyep9NWfCjzyK/ryNGwRNgRdbGQJpH7Np2CrvpB7fIpV4vOB
n2Bk3HLUugSG66sGCuM0cfyFICA9HnaKo4zWaAuR0C9k7NOpqzLU9Oou8WidC1jt
D4q5BoFYUlU1EfDsi+guhqypgbTah7fp5g+9hZ8dx2xOEhV4Owl1keqT2sdvyusV
omesxgf6l5Zpt4JFjhWlOUTMd/o1Oxpn+BDhN1C77/5KVuxDw4s99utWk/yfSzLj
rCHuwgbB2PLx7dMpLe9PfrvqbPXDufwFON9JVe7Sk8p2qxzEgskmVxQ/m6zl8m6W
fF2qVCs+FoX2KQQ/i7claAfYjFDJRj5GuhRR3XcWZ/GN7mJnYzo=
=ll3v
-----END PGP SIGNATURE-----

--Apple-Mail=_9A666857-70EB-4861-A4D9-4AE90E41F066--


From nobody Thu Mar 28 22:37: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 74C2212018F for ; Thu, 28 Mar 2019 22:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmQT1ND5sXgS for ; Thu, 28 Mar 2019 22:37:03 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC09120132 for ; Thu, 28 Mar 2019 22:37:03 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id y197so1311822wmd.0 for ; Thu, 28 Mar 2019 22:37:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=VULoCS5yM+3jY8jFEECLK4xk3m5ZNts7cJaFdwyF5Lc=; b=c7QZAYmN8qu3NknvMPbENtknzltyNEx0Bo+CO5ezAvz7xQnTX+A2VYoHcFvKLUARn8 qpEHCAXQG/nZe4TdlT+m+GfEyg83+nhPevzRx4XeZWmj6dMcwNp0QFdQMZDoRHkEl3Ev QyvozFtVHYMbVq6QS0mpOK7LY72hHy+kv5XCHQs0f5zo1ycszTsjfr6vtEfn37EC9AYP 59Zr8IpgqgpjqDIPk5Ebt71+UIvUiqVjmI1P3dTJ7WbrIb0J5XN0X3MelSLbIq6NNtlg rIcToWOPM4XO7oC49s2DGFagbTuuErvc0tJmRuOVq7AxGqOpALQ1YWgatsLotErWREGq fCwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=VULoCS5yM+3jY8jFEECLK4xk3m5ZNts7cJaFdwyF5Lc=; b=LQ7t/OipiXjInI+gNuoISk5dMNSVLVUw45UPqHeyJjMU1loy4mh6YghVKxHNpv6xcC AOtzOCYakicIO8Q7EiGKIPFGGFJZVmg4gb6m19q3VFVvyntkkJxIF+enHPZUXt7JmbkC Mzzv7Bfm5q6kLfkVWP7en1NuIBb6sXCZ5ucRTZQDReOwXY/exjsXDW0Gmyju/vvkx4Ml Uk2IlpUk8xrzSYM1PDEDcFgHrasdeez1PSTETpTme86QFstv1HEm8aR/51hnoFTqp/Nr HKwu/HBexNLHWhv4mMwIIwp+RdEF8yTETkOsuTUglUhKE6NkSkGyYmnAJQDBm8TTnNyw kNtA==
X-Gm-Message-State: APjAAAXIMAHtVgpTisaYBT/5/f5JCpzDmX3njKLJSFIgjWN7/6JRPp+f MXD5N8f5HKv3LgADl+Hwdej9tv9aFh0=
X-Google-Smtp-Source: APXvYqzVubqKO5Ur/7O3jREEXHP3BOF/KjoKrKHQPCl0OoW+SsjFPG+ppHbHwB1vM97tUtUBokuvcQ==
X-Received: by 2002:a1c:7208:: with SMTP id n8mr2372114wmc.46.1553837821716; Thu, 28 Mar 2019 22:37:01 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id v190sm3048535wme.18.2019.03.28.22.37.00 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:37:00 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_0F192E14-443E-4FE9-BF24-8FC48C5E6EEA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <0E2EDE21-3F52-4112-B71E-8458C656AD31@gmail.com>
Date: Fri, 29 Mar 2019 06:36:59 +0100
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Operational Headaches: Mikael's talk
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:37:05 -0000

--Apple-Mail=_0F192E14-443E-4FE9-BF24-8FC48C5E6EEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Yesterday, Mikael Abrahamsson gave a talk about the Terastram deployment =
(https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terast=
ream/). In it, he outlined several headaches he finds himself dealing =
with. Our charter says that we get to send missives to other working =
groups about operational issues we discuss; I wonder if it would be of =
value those chase these (and potentially other) headaches down. I'll =
send several emails this morning opening threads about his individual =
headaches; I'd be interested in your thoughts and interest.

The outcomes on each headache vary; in some cases, he identifies a draft =
that seems to be in the right ballpark. For those, I think I need to =
send a note to the relevant authors and chairs asking them what the =
prognosis is and expressing operational interest. We may also have =
comments on them, which might be adequate documented in the discussion =
thread (e.g., your comments), or might call for a draft =
draft-ietf-v6ops-operational-thoughts-on-, or something else. For =
headaches that don't have an obvious draft (when you receive a prefix =
from a DHCP server, would it be too much trouble to install a prefix on =
an interface and install relevant routes?), I think that probably calls =
for a person or design team to create such a draft for discussion on the =
list and in Montreal. Or maybe some enterprising person might forward a =
link to the thread to their vendor of choice...

In any event, I'll be looking for your comments.
=
--------------------------------------------------------------------------=
------
The fact that there is a highway to hell and a stairway to heaven is an =
interesting comment on projected traffic volume...


--Apple-Mail=_0F192E14-443E-4FE9-BF24-8FC48C5E6EEA
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+AFAlydrvsACgkQEhdRnd2G
P+BpgRAAo/KrM7P852NjlH0Ujt1n5f0rthDMEQGJmVWlTS5M9veGQ0Z2e3MwnYrY
wcZ/3UKMlUDhexEtVc+SmNDOFLZuRO0dEqoZ0JACSWLH85a3SLGFmSlB7OiiJ3p7
R2JOW64v8H2CgdnBvHJZl94ayoHQb8YXD1lc0ARVkVJWWI385cIb5dBy7CcNHOqN
rg2MbPekNpzFxa659+xAfvju9oOCOjHp9o6UtikVEydOwpTkR05Y+hmlCm3dwH3i
/N9/t9jj9HuyMWn2cbZnHwVL3pgx6yVsyq/BtrpTklPSvurZN+yjmMqOxDzTFcBa
qhGZx24h7hhjRI0dUFOPJNXGN54GXNflZCEWbdgrdtm3BLWEP4gAiK3MgrN+DMB5
ouV46Ww/IhimVcy0D1EAtgAws0tCIp9u53dAitwNdhA8mfcTcpqwZJztBajQo6XH
x09tTgdMk29KhtiAAS+l0n2tPbess13M80+XAj57KOI/U3Py8uHUGhhoOchGRgsu
x0VK4aolp4+bXhnqRHlu4lWRc+sPlu+Oazspz6duJp80l333Q1fe7eYduw+gBSfB
GU9/3o4fZQ6+keOhXGqsOle9rtKLkrUos0ac47bkRu8pNlGlUlKSoqhgVbOvDotG
2inxIgmlj/Q03eE3PnDMnbhJK3hUCA2nsNY661AIdgQpEwbL3fg=
=btab
-----END PGP SIGNATURE-----

--Apple-Mail=_0F192E14-443E-4FE9-BF24-8FC48C5E6EEA--


From nobody Thu Mar 28 22: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 AE4A71203DB for ; Thu, 28 Mar 2019 22:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PMfPZjuSJqx for ; Thu, 28 Mar 2019 22:37:29 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9811512041E for ; Thu, 28 Mar 2019 22:37:29 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id q1so1035596wrp.0 for ; Thu, 28 Mar 2019 22:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=DbsyDeKuCOm/NEXLEjc61BFIBvpnLE5ogQjL2vKsviE=; b=gz/GeP75PT5ghbGv9D4QnjcRBNxqZuM6ITWsV4VtyB5RnMKoLok6Z+r6c5erQvHVaF 5wj1qJTCJU0DKt2V/+UJVJ4ues1RwFlZzo+7ARceejH8PktPUdskggl+abKpteqvXIsI lUWgG5ybdMfGB3V/7aBJ9kzvBEbiAj5bEoqrtXKDYqAVQ+Y/FAFcMw3UX+loG/tBfjde sf3W+7ORvcSLI7ixSaFlJ9cjwIArU4KPu9c8ZZ6afm4aM6OAyCn06LtJEVxKy3EMlU+2 AHMda1QHylPFwFwpOkIvExtcA5q/Ili6R9Vazze9IYAHufyLC4w3ezXumYF8ovvpo2Z2 VkRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=DbsyDeKuCOm/NEXLEjc61BFIBvpnLE5ogQjL2vKsviE=; b=VFlUfbGO4osZlm8Q8OPYw4+y2itQDZF3hHjM13NIY/OyCWXugx1l1XNyN5C6/u9pDx 4cs9jOfUpyoCF7ACnUQ+XCt8NLpObrjxzs9raTeQVBs4HYZH0sDy0GT3odsIZGgvrF6b 1unI1258pbPtcUuJeuK+m3u26WVnM0t7k1iZ+tqS8gj0gaFZCsuUZR7lt6nCwr7lhDDq nw1/7gSj7S8y8DdWbcnpRDQuJ8N7YjO+Eh/QaqvtPvkYkhRbSijOiZ/DPQgU7Vd57LiJ J2ZicNPVsCv+b456PFtL5CpBuy+ibTVl8bceGMNtNorrmhK7VPu7/wSXCwpe63b7FNqo eWVA==
X-Gm-Message-State: APjAAAWOjqQrMx/at8VIahC/JlmUUl65CtMiukcuaKODNhhIRz9H6BrZ q4dpbt4kIHy0EiZMsOPhM1Sr6O3qPm8=
X-Google-Smtp-Source: APXvYqzAYoeeW4qMNP+HFte4b2oIGP94US++/fq5tBH9kVI7GWcjjtC7awsayiaV9Wlq25b/xvrYlw==
X-Received: by 2002:a5d:488d:: with SMTP id g13mr16462215wrq.119.1553837847853;  Thu, 28 Mar 2019 22:37:27 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id v190sm3048535wme.18.2019.03.28.22.37.25 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:37:26 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_3DE7DE11-FBFF-4B1E-ABBF-E3D1C69DE6B5"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com>
Date: Fri, 29 Mar 2019 06:37:25 +0100
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Operational Headache: DHCP V6 Relay
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:37:40 -0000

--Apple-Mail=_3DE7DE11-FBFF-4B1E-ABBF-E3D1C69DE6B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

h=
ttps://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastre=
am/, slide 3-4

What do we want to say about DHCPv6 issues in vendor product and/or =
services? This headache doesn't have an obvious draft. I think that =
probably calls for a person or design team to create such a draft for =
discussion on the list and in Montreal.

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


--Apple-Mail=_3DE7DE11-FBFF-4B1E-ABBF-E3D1C69DE6B5
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+AFAlydrxUACgkQEhdRnd2G
P+BZBBAAyRjtNA/OC2/EAdrNvubOa+qfrA0SncfzRnoc61khNvK4nOViP6Alxvmr
Nz+xLSMSAv1v0x4Vh2Xfetk9EHuuiWJxYIzrTIcJaMZ1LlKaZk421Q2LhLUnDsrO
os1COScWwC0l2HrAokaCaK+AasppIRkC/mnmdoPj1CCl/BDrVoT+PDXgbWbQ9UMd
PeZUnlenPOtP59zShtdg0kRDJ7rOYCS6Nk16qlvZSznL5s7eSQa7KZ4CFP7iLkNk
hQCH3sVkIRnNe6E/N0HLMnw/yktEbWKhyeEPrDBR3Pbx9cYVxfYlnKUQagbKE71x
TuE1ugMMA2FKmgegftOwjTa5OHX7JxbkaRWjDe5Zfd5dgINNsh5l/+4IJfwZMyjy
737dUWuBeLdRD5ybCzGktvx1WpM08P9Dsc1BcH7J5Z4tfXNVoRYNiz4lXpTP2JzQ
bgx8mSLoasySBuLME2YC7wW7p12Rg2rTbe/i75CW2xnGc+T8VL4BEVJHxB/EwRNw
ddkdaZA7qgMvUDv86Z9UrwIsMS6Ep69MKIFZcWS7S6eCYC8ktWBoCHhJIYknq23s
M3MNGcn7zEInXLv6Jn9kvo7ZXYJvhsf3e8NzjvFBYoDo79yLZkhmatinGL35hH2Z
jJEDZyDgeSi45J5LMn+K1x6XCJzLnjHXb6LXF1ylqZuXGThzqmc=
=Yri8
-----END PGP SIGNATURE-----

--Apple-Mail=_3DE7DE11-FBFF-4B1E-ABBF-E3D1C69DE6B5--


From nobody Thu Mar 28 22:37:56 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE17612050C for ; Thu, 28 Mar 2019 22:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtSFONvRQrau for ; Thu, 28 Mar 2019 22:37:42 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 14EA4120403 for ; Thu, 28 Mar 2019 22:37:40 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id p10so1032397wrq.1 for ; Thu, 28 Mar 2019 22:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=DLO95zl+On84luuhpirrGtWkmjSyteqwFrJlA9bjU6w=; b=E9AZDMpUN96ZZ/FSXC0wXERCbo2q+g/wkT7rQ9HTns0IdhtBSuIISLcuNoi4ViygHX jfTaI1Ngw11MW27JqqjXbUrZMlp0ChI1qPPiTU8k7mC3lcvTZkvmkvrRD9BZQViZIaKL LAzybn0ITaNdv4ZBhMn6Xadd975KcMC0vfBZzYctzhfwdlBDHzdOIo5aZKrZ9DBwD/ZR 62/kP+4C2rNGGi0j1iY1lyyT0kP/dGjAjZQe9Ibv9PdhY+Qc4qSmV/47JhyyscoKoceP d5bICb/ZdQ8VIiFRhKjW23+UAEDl4RMn9hGUR4wo47LaqgfJoJYe/qPxuW3Fhle+lI1g p7sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=DLO95zl+On84luuhpirrGtWkmjSyteqwFrJlA9bjU6w=; b=E/HVnVMAFyLbFW1Q8PxxfaPmLTfIMnQf35h9+Jd4cS/pU3OgnReCkTbd8Adzs4yRTA x/dFUD5q1NigBtYpLykxXrHryagjiGisAxvlUQuR38D6H/qRJ8lhpGJ1rZ4D/pa6hHSq uBY36pyp6AACCCUCJA6Hhhuq0fdcdqr+vEBUwHFriK/BiCidjQGFLc5aPltuJs4XFAbm 2729IK/OOimlNZn1eON3dsok6qsccIHtbCDv+AYDmzwRGyooUpY1ldkE87jv3dp4D56o XKkKzMFTp5df3Xg9qu9A8lf1+8JB6CbuVX0DG5HmCj49ARdvaoXDCdp3gFeidefnq9+W eaog==
X-Gm-Message-State: APjAAAU2QN1Y63pKbUbgXSMVNUAvjt4EY+NJ5l2dq9UywCbZaifqXfUw XJ4I3wxYoZF9xLVw3BuQP9xoo4ZgQfg=
X-Google-Smtp-Source: APXvYqzRBFbjplwSF9vnyokhG7cmg9XJXsMsL4ivrpC3NmS99SUnrPhfkiop0mPeHLQ4gHqkqJ1YoQ==
X-Received: by 2002:a5d:488d:: with SMTP id g13mr16462600wrq.119.1553837858384;  Thu, 28 Mar 2019 22:37:38 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id v190sm3048535wme.18.2019.03.28.22.37.37 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:37:37 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_9353F728-5841-404A-8404-C3307089C58A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: 
Date: Fri, 29 Mar 2019 06:37:36 +0100
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:37:56 -0000

--Apple-Mail=_9353F728-5841-404A-8404-C3307089C58A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

h=
ttps://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastre=
am/, slide 5

What do we want to say on this issue? Mikael mentions =
draft-ietf-intarea-provisioning-domains; in this case, I think I need to =
send a note to the relevant authors and chairs asking them what the =
prognosis is and expressing operational interest. First, is there a =
consensus to do that? Second, do we have additional comments to pass =
along? Our comments might be adequately summarized by forwarding a link =
to this thread, or might rise to the level that needs to be discussed in =
an internet draft in v6ops. Comments?

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


--Apple-Mail=_9353F728-5841-404A-8404-C3307089C58A
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+AFAlydryAACgkQEhdRnd2G
P+BiPQ//WjjGU8ER9EE1ZcMVLcSC3W9eQxMu19FfTSdf4CRG1hol2QZ9EmxOZd9n
v1CLLmVAdBspqMMeshPpxFzG2C0Z+htx5RlhqPZPScLz0UmI1L5UvwR6FhN5Yisq
T5WyeDL1OLKe49eSX1eenQHrjFvE+DkkTwymKPrtTTrmi+7iajgQ7OcRMO1mpF5p
yK9f6PNg+H7aYVILtK7q//aQQwitgfDMmkwEkZ/4rciSM7XA1IYTQHaB7B/jvJ4I
PMt58kX+BARCf3NCmtrkehuZM8VAbKp3e4ipNyTKw1Rua7l5x7Rz5Stci1hN5kHW
QLJh1rickh7e8v2K5hi2HQ1SP+9KGH5+sKAe/jhOtJ6nMSqCBlAGxhAP/dWmMKQ+
0WM3mLbWy4HhONXuCAHLBpGjVhDvqE9BDlaVhXCUBuQGXNAOf0P8GsCNfHnyu4cN
TcMm24sVGNuhP19QXCiMgbP55W1mkdE4m2gkjQaINweHP6SSn3ahjhHV33H2rqmc
zNFKRDvHOw+mC9olEjDD3mX6AJEeZ02IdVSozBp8LVoPTEj1Cjsvos6BfdQWhLEq
NGQP+QERy09IXqGdsPgUQcco65HoWibSeEWDQmVHFZLouBNGGH6PseOOMMnNS/OO
Y38n7RGv+4SCMAjKVgYTymPgNJmvNOa6e7Z+y0u7pwv5AMTjWy4=
=2vbD
-----END PGP SIGNATURE-----

--Apple-Mail=_9353F728-5841-404A-8404-C3307089C58A--


From nobody Thu Mar 28 22:38: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 33D0F12052F for ; Thu, 28 Mar 2019 22:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2WG-nFAYSyB for ; Thu, 28 Mar 2019 22:37:54 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23302120403 for ; Thu, 28 Mar 2019 22:37:54 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id z24so1287701wmi.5 for ; Thu, 28 Mar 2019 22:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=1S019YRCQqxvVn+VVMv5MFmdfF2jvehgFZ+lQ1p83yQ=; b=UNhmE5r0kmgXw7f+GjJZdZxS0Meeb1FtwSmSwIFuHNojoq9Y9ProPrgngV6o5dkh51 w2PxcI9+vWloynp5bnm1EGPjVw0Pxhc8u/XzMKuqMWZkDABCBMsXuQOSB4b2+cB0UAFM hLwe0hmkv2MBitDgdPGq4ivWebfw3dZwLa5JtJtiEGOYL93+LZKj919rsBolDzr6BRer SRKpfQdQ5eWv2qZuPrKlkWIWIAsLQ6Jh0oWrGDGO+ZziBPUmJZTs4sR61iGKnXg1w4uS sHylHUZzrl+edasn8tdcLiQqPShlOD39pCt5Ll/2Nsx3i4eCiXqzTAVigBxw9/d9Q7re hWMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=1S019YRCQqxvVn+VVMv5MFmdfF2jvehgFZ+lQ1p83yQ=; b=B+LrGeZpcXtrcu5N4s+GJDtz2+C36sHLo9Fjb8fuzJebqMypWolU/UgdlFcOo/Ah5Q HymIKyMag3rpgzCA9RJyYp5X4q7z0NNmDRsHdTpZ3P0U0BMuALMJl+mBV+/ynAtX9S8W Lao33vAHW+06wdOMcMmsx09JThi5MaXP0kQUswgfBP8zjkfYvxGuMnyXcjZuA5Wzxwh3 QaXpPWy7W6AbgqVCx3A2X6Ev/GaqCzq5f/nChqSAj15YMYHTayMZ2Vna086OGA75YXl6 YZGzTqK3i5SDCGhtZSvtQCa6vL4NLVzhi/EB8J1Ge56e4i1sIkO/Qi6VQ0+towOCs/Mr qaSA==
X-Gm-Message-State: APjAAAVQ+n0o2kppvpi+Obwr9KFHtYE/VFfOaPV8QwTA1szjl7vKIu0D 2hEpR226JcdtIYXR3RqPjHnFMotQor0=
X-Google-Smtp-Source: APXvYqwrcJ4uHdsgrHTdrlsrTS0RKGJE4mcsHhyUrlWIN1mZWzsKDaYY4bc2GbCnQKmFqD+h0p0+lw==
X-Received: by 2002:a05:600c:21c3:: with SMTP id x3mr2164978wmj.90.1553837872421;  Thu, 28 Mar 2019 22:37:52 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id v190sm3048535wme.18.2019.03.28.22.37.50 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:37:50 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_EB0973A8-AD14-44F1-891B-5278F6F49F3A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: 
Date: Fri, 29 Mar 2019 06:37:49 +0100
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Operational Headache: Multi Attached Data Center Host configuration
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:38:08 -0000

--Apple-Mail=_EB0973A8-AD14-44F1-891B-5278F6F49F3A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

h=
ttps://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastre=
am/, slide 6

What do we want to say on this topic? There are a number of screwball =
interactions, and vendor product seems to vary. This seems to call for =
an draft named might call for a draft =
draft-ietf-v6ops-operational-thoughts-on-multi-attached-hosts-in-data-cent=
ers or something like that. Is there a person or set of people that =
would be interested to form a design team around that topic?
=
--------------------------------------------------------------------------=
------
The fact that there is a highway to hell and a stairway to heaven is an =
interesting comment on projected traffic volume...


--Apple-Mail=_EB0973A8-AD14-44F1-891B-5278F6F49F3A
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+AFAlydry4ACgkQEhdRnd2G
P+BPeg//Tqdh3tkg3m9LtamEpZ5ONK5yhAvaCYpEOUSLmd6lkliJl3DelYTNUpgU
j38PZEhp+qjKsKfeL52mIcEgt7FKHuFFZVe9B7aqikfK/jbY4UwMNQOVojLCjccm
e96bP6IpCo0AT/5MSyXDQ3+wPCV2grcFfEDk031vkhgqmKrldMwAEYI8Ue7XwJ0X
blNJ+bJqIAEB+BPEhtC+QXAuDOPzXeBChChJGgtkh/diUFF0jnxy9At3QedXKYnu
EQ3ZbWeifRWzbcl7aOoFO0rIu14u/baP4CDVc5caZuHUdTECH9czkK0euTF4YeYM
4sBzyHPjf0XbqQ4RVtuByvjQCkDczyw7EeHPF6xp0g2aRqS8AwUYc/6Z42GHgBT4
oAIf50L6A3X05cO0+SEpMLxdaBlOPkzTinYJp81y2huVMq1+IZBS+W0HgPqdRy63
WiR+CU09nB9p51euXDPzy/8XpvYEwyligxKRRUhxdClLaC2UtGSJNF8NFW9iOcz/
b25/OC+tiN+RBvGcwGn6YwFUHNLdKlVR/ZOeXMf3ywGkWmO1O+gasAptGK/9FhJq
Lauc2Ia0l4EdvnGtI+vAnsNPdz5jr30MNBYzfUgCQxsuVnJizDRm4nJ8t23a18mP
XQlBHNqa7OROh2YUIV+hAwAHtkaorrETlnmJR1meyEkUHd8N0Yc=
=GuAG
-----END PGP SIGNATURE-----

--Apple-Mail=_EB0973A8-AD14-44F1-891B-5278F6F49F3A--


From nobody Thu Mar 28 22:38: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 EFB9A1201E9 for ; Thu, 28 Mar 2019 22:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGW87nQJPk5Q for ; Thu, 28 Mar 2019 22:38:02 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 1658A1201C6 for ; Thu, 28 Mar 2019 22:38:02 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id k11so1010319wro.5 for ; Thu, 28 Mar 2019 22:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=GJXMMXE9i1Xduzv9Bge1Zo0QMbrQ0fhz21umQuGqAQo=; b=VHc1pEPeqzDddr2jz7PY7p442uE44hO0NioDLIT/1E2RIUwIOkLUXPOlXK/8yB/tIB xODHam3/CRVZuHI4MKAGI83YAdxEb1YHKf5iD03RBCGcCGEAVRlcB9PmlV08JqlyAM8c EmaYoTZI0LU2AIe598jdnFbw8TSA90ZDOyOlf/FGO8aDKKTdjVWvQO2xPYQZ/nJu5fGf 0IGBhu/JP3lcLopMvyDARDpkRmTRwHz/kbhmebEE9Dp49seCJHvWTTEPJ5LmFLZsJuhe 9MQbDX7ogVImt23gpyxZesH9g/7GwB/rrAFmgtxOxyS6QYEtIgouMtUrf4B/buCjk7L0 xrUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=GJXMMXE9i1Xduzv9Bge1Zo0QMbrQ0fhz21umQuGqAQo=; b=JbDPEzwV3UA1s9Y3CYy8ugTIB86XmQgG1C5KCgsJEH4/L8EEUsOaV9kSz9dZk5g8qX rexRhpUMf2CPIzfwbkiDmidcIqNDuJB2t46ndtpNLfnX61y3cfSHMp+2owLxIPLaw6py zgn/xx/FtSIwsJ/aYyTae/654dxP3Td9Kfs5+Bnqv9wP9ILz6LeYBlsbmwC0jznSpbCH GV70s2Gm/MgHB9ZLE2LwTG2HbDpfIBNdfz0h92/ia8I94mPUJRc6Mk/n717s6/IVm3ka +S96iVBly3TtyAC0iUvYVVDDclXzAQjEP0ZW7txqeAG9ovShyTEeGZNcyurfHTr8W+r4 2AsA==
X-Gm-Message-State: APjAAAXwhf8SYdH8cNG/SfrPXXHHhHrMES1ge/IXzlxk7wVXUhCOyp0e kddwNmh2AqLxFXFfSjSQrl5qpd/uRiQ=
X-Google-Smtp-Source: APXvYqy4hayfWkd7rGclfBvakch7xrsVw0lV6pEhOh+tHSmLS5RIfwmk67i0+kJE8FQzMw2ggPUtGA==
X-Received: by 2002:adf:f88c:: with SMTP id u12mr28817081wrp.235.1553837880199;  Thu, 28 Mar 2019 22:38:00 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id v190sm3048535wme.18.2019.03.28.22.37.58 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:37:59 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_8785871A-877D-4D22-8380-57B0C076D384"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: 
Date: Fri, 29 Mar 2019 06:37:58 +0100
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Operational Headache: MTU issues
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:38:17 -0000

--Apple-Mail=_8785871A-877D-4D22-8380-57B0C076D384
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

h=
ttps://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastre=
am/, slide 7-8

What do we want to say on this issue? Mikael mentions =
draft-van-beijnum-multimtu as possibly relevant, but I also get the idea =
that there is more to say; in this case, I think I need to send a note =
to the relevant authors and chairs asking them what the prognosis is and =
expressing operational interest. First, is there a consensus to do that? =
Second, do we have additional comments to pass along? Our comments might =
be adequately summarized by forwarding a link to this thread, or might =
rise to the level that needs to be discussed in an internet draft in =
v6ops. Comments?

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


--Apple-Mail=_8785871A-877D-4D22-8380-57B0C076D384
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+AFAlydrzYACgkQEhdRnd2G
P+Cffg/9G5v/6I+wfdPSCSzpky4TbdedVu/usvJzwVbwEN+DPi9NgESAojdcsdH8
Z5+kW3V3HTLUba22p4/kgp9szQXnqh1eCldl43uTH9/vAsHG2BNuXUiws8kH945N
iDknJRyO0QXqQh7bTftqft8cxY0FVPgbTcwhod3qLUOZvCayxjqTOz03Y4vuZOKt
L90KS1TNBYlYje9YGFNczsQTdf7EImaM2tgeVgRNkB3LGuLyqOjGHea0RyVo5qjm
o8GiHd83u9KT3e3vMGAXtxova3KKhdOmBOatSXv7M+a493OyL8K2XI5p13pnWDZR
+9JkfmWC8RS6DoqydUGbz/F/7dhLdmNvnEgTIkQnB4KXABdOJso083gAsxZBkQL6
PGuCYWjmF95iNtn3cgVsrq19L+fVgdycRqYEeW288v9NnVgacEFeu7MOwx6VNoem
PuMo7bICTwqJ4N90f5ryKfLYed6jQe6OhJrIfBM3X90/3JS/NbgGfiw7NnIVMZSF
tb9prtmMWJpUa+7Jrh5mm+KSLFkeQlMx7ZqPYUV2wisoVCgojQrUHfNntKicoQTV
mPCRYaW5PBwAVf0gfUBojiLnTFZloEghs2pfNP6qCtx556QcofBbiBJh67ZIcZRd
3ctYIL6WgfPBjMLedBzdTQBvhys8RMLd2oJSaWz+1que8IaJYdk=
=KEf0
-----END PGP SIGNATURE-----

--Apple-Mail=_8785871A-877D-4D22-8380-57B0C076D384--


From nobody Thu Mar 28 22:38: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 213D61201D9 for ; Thu, 28 Mar 2019 22:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy_PpoG0_shF for ; Thu, 28 Mar 2019 22:38:09 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072C01203DB for ; Thu, 28 Mar 2019 22:38:09 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id a184so1140953wma.2 for ; Thu, 28 Mar 2019 22:38:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:to; bh=ctuiA3FR8EVAZw1UV18VFQZU0148u/DhDmnjn56aQKw=; b=JtW3GtQ21uWsEqUxfISi9+rq3QIEBw6Uap9gWrp7TG1IV6GK5ZDwgXPDGo4JF2mt0T pk3ZYaXpt/B6KBmbxcfvd7veQN7Pw3zGQE6D5RFonQaqQf/uFAcPivSid9XpTfmFuGAC CmVz5NkuAZPtWCIVN/CqPovSv2ttieFRvia7FVCix5uSr7cGUiwCPk5/yBORF1EYRdwq em5UM21geLcZVwKr1A6sXBHrEsho3AUbxMh+WS/E3DjGFGkulWBwEEhaaEC9BYJWOZyS 00p5xBRDhrdDX1Rzu/ooLyFtldp+SDrXi9oGpXpcH6bKIPVanaV8/Xay7rPQNRAP3voU P37A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=ctuiA3FR8EVAZw1UV18VFQZU0148u/DhDmnjn56aQKw=; b=L2kVKjK/DKIHlVg8sllmZjC3u60lCgR4+wVRM+VAGSfZN9/y+ylZ9BtetebaZsGLw5 VMcXw4OmFIgI28SU5nLLPp+4MyYqp1KO9/kV5tb4fNZpMIGPnD2KQ0L8MWQ3M3jlFyBi Rw7oY4Sf7kIWSHP2sFe4QPjcB0Y0vxwsXB3T8VbhaAxggmw7WURclm4hsCUQXXrqBgqd 8WdpyNP97C8Xu/LcL70TN6yaAuzRTTv7rgmH4IJnQx7zoxOfwfh1xFUCOkgfJb62TlMR ftkvO8zgHucAyFJqainY2c7iuiqrLYgYp4dJHqilCy1AyOjADzJl0mrKmgAF+frFZaL3 MwuA==
X-Gm-Message-State: APjAAAV1L0HkxnOsGSgQejNzs2RoeVZqIOxaC/6TTfS/ICu+fS3d3yrL 5VNFIxkleFoHxkdvt0ghN5HvnUmB2O4=
X-Google-Smtp-Source: APXvYqwc/kxOjQ0Ax1fWm+f5C80MMACQdvfaD9PrjPjrV26YyiJBx6CA7crDme5OZclV/wgfloXIhw==
X-Received: by 2002:a1c:7208:: with SMTP id n8mr2374608wmc.46.1553837887257; Thu, 28 Mar 2019 22:38:07 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id v190sm3048535wme.18.2019.03.28.22.38.06 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:38:06 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_89467346-81F7-4FD1-855D-5D5A09F4B164"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: 
Date: Fri, 29 Mar 2019 06:38:05 +0100
To: IPv6 Operations 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:38:22 -0000

--Apple-Mail=_89467346-81F7-4FD1-855D-5D5A09F4B164
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

h=
ttps://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastre=
am/, slide 9

What do we want to say on this issue? Mikael mentions =
draft-patterson-intarea-ipoe-health as possibly relevant, but I also get =
the idea that there is more to say; in this case, I think I need to send =
a note to the relevant authors and chairs asking them what the prognosis =
is and expressing operational interest. First, is there a consensus to =
do that? Second, do we have additional comments to pass along? Our =
comments might be adequately summarized by forwarding a link to this =
thread, or might rise to the level that needs to be discussed in an =
internet draft in v6ops. Comments?
=
--------------------------------------------------------------------------=
------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu


--Apple-Mail=_89467346-81F7-4FD1-855D-5D5A09F4B164
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+AFAlydrz0ACgkQEhdRnd2G
P+DbCA//ZJHKaDEbAxUu6pGV+xuZu6/5Ft6ha6h7h4VwYYimTugwUib1MubuOgx9
EZIWYC5iwspwfXgHFFDGmEjVZjdSLx18KRI5M2SiO5h32r8UID/JL270v5eCFXgN
qum+9MXlZj9zPj9YMBU7Aaw7KO1JzNxflU6BhYCBJQbxuECoRGhv4NVdVF0GHbQB
nxv+xMYCW9Xi9WWzFHViV1kM9OWMyc69PEH86RYvXgUd2Zdj847ybDYMnFJekeRh
9mCRNML6aRO3yYJu27glzJJuosnfxOq7JD/WJT+gC04dY9mG1PHILn64zeUsdcRu
RM0qH12CgiJZ+54CqsAZalcAhbdvS/t2WF6DLJPMhsm7uBIWeRpKqn58SD95Kmhy
YPdyVHY6cJ68XnUMjTHezEEZwxOsDNJ1zA+43dclWz6oQDrUroM67Y3HUVFeO7vf
8A9e0wJwoyopZYxecMoB+aBEmYXhTX01G/pym9QZNaXd2o2nUsH7nUnqqm5knNz0
OfcabdGwQOSLc50fwCzPM+TQbQ1Z9APxQRfoXC7k/q3r3oUH/ChA7B0vDOzyhOBb
fKuYMWOzxWcM1fJBXePeqNC+ORxTfJV0cAy17qkhmv7B6gZhD11Cb69aTdYWhLR7
su3ZgQdZWEijQQ1yvgPYEjXHGJDI+dBCOgrmflcDJpc5kyH+34g=
=Yyy0
-----END PGP SIGNATURE-----

--Apple-Mail=_89467346-81F7-4FD1-855D-5D5A09F4B164--


From nobody Thu Mar 28 22:56: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 E20BD1201BF for ; Thu, 28 Mar 2019 22:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrPTwP2AvVCr for ; Thu, 28 Mar 2019 22:56:52 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 2D3A11201AA for ; Thu, 28 Mar 2019 22:56:52 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id z6so8870553wmi.0 for ; Thu, 28 Mar 2019 22:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:date:references:to:in-reply-to:message-id;  bh=CY99RVhjXzy7Z91veI3kLkuYeX3PUv7qICg/oYf7y/M=; b=EjWWXwj52f+Dve/F9JS5M6/cXFp/pzUzsX6vEvs5OP3H/ZK0baWBGd/M5fQ3QGaoim fLJumrIS2Bz7BiaIp/Dxbx7B2KyOtlftq9AjGrOJdtct90eqIoa5dAAp3n3/9AEBSR+l +rRmUvuytUcUtKp6YS7gPkyqRvjbQQcfrHflgLuF45dAtq5GyZcjNxZ7vDnJnKrUbk0b F9eJAhGiWWZOlfxB3Z2FSrxhsNNepXLWm3GufIx+HXvhpfE0zAdljp+27cMOfKT9ieaZ 0N3SOIiItzNupoEA88xEX6ytGExNIDgE0JEaZz+GbzviAzu3Lge2rqsNcN4kNGmsM9jL V+Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=CY99RVhjXzy7Z91veI3kLkuYeX3PUv7qICg/oYf7y/M=; b=fVhEuhdNu+UBqS7SCgpi+FneIm0dO1xi8jsXtUu17NhcJBiilaWJCvaNJQr7Rvq3su BlD5ifLswJzEkDIXqzuh3PyMIbqt3pSWBRHfRiPeyp8Ed2mYAIETFW87zGQxEBtreYTN Nv12gag6iTSt6Tz3dy1azlh5MwWzR8n/KgxriaUCuzw4WvUVYvSfSdkCl7v30nj8Z2k+ fzQD1yi6MtQSfYRZh+u6w3MsrSLXu63upcJ1o7euCFFwG1JxNfQOjOcn3wFti8+xRnBP cDznjGkSfy4R6KUdvHWSEG7xFEzBGFQUbV1VsukheyHapJli+5IdmiktU48DJWuKr390 jtYw==
X-Gm-Message-State: APjAAAXOFmGfZrsSEAd6ypxyB34orkDCU5WODLihRoLXsz0DQw1K+mjg 897HubvsYM5QVXMBDung4uMjkxSKrno=
X-Google-Smtp-Source: APXvYqzcOFqAHcjTJIPdnY8Ob5kzdWkYEsG8Ad9WaaA53Kc8cZBG6PPbxQYM3X9z4MvdQWV15JMjzQ==
X-Received: by 2002:a1c:ef08:: with SMTP id n8mr2311114wmh.85.1553839010352; Thu, 28 Mar 2019 22:56:50 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5da9:f408:cfef:f200? ([2001:67c:1232:144:5da9:f408:cfef:f200]) by smtp.gmail.com with ESMTPSA id d6sm1238169wrx.62.2019.03.28.22.56.48 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 22:56:49 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_D5D25169-2F13-4DB3-967A-8D4F2282DFC2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Fri, 29 Mar 2019 06:56:47 +0100
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>    
To: IPv6 Operations 
In-Reply-To: 
Message-Id: <0153779E-91C8-4D9F-9454-CE44E2E9A9A8@gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: [v6ops] Default DNS Server
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 05:56:54 -0000

--Apple-Mail=_D5D25169-2F13-4DB3-967A-8D4F2282DFC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Mar 28, 2019, at 5:11 PM, JORDI PALET MARTINEZ =
 wrote:
> 1) Mikael mention that Chromecast (and other devices), use a manually =
configured DNS such as 8.8.8.8.

This is a different comment than Jordi's topic, but I'm of the opinion =
that the use of services like 8.8.8.8 by default overrides what might be =
local policy. I'd really like to see such things use 8.8.8.8 (or 1.1.1.1 =
or whatever) only as a backup in case the network didn't tell it what =
DNS server to use.

Reason: if nothing else, the device might be used in a network that has =
local services that need to be accessible. Google is well informed, but =
even Google doesn't know everything, and specifically doesn't know about =
such services. To me, this design decision borders on arrogance, and =
certainly isn't about enabling user control of the services they use. =
Net Neutrality and all that...
=
--------------------------------------------------------------------------=
------
The fact that there is a highway to hell and a stairway to heaven is an =
interesting comment on projected traffic volume...


--Apple-Mail=_D5D25169-2F13-4DB3-967A-8D4F2282DFC2
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+AFAlyds6AACgkQEhdRnd2G
P+DGuA/+Nne4IZgIvGezpZfKdyodqmu5YKoG8EATkZDVw8N0bshlj6TTgOiPBXH7
n8lCZoV8L3v9YOtxq6jUEVeg5prMHpd5xMzDTSsjFMFxPIIt+krtCy/jhIqW/Zyq
h2vjwQl0+Nze/WMzFPxGMmtP5WaXH58z+NQYUdePHuQKv9OAyRTVPcPn1ObQZMFa
ujfQMUPUIF6Wn/vocQk5cK2ilFnwbTtazmq2qxi1EAvzpZ/T1zOGEf4LazYlYKv9
c8E+7YSt5u24wUnSEZ+EvfeHXoNLvFofwBYs5a8TXGhoJXWvWpBxj9p6r1HuG9Lx
2L0RYlB5HRQr4mcvAJCbruFZDbYDYawY8HmVZyTS/6bupGvw+Y1wmYbvJsLAaPnU
/qwMMXBnFzDt+ZDprOTBW/ZjEM73P8acwYcnA64zJFrv9Vaf0ZO1yDd6IviKYxOb
52OUf07H78F8rvtsVU6Eyw+0Lggh1JzIRmDLInVWsuSVnFsN9YkDXhUCt2p95vAn
tC1appkmS9NbgFSGYvlx2PoUJ9bq2/SGPVQQ3yXi47Nb2L/KX45aXNATtrLyvMtE
ZvPajK50Gf9xN8hJ8E+Y2UG07PQKGNxD6LUQRfTyIq93mDhn4o7Udbv4e3xoMAvo
qvaAlNRDGmLKS5SNC581tjQj0dvNJmd9tnlU0NNRMS+zEKbCVL0=
=GGjg
-----END PGP SIGNATURE-----

--Apple-Mail=_D5D25169-2F13-4DB3-967A-8D4F2282DFC2--


From nobody Thu Mar 28 23:09: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 4A5C01201AA for ; Thu, 28 Mar 2019 23:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=URDe32WV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=c0aOtJkj
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSymVTtWB-81 for ; Thu, 28 Mar 2019 23:09:22 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AC012015D for ; Thu, 28 Mar 2019 23:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1328; q=dns/txt; s=iport; t=1553839762; x=1555049362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j8EqNhOjDPg2zxfh+3TfIy+MHD9iPqcg5QpOQB0i+7s=; b=URDe32WVfLX6aPvD542UDVmjgAbT7LFzdiwSpOTQyi4Hb3BKhvAw+DYj fOmIV/rGLv7n8yNMyeOVYlrhU6EcebdNHZ4oSn1ArPMdNOz8I+PushBjo 4qKry+lFRRb6FejNpvjdpXHmwMqZ4xiRu/hZQeRWO5njhq+6HdGtua5j7 M=;
IronPort-PHdr: =?us-ascii?q?9a23=3Aw30KoRFoxLmImTgfI40vJJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeTjbS0kFexJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAADMtZ1c/4ENJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgT1QA2h0BAsnh1UDjzGCV4k4jVaCUgN?= =?us-ascii?q?UDQEBGA0HhEAChTQiNwYNAQEDAQEJAQIBAm0cDIVKAQEBAwEBATgGAQEsCwE?= =?us-ascii?q?ECwIBCBgeECEGCyUCBA4FHoMEAYFdAw0IAQIMni4CihSCIIJ4AQEFgTEBAwQ?= =?us-ascii?q?MQUGCQQ0LggwDBYEvAYsxF4FAP4E4H4JMPoIaRwEBAwGBXYM7giaKR5oxNgk?= =?us-ascii?q?Ch2qIHIM/GpQMkTWBPIt1AgQCBAUCDgEBBYFjIoFWcBU7KgGCQYIKg26FFIU?= =?us-ascii?q?/coEojk0BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,283,1549929600"; d="scan'208";a="540731255"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 06:09:20 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2T69Ku6014424 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 06:09:20 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 01:09:19 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 01:09:19 -0500
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 29 Mar 2019 02:09:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2K1V83GhEC2XTKAQVfEdx51zhp9lgrXKn63VYHiw0co=; b=c0aOtJkjtGLdPpA6ocl+egRFJQAPu7V2KfFccW9aJlf4PPwxMSlThEtJhteur1WBF1cl/dYj2qCnG53CTu25c6vp8gauzRKPAsOcfM1BzAiTRDCtET6XyWNXqof2i+ZLFjJzGW4JZl6MrhGkrHqryN2bcNCyEsgespMpwRFj/iA=
Received: from DM6PR11MB3068.namprd11.prod.outlook.com (20.177.218.153) by DM6PR11MB2651.namprd11.prod.outlook.com (20.176.99.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.16; Fri, 29 Mar 2019 06:09:18 +0000
Received: from DM6PR11MB3068.namprd11.prod.outlook.com ([fe80::5d16:a8db:b524:e147]) by DM6PR11MB3068.namprd11.prod.outlook.com ([fe80::5d16:a8db:b524:e147%4]) with mapi id 15.20.1750.014; Fri, 29 Mar 2019 06:09:18 +0000
From: "Rajiv Asati (rajiva)" 
To: Fred Baker 
CC: IPv6 Operations 
Thread-Topic: [v6ops] Operational Headache: Upstream liveness
Thread-Index: AQHU5fJv4iCa3cLT7k+h6fJIuixptaYiH/1g
Date: Fri, 29 Mar 2019 06:09:17 +0000
Message-ID: <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rajiva@cisco.com; 
x-originating-ip: [2600:387:2:809::44]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d2521b94-03f3-4f8c-e371-08d6b40d13e4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR11MB2651; 
x-ms-traffictypediagnostic: DM6PR11MB2651:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(136003)(366004)(376002)(189003)(199004)(66574012)(14454004)(229853002)(105586002)(33656002)(6436002)(966005)(53936002)(6486002)(446003)(4326008)(476003)(6916009)(2906002)(478600001)(71200400001)(6246003)(46003)(83716004)(97736004)(36756003)(6116002)(486006)(2616005)(71190400001)(11346002)(106356001)(25786009)(256004)(102836004)(6506007)(8936002)(99286004)(53546011)(76176011)(7736002)(305945005)(186003)(6512007)(6306002)(5660300002)(8676002)(82746002)(81156014)(86362001)(68736007)(316002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2651; H:DM6PR11MB3068.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: wPQ2KPqGaZSf5FHjUekX0Ce23qFFXW+O4BW5eKb1hZ+ixfrsr9dC3PxnGQAzh9e9+JciIv6xOfeADjbHqQs6Yu0bPHUrbDTfDGqemjPAUhqpJRWygSD2PUKFyVoPG1a7tq1ZqtmoX/AlNIVO0kRJM8n9N3g/p0uN9t8B+J6XXZW0AXSNKaQqcek5DJuMb65J/wOXyWl7klzChCYUfb5fxLYM/CC9qUU4Yxa/1CXRf6JeYwbpN+lGjfO55yTFI80eF5q/ic/m4SgHm3klnj87/ohwbchlO1DWrCGG0pJ1eaeF0vDNtjTIdV6QjyHesJ/fgCLkV3b1MMyuzlZIqlUCNljixo4d9j09PUhlgWw53fnIIclGWpoPv4kSPCCjVncDc8k6I/RTwd+yJfwn4lnqTAWwVgdcFFmw3Ju58aT9Me8=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d2521b94-03f3-4f8c-e371-08d6b40d13e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 06:09:17.9454 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2651
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 06:09:25 -0000

Why is NUD not sufficient to address the problem (WAN neighbor unreachable)=
?=20

I hope that the HGW devices are  compliant with RFC4861 / 7048.=20

Cheers,
Rajiv =20

> On Mar 29, 2019, at 6:44 AM, Fred Baker  wrote:
>=20
> https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terast=
ream/, slide 9
>=20
> What do we want to say on this issue? Mikael mentions draft-patterson-int=
area-ipoe-health as possibly relevant, but I also get the idea that there i=
s more to say; in this case, I think I need to send a note to the relevant =
authors and chairs asking them what the prognosis is and expressing operati=
onal interest. First, is there a consensus to do that? Second, do we have a=
dditional comments to pass along? Our comments might be adequately summariz=
ed by forwarding a link to this thread, or might rise to the level that nee=
ds to be discussed in an internet draft in v6ops. Comments?
> -------------------------------------------------------------------------=
-------
> Victorious warriors win first and then go to war,
> Defeated warriors go to war first and then seek to win.
>     Sun Tzu
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Fri Mar 29 00:51:23 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059DC1201F8 for ; Fri, 29 Mar 2019 00:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE5NGe-0O14m for ; Fri, 29 Mar 2019 00:51:19 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4905D1201AE for ; Fri, 29 Mar 2019 00:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [194.228.68.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 04FEE1867DC03 for ; Fri, 29 Mar 2019 08:51:15 +0100 (CET)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: v6ops@ietf.org
Date: Fri, 29 Mar 2019 08:50:54 +0100
Message-ID: <3848353.jbcFU8J3gA@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: 
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>  
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2160319.rLbFpxMUlt"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 07:51:22 -0000

--nextPart2160319.rLbFpxMUlt
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hi Jordi,

I would like to point out a question I've asked to you after session:

Would it work if a multiple sides would be under the single proxy on IPv4, =
but=20
on separate hosts on IPv6? Wouldn't it make just one side accessible and re=
st=20
would be pointed to wrong server?

Regards,
Martin

Dne =C4=8Dtvrtek 28. b=C5=99ezna 2019 16:49:24 CET, JORDI PALET MARTINEZ na=
psal(a):
> Hi Dave,
>=20
> After the meeting, I figured out that that's probably easier and no need =
to
> determine if it is an IPv4-only host.
>=20
> We can just create the EAMT entry for any A request if there is a
> corresponding AAAA which doesn't contain the WKP or NSP. This means that
> the end-host (CDN) is dual-stacked.
>=20
> Then any host using the A record will automatically get the NAT46 transla=
ted
> to the "real" AAAA, not the one with the WKP or NSP, so we fulfil the
> intended optimization not requiring knowing if the host is IPv4-only.
>=20
> I think that's what you are meaning?
>=20
> The other think is how to select what AAAA to use if there are several.
>=20
> I really think it will be interesting to get some co-authors, or at least
> good inputs from CDN/caches operators on this.
>=20
> Regards,
> Jordi
>=20
>=20
>=20
> =EF=BB=BFEl 28/3/19 15:35, "Dave Plonka"  escribi=C3=B3:
>=20
>     Hi Jordi -
>=20
>     Thanks for this draft presentation in v6ops.
>=20
>     As we mentioned in the v6ops meeting, I don't think a CPE (or any
>     remote host) can reliably determine if a given IPv4 DNS client is an
>     IPv4-only host.
>=20
>     For one, this is because dual-stack hosts have at least two different
>     IP addresses (v4 and v6), as you know, and there isn't a simple way to
>     remotely determine that a given IPv4 address and a given IPv6 address
>     are actually bound to the same host's interface(s), or even to enforce
>     that a dual-stack host will query the same DNS recursive service when
>     using two (or more) different client (IPv4 and IPv6) addresses.
>=20
>     However, for your draft, couldn't we just eliminate any attempt to
>     determine if any hosts are v4-only or not, and always synthesize the
>     IPv4 DNS answers?
>=20
>     I'm not saying I'm in favor of the mechanism overall, just saying we
>     could avoid the unnecessary and error-prone step of trying to
>     determine if a host is v4 only.
>=20
>     Does that make sense?
>=20
>     Thanks,
>     Dave
>=20
>=20
>     On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
>=20
>      wrote:
>     > Hi all,
>     >=20
>     > We have published a new version of this document, taking in
>     > consideration a few inputs, clarified some examples, nits, etc.
>     >=20
>     > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-=
cac
>     > hes/?include_text=3D1
>     >=20
>     > Regards,
>     > Jordi
>     >=20
>     > =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
>     >     A new version of I-D,
>     >     draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
>     >     has been successfully submitted by Jordi Palet Martinez and pos=
ted
>     >     to the
>     >     IETF repository.
>     >    =20
>     >     Name:               draft-palet-v6ops-464xlat-opt-cdn-caches
>     >     Revision:   01
>     >     Title:              464XLAT Optimization for CDNs/Caches
>     >     Document date:      2019-03-25
>     >     Group:              Individual Submission
>     >     Pages:              10
>     >     URL:          =20
>     >     https://www.ietf.org/internet-drafts/draft-palet-v6ops-464xlat-=
op
>     >     t-cdn-caches-01.txt Status:       =20
>     >     https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-=
cd
>     >     n-caches/ Htmlized:     =20
>     >     https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-c=
ac
>     >     hes-01 Htmlized:     =20
>     >     https://datatracker.ietf.org/doc/html/draft-palet-v6ops-464xlat=
=2Do
>     >     pt-cdn-caches Diff:         =20
>     >     https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-464xlat-o=
pt-c
>     >     dn-caches-01    >    =20
>     >     Abstract:
>     >        This document describes the drawbacks of IP/ICMP Translation
>     >        Algorithm (SIIT), when used as a NAT46, and IPv4-only devices
>     >        or
>     >        applications initiate traffic flows to dual-stack CDNs (Cont=
ent
>     >        Delivery Networks) or Caches, which are forced to be transla=
ted
>     >        back
>     >        to IPv4 by a NAT64.  The document proposes possible solutions
>     >        to
>     >        avoid that.
>     >    =20
>     >     Please note that it may take a couple of minutes from the time =
of
>     >     submission until the htmlized version and diff are available at
>     >     tools.ietf.org.
>     >    =20
>     >     The IETF Secretariat
>     >=20
>     > **********************************************
>     > 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 y=
ou
>     > are not the intended recipient be aware that any disclosure, copyin=
g,
>     > distribution or use of the contents of this information, even if
>     > partially, including attached files, is strictly prohibited, will be
>     > considered a criminal offense, so you must reply to the original
>     > sender to inform about this communication and delete it.
>     >=20
>     >=20
>     >=20
>     > _______________________________________________
>     > v6ops mailing list
>     > v6ops@ietf.org
>     > https://www.ietf.org/mailman/listinfo/v6ops
>=20
>     --
>=20
>     dave@plonka.us  http://www.cs.wisc.edu/~plonka/
>=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


--nextPart2160319.rLbFpxMUlt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlydzl4ACgkQtRBl6lEd
5Vy0Ygf8CDFPcS7yQ8RCKMUjVnA88rc9HmiKnQV8T/RbbsL2ESatgHC1kcxnuC93
yakY05ytggT8P7qVABR5zO4XFZKzjiSWlD9LISNfRStK7re146bmRXoKVoCbnxss
yXIGCpIErMEnOoPlIfea4Q80A1JnR27oeC5NGros3Z3poNN2V07SbdPB9mOANxtB
q0oajBTedK248tfvtjrOh3md8wX2BZdWYQHZ0sGRG6GgftU2/7p4VvMUf3/Gp0NX
S6I9zwQXRI4jKMECrn4E4oB7DGu0oAyhIRW6cCBqbbNdZiMry2/BrvUzBI8aBjeA
pDxsD3Y4WFrd0dOom4dXtQNDBNl99g==
=9Y2B
-----END PGP SIGNATURE-----

--nextPart2160319.rLbFpxMUlt--




From nobody Fri Mar 29 00:56: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 8F2D51202ED for ; Fri, 29 Mar 2019 00:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 rD8X0lvKuLbT for ; Fri, 29 Mar 2019 00:56:25 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B374D120203 for ; Fri, 29 Mar 2019 00:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553846182; x=1554450982; 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=MBtZNsak jlvR0BtxnQj0sWOIW2loooMtKUC9uYRyAMI=; b=Ut+4gNZ22+7cauAU1CjUYQXx 8qD1rKVWBPELCxtr3lMNSqJq+tqd1uXOED1W2nyXqN2AXtnHkVscClUQVzmkH3kM W3kXIbVYj/uB5e8DcmXItVX0HscxaSWIw79POAVmlkdo08DHm6CDCrdhJyQQqMBM /TLd/zSAbkr1YvLk/bw=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 29 Mar 2019 08:56:22 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 29 Mar 2019 08:56:22 +0100
Received: from [31.133.151.187] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006202418.msg for ; Fri, 29 Mar 2019 08:56:22 +0100
X-MDRemoteIP: 2001:67c:1232:144:c8a9:c9d5:6eed:e60
X-MDHelo: [31.133.151.187]
X-MDArrival-Date: Fri, 29 Mar 2019 08:56:22 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=199112b751=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Fri, 29 Mar 2019 08:56:17 +0100
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <94687473-BB61-49D0-8AF5-88A3CBEEDD82@consulintel.es>
Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>   <3848353.jbcFU8J3gA@asclepius>
In-Reply-To: <3848353.jbcFU8J3gA@asclepius>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 07:56:31 -0000

Hi Martin,

Not sure to completely understand you. May be an explicit example will make=
 it more obvious to me, but see first the following:

The EAMT will create an entry with an AAAA (if available) for each A.

So, if it works with "DNS" it will work with the EAMT.

Regards,
Jordi
=20
=20

=EF=BB=BFEl 29/3/19 8:52, "v6ops en nombre de Martin Hun=C4=9Bk"  escribi=C3=B3:

    Hi Jordi,
   =20
    I would like to point out a question I've asked to you after session:
   =20
    Would it work if a multiple sides would be under the single proxy on IP=
v4, but=20
    on separate hosts on IPv6? Wouldn't it make just one side accessible an=
d rest=20
    would be pointed to wrong server?
   =20
    Regards,
    Martin
   =20
    Dne =C4=8Dtvrtek 28. b=C5=99ezna 2019 16:49:24 CET, JORDI PALET MARTINE=
Z napsal(a):
    > Hi Dave,
    >=20
    > After the meeting, I figured out that that's probably easier and no n=
eed to
    > determine if it is an IPv4-only host.
    >=20
    > We can just create the EAMT entry for any A request if there is a
    > corresponding AAAA which doesn't contain the WKP or NSP. This means t=
hat
    > the end-host (CDN) is dual-stacked.
    >=20
    > Then any host using the A record will automatically get the NAT46 tra=
nslated
    > to the "real" AAAA, not the one with the WKP or NSP, so we fulfil the
    > intended optimization not requiring knowing if the host is IPv4-only.
    >=20
    > I think that's what you are meaning?
    >=20
    > The other think is how to select what AAAA to use if there are severa=
l.
    >=20
    > I really think it will be interesting to get some co-authors, or at l=
east
    > good inputs from CDN/caches operators on this.
    >=20
    > Regards,
    > Jordi
    >=20
    >=20
    >=20
    > =EF=BB=BFEl 28/3/19 15:35, "Dave Plonka"  escribi=C3=
=B3:
    >=20
    >     Hi Jordi -
    >=20
    >     Thanks for this draft presentation in v6ops.
    >=20
    >     As we mentioned in the v6ops meeting, I don't think a CPE (or any
    >     remote host) can reliably determine if a given IPv4 DNS client is=
 an
    >     IPv4-only host.
    >=20
    >     For one, this is because dual-stack hosts have at least two diffe=
rent
    >     IP addresses (v4 and v6), as you know, and there isn't a simple w=
ay to
    >     remotely determine that a given IPv4 address and a given IPv6 add=
ress
    >     are actually bound to the same host's interface(s), or even to en=
force
    >     that a dual-stack host will query the same DNS recursive service =
when
    >     using two (or more) different client (IPv4 and IPv6) addresses.
    >=20
    >     However, for your draft, couldn't we just eliminate any attempt t=
o
    >     determine if any hosts are v4-only or not, and always synthesize =
the
    >     IPv4 DNS answers?
    >=20
    >     I'm not saying I'm in favor of the mechanism overall, just saying=
 we
    >     could avoid the unnecessary and error-prone step of trying to
    >     determine if a host is v4 only.
    >=20
    >     Does that make sense?
    >=20
    >     Thanks,
    >     Dave
    >=20
    >=20
    >     On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
    >=20
    >      wrote:
    >     > Hi all,
    >     >=20
    >     > We have published a new version of this document, taking in
    >     > consideration a few inputs, clarified some examples, nits, etc.
    >     >=20
    >     > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-=
cdn-cac
    >     > hes/?include_text=3D1
    >     >=20
    >     > Regards,
    >     > Jordi
    >     >=20
    >     > =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
    >     >     A new version of I-D,
    >     >     draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
    >     >     has been successfully submitted by Jordi Palet Martinez and=
 posted
    >     >     to the
    >     >     IETF repository.
    >     >    =20
    >     >     Name:               draft-palet-v6ops-464xlat-opt-cdn-cache=
s
    >     >     Revision:   01
    >     >     Title:              464XLAT Optimization for CDNs/Caches
    >     >     Document date:      2019-03-25
    >     >     Group:              Individual Submission
    >     >     Pages:              10
    >     >     URL:          =20
    >     >     https://www.ietf.org/internet-drafts/draft-palet-v6ops-464x=
lat-op
    >     >     t-cdn-caches-01.txt Status:       =20
    >     >     https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-=
opt-cd
    >     >     n-caches/ Htmlized:     =20
    >     >     https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-c=
dn-cac
    >     >     hes-01 Htmlized:     =20
    >     >     https://datatracker.ietf.org/doc/html/draft-palet-v6ops-464=
xlat-o
    >     >     pt-cdn-caches Diff:         =20
    >     >     https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-464xl=
at-opt-c
    >     >     dn-caches-01    >    =20
    >     >     Abstract:
    >     >        This document describes the drawbacks of IP/ICMP Transla=
tion
    >     >        Algorithm (SIIT), when used as a NAT46, and IPv4-only de=
vices
    >     >        or
    >     >        applications initiate traffic flows to dual-stack CDNs (=
Content
    >     >        Delivery Networks) or Caches, which are forced to be tra=
nslated
    >     >        back
    >     >        to IPv4 by a NAT64.  The document proposes possible solu=
tions
    >     >        to
    >     >        avoid that.
    >     >    =20
    >     >     Please note that it may take a couple of minutes from the t=
ime of
    >     >     submission until the htmlized version and diff are availabl=
e at
    >     >     tools.ietf.org.
    >     >    =20
    >     >     The IETF Secretariat
    >     >=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 privi=
leged
    >     > or confidential. The information is intended to be for the excl=
usive
    >     > use of the individual(s) named above and further non-explicilty
    >     > authorized disclosure, copying, distribution or use of the cont=
ents
    >     > of this information, even if partially, including attached file=
s, is
    >     > strictly prohibited and will be considered a criminal offense. =
If you
    >     > are not the intended recipient be aware that any disclosure, co=
pying,
    >     > distribution or use of the contents of this information, even i=
f
    >     > partially, including attached files, is strictly prohibited, wi=
ll be
    >     > considered a criminal offense, so you must reply to the origina=
l
    >     > sender to inform about this communication and delete it.
    >     >=20
    >     >=20
    >     >=20
    >     > _______________________________________________
    >     > v6ops mailing list
    >     > v6ops@ietf.org
    >     > https://www.ietf.org/mailman/listinfo/v6ops
    >=20
    >     --
    >=20
    >     dave@plonka.us  http://www.cs.wisc.edu/~plonka/
    >=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, distributio=
n 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 thi=
s
    > 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 Fri Mar 29 01:05:52 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ADB120229 for ; Fri, 29 Mar 2019 01:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MT-Mzjd7DeK for ; Fri, 29 Mar 2019 01:05:47 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 CB69612021B for ; Fri, 29 Mar 2019 01:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [194.228.68.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 0E10E18050A25 for ; Fri, 29 Mar 2019 09:05:42 +0100 (CET)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: v6ops@ietf.org
Date: Fri, 29 Mar 2019 09:05:26 +0100
Message-ID: <1600807.2ZHIhdiWcE@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: <94687473-BB61-49D0-8AF5-88A3CBEEDD82@consulintel.es>
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com> <3848353.jbcFU8J3gA@asclepius> <94687473-BB61-49D0-8AF5-88A3CBEEDD82@consulintel.es>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart7297255.QQJkDrvoFz"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 08:05:50 -0000

--nextPart7297255.QQJkDrvoFz
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Let say:

# Here is HTTP proxy
www.example.com   IN A 192.0.2.64
www.example.net   IN A 192.0.2.64

# Here are IPv6-only hosts
www.example.com   IN AAAA 2001:db8::1:1
www.example.net   IN AAAA 2001:db8::2:1

Now if one (or multiple) host asks for both sides what would be in EAMT?

Martin

Dne p=C3=A1tek 29. b=C5=99ezna 2019 8:56:17 CET, JORDI PALET MARTINEZ napsa=
l(a):
> Hi Martin,
>=20
> Not sure to completely understand you. May be an explicit example will ma=
ke
> it more obvious to me, but see first the following:
>=20
> The EAMT will create an entry with an AAAA (if available) for each A.
>=20
> So, if it works with "DNS" it will work with the EAMT.
>=20
> Regards,
> Jordi
>=20
>=20
>=20
> =EF=BB=BFEl 29/3/19 8:52, "v6ops en nombre de Martin Hun=C4=9Bk"  en nombre de martin.hunek@tul.cz> escribi=C3=B3:
>=20
>     Hi Jordi,
>=20
>     I would like to point out a question I've asked to you after session:
>=20
>     Would it work if a multiple sides would be under the single proxy on
> IPv4, but on separate hosts on IPv6? Wouldn't it make just one side
> accessible and rest would be pointed to wrong server?
>=20
>     Regards,
>     Martin
>=20
>     Dne =C4=8Dtvrtek 28. b=C5=99ezna 2019 16:49:24 CET, JORDI PALET MARTI=
NEZ=20
napsal(a):
>     > Hi Dave,
>     >=20
>     > After the meeting, I figured out that that's probably easier and no
>     > need to
>     > determine if it is an IPv4-only host.
>     >=20
>     > We can just create the EAMT entry for any A request if there is a
>     > corresponding AAAA which doesn't contain the WKP or NSP. This means
>     > that
>     > the end-host (CDN) is dual-stacked.
>     >=20
>     > Then any host using the A record will automatically get the NAT46
>     > translated to the "real" AAAA, not the one with the WKP or NSP, so =
we
>     > fulfil the intended optimization not requiring knowing if the host =
is
>     > IPv4-only.
>     >=20
>     > I think that's what you are meaning?
>     >=20
>     > The other think is how to select what AAAA to use if there are
>     > several.
>     >=20
>     > I really think it will be interesting to get some co-authors, or at
>     > least
>     > good inputs from CDN/caches operators on this.
>     >=20
>     > Regards,
>     > Jordi
>     >=20
>     > =EF=BB=BFEl 28/3/19 15:35, "Dave Plonka"  escribi=
=C3=B3:
>     >     Hi Jordi -
>     >    =20
>     >     Thanks for this draft presentation in v6ops.
>     >    =20
>     >     As we mentioned in the v6ops meeting, I don't think a CPE (or a=
ny
>     >     remote host) can reliably determine if a given IPv4 DNS client =
is
>     >     an
>     >     IPv4-only host.
>     >    =20
>     >     For one, this is because dual-stack hosts have at least two
>     >     different
>     >     IP addresses (v4 and v6), as you know, and there isn't a simple
>     >     way to
>     >     remotely determine that a given IPv4 address and a given IPv6
>     >     address
>     >     are actually bound to the same host's interface(s), or even to
>     >     enforce
>     >     that a dual-stack host will query the same DNS recursive service
>     >     when
>     >     using two (or more) different client (IPv4 and IPv6) addresses.
>     >    =20
>     >     However, for your draft, couldn't we just eliminate any attempt=
 to
>     >     determine if any hosts are v4-only or not, and always synthesize
>     >     the
>     >     IPv4 DNS answers?
>     >    =20
>     >     I'm not saying I'm in favor of the mechanism overall, just sayi=
ng
>     >     we
>     >     could avoid the unnecessary and error-prone step of trying to
>     >     determine if a host is v4 only.
>     >    =20
>     >     Does that make sense?
>     >    =20
>     >     Thanks,
>     >     Dave
>     >    =20
>     >    =20
>     >     On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
>     >    =20
>     >      wrote:
>     >     > Hi all,
>     >     >=20
>     >     > We have published a new version of this document, taking in
>     >     > consideration a few inputs, clarified some examples, nits, et=
c.
>     >     >=20
>     >     > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-op=
t-c
>     >     > dn-cac
>     >     > hes/?include_text=3D1
>     >     >=20
>     >     > Regards,
>     >     > Jordi
>     >     >=20
>     >     > =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org" =20
>     drafts@ietf.org> escribi=C3=B3:
>     >     >     A new version of I-D,
>     >     >     draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
>     >     >     has been successfully submitted by Jordi Palet Martinez a=
nd
>     >     >     posted
>     >     >     to the
>     >     >     IETF repository.
>     >     >    =20
>     >     >     Name:               draft-palet-v6ops-464xlat-opt-cdn-cac=
hes
>     >     >     Revision:   01
>     >     >     Title:              464XLAT Optimization for CDNs/Caches
>     >     >     Document date:      2019-03-25
>     >     >     Group:              Individual Submission
>     >     >     Pages:              10
>     >     >     URL:
>     >     >     https://www.ietf.org/internet-drafts/draft-palet-v6ops-46=
4xl
>     >     >     at-op
>     >     >     t-cdn-caches-01.txt Status:
>     >     >     https://datatracker.ietf.org/doc/draft-palet-v6ops-464xla=
t-o
>     >     >     pt-cd
>     >     >     n-caches/ Htmlized:
>     >     >     https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt=
=2Dcd
>     >     >     n-cac
>     >     >     hes-01 Htmlized:
>     >     >     https://datatracker.ietf.org/doc/html/draft-palet-v6ops-4=
64x
>     >     >     lat-o
>     >     >     pt-cdn-caches Diff:
>     >     >     https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-464=
xlat->     >     >     opt-c
>     >     >     dn-caches-01    >
>     >     >    =20
>     >     >     Abstract:
>     >     >        This document describes the drawbacks of IP/ICMP
>     >     >        Translation
>     >     >        Algorithm (SIIT), when used as a NAT46, and IPv4-only
>     >     >        devices
>     >     >        or
>     >     >        applications initiate traffic flows to dual-stack CDNs
>     >     >        (Content
>     >     >        Delivery Networks) or Caches, which are forced to be
>     >     >        translated
>     >     >        back
>     >     >        to IPv4 by a NAT64.  The document proposes possible
>     >     >        solutions
>     >     >        to
>     >     >        avoid that.
>     >     >    =20
>     >     >     Please note that it may take a couple of minutes from the
>     >     >     time of
>     >     >     submission until the htmlized version and diff are availa=
ble
>     >     >     at
>     >     >     tools.ietf.org.
>     >     >    =20
>     >     >     The IETF Secretariat
>     >     >=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-explicil=
ty
>     >     > 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 origi=
nal
>     >     > sender to inform about this communication and delete it.
>     >     >=20
>     >     >=20
>     >     >=20
>     >     > _______________________________________________
>     >     > v6ops mailing list
>     >     > v6ops@ietf.org
>     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >    =20
>     >     --
>     >    =20
>     >     dave@plonka.us  http://www.cs.wisc.edu/~plonka/
>     >=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 u=
se
>     > 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 strict=
ly
>     > prohibited and will be considered a criminal offense. If you are not
>     > the
>     > intended recipient be aware that any disclosure, copying, distribut=
ion
>     > or
>     > use of the contents of this information, even if partially, includi=
ng
>     > attached files, is strictly prohibited, will be considered a crimin=
al
>     > offense, so you must reply to the original sender to inform about t=
his
>     > 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
>=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


--nextPart7297255.QQJkDrvoFz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlyd0cYACgkQtRBl6lEd
5VwFCgf9EV68EHiivUiQ+k/W2xurSklYQdyfh6rBcGlhqAHY7+DMj7KhPKA8BIA+
lFBkpmwX6mlGsKwgGYsvMKWngMdXYYqNc3m1aGwhZVriT72S6DYZg0GPMFxhR0de
lpDxw5PmMwos7TENHvbHfQs6PMaxk5HG9POqlpa35fZXnY9E+CGclcjNlwHD+hGV
kUEp+3t/nNO5U/EE5ygyjxIK30zeCQ1dYk1kzqNnwokUUc+6zTIQvG4SYR5yrvHH
FItU2/82OIcNyQljUzEdKQUVNdGKmko7fEa1lYedgzgAfc3HfV7lHJytLGC/+uun
4434sAGUxhEwt5fzO8mUKT4wIMKEeA==
=2I18
-----END PGP SIGNATURE-----

--nextPart7297255.QQJkDrvoFz--




From nobody Fri Mar 29 01:10: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 CFFAF1203CE for ; Fri, 29 Mar 2019 01:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 4wrirO-3Vi-Z for ; Fri, 29 Mar 2019 01:09:53 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBC91202C2 for ; Fri, 29 Mar 2019 01:09:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553846991; x=1554451791; 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=CuQ/XhCm bLHm6Dpl7sYjQVX9RxP5Lo3aDSXARqzza80=; b=QJ30YaE9zuk9HO3D0guphgR9 619XdCFtIgItEueLyMyire6kZPbvy7ZZcOW71vCRxAQ+w1Ob+Igv3SXhCYAzmGOz lYebrI7/lZg8q4NPQaqnUYKOIuzFlAScze9wXkWoUxXnx0uR8eYjK4+298xVTKvp 2Bo7/zv2IQZY0Q3AG0w=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 29 Mar 2019 09:09:51 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 29 Mar 2019 09:09:48 +0100
Received: from [31.133.151.187] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006202435.msg for ; Fri, 29 Mar 2019 09:09:47 +0100
X-MDRemoteIP: 2001:67c:1232:144:c8a9:c9d5:6eed:e60
X-MDHelo: [31.133.151.187]
X-MDArrival-Date: Fri, 29 Mar 2019 09:09:47 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=199112b751=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Fri, 29 Mar 2019 09:09:44 +0100
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <9446D127-82F4-4196-BB8A-FB4D12D369D0@consulintel.es>
Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com> <3848353.jbcFU8J3gA@asclepius> <94687473-BB61-49D0-8AF5-88A3CBEEDD82@consulintel.es> <1600807.2ZHIhdiWcE@asclepius>
In-Reply-To: <1600807.2ZHIhdiWcE@asclepius>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 08:10:04 -0000

Unless I'm wrong, this will also fail with the standard NAT64/DNS64 behavio=
r !

So, we aren't breaking anything at it is broken already :-(

Regards,
Jordi
=20
=20

=EF=BB=BFEl 29/3/19 9:06, "v6ops en nombre de Martin Hun=C4=9Bk"  escribi=C3=B3:

    Let say:
   =20
    # Here is HTTP proxy
    www.example.com   IN A 192.0.2.64
    www.example.net   IN A 192.0.2.64
   =20
    # Here are IPv6-only hosts
    www.example.com   IN AAAA 2001:db8::1:1
    www.example.net   IN AAAA 2001:db8::2:1
   =20
    Now if one (or multiple) host asks for both sides what would be in EAMT=
?
   =20
    Martin
   =20
    Dne p=C3=A1tek 29. b=C5=99ezna 2019 8:56:17 CET, JORDI PALET MARTINEZ n=
apsal(a):
    > Hi Martin,
    >=20
    > Not sure to completely understand you. May be an explicit example wil=
l make
    > it more obvious to me, but see first the following:
    >=20
    > The EAMT will create an entry with an AAAA (if available) for each A.
    >=20
    > So, if it works with "DNS" it will work with the EAMT.
    >=20
    > Regards,
    > Jordi
    >=20
    >=20
    >=20
    > =EF=BB=BFEl 29/3/19 8:52, "v6ops en nombre de Martin Hun=C4=9Bk"  en nombre de martin.hunek@tul.cz> escribi=C3=B3:
    >=20
    >     Hi Jordi,
    >=20
    >     I would like to point out a question I've asked to you after sess=
ion:
    >=20
    >     Would it work if a multiple sides would be under the single proxy=
 on
    > IPv4, but on separate hosts on IPv6? Wouldn't it make just one side
    > accessible and rest would be pointed to wrong server?
    >=20
    >     Regards,
    >     Martin
    >=20
    >     Dne =C4=8Dtvrtek 28. b=C5=99ezna 2019 16:49:24 CET, JORDI PALET M=
ARTINEZ=20
    napsal(a):
    >     > Hi Dave,
    >     >=20
    >     > After the meeting, I figured out that that's probably easier an=
d no
    >     > need to
    >     > determine if it is an IPv4-only host.
    >     >=20
    >     > We can just create the EAMT entry for any A request if there is=
 a
    >     > corresponding AAAA which doesn't contain the WKP or NSP. This m=
eans
    >     > that
    >     > the end-host (CDN) is dual-stacked.
    >     >=20
    >     > Then any host using the A record will automatically get the NAT=
46
    >     > translated to the "real" AAAA, not the one with the WKP or NSP,=
 so we
    >     > fulfil the intended optimization not requiring knowing if the h=
ost is
    >     > IPv4-only.
    >     >=20
    >     > I think that's what you are meaning?
    >     >=20
    >     > The other think is how to select what AAAA to use if there are
    >     > several.
    >     >=20
    >     > I really think it will be interesting to get some co-authors, o=
r at
    >     > least
    >     > good inputs from CDN/caches operators on this.
    >     >=20
    >     > Regards,
    >     > Jordi
    >     >=20
    >     > =EF=BB=BFEl 28/3/19 15:35, "Dave Plonka"  escri=
bi=C3=B3:
    >     >     Hi Jordi -
    >     >    =20
    >     >     Thanks for this draft presentation in v6ops.
    >     >    =20
    >     >     As we mentioned in the v6ops meeting, I don't think a CPE (=
or any
    >     >     remote host) can reliably determine if a given IPv4 DNS cli=
ent is
    >     >     an
    >     >     IPv4-only host.
    >     >    =20
    >     >     For one, this is because dual-stack hosts have at least two
    >     >     different
    >     >     IP addresses (v4 and v6), as you know, and there isn't a si=
mple
    >     >     way to
    >     >     remotely determine that a given IPv4 address and a given IP=
v6
    >     >     address
    >     >     are actually bound to the same host's interface(s), or even=
 to
    >     >     enforce
    >     >     that a dual-stack host will query the same DNS recursive se=
rvice
    >     >     when
    >     >     using two (or more) different client (IPv4 and IPv6) addres=
ses.
    >     >    =20
    >     >     However, for your draft, couldn't we just eliminate any att=
empt to
    >     >     determine if any hosts are v4-only or not, and always synth=
esize
    >     >     the
    >     >     IPv4 DNS answers?
    >     >    =20
    >     >     I'm not saying I'm in favor of the mechanism overall, just =
saying
    >     >     we
    >     >     could avoid the unnecessary and error-prone step of trying =
to
    >     >     determine if a host is v4 only.
    >     >    =20
    >     >     Does that make sense?
    >     >    =20
    >     >     Thanks,
    >     >     Dave
    >     >    =20
    >     >    =20
    >     >     On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
    >     >    =20
    >     >      wrote:
    >     >     > Hi all,
    >     >     >=20
    >     >     > We have published a new version of this document, taking =
in
    >     >     > consideration a few inputs, clarified some examples, nits=
, etc.
    >     >     >=20
    >     >     > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xla=
t-opt-c
    >     >     > dn-cac
    >     >     > hes/?include_text=3D1
    >     >     >=20
    >     >     > Regards,
    >     >     > Jordi
    >     >     >=20
    >     >     > =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org" =20
    >     drafts@ietf.org> escribi=C3=B3:
    >     >     >     A new version of I-D,
    >     >     >     draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
    >     >     >     has been successfully submitted by Jordi Palet Martin=
ez and
    >     >     >     posted
    >     >     >     to the
    >     >     >     IETF repository.
    >     >     >    =20
    >     >     >     Name:               draft-palet-v6ops-464xlat-opt-cdn=
-caches
    >     >     >     Revision:   01
    >     >     >     Title:              464XLAT Optimization for CDNs/Cac=
hes
    >     >     >     Document date:      2019-03-25
    >     >     >     Group:              Individual Submission
    >     >     >     Pages:              10
    >     >     >     URL:
    >     >     >     https://www.ietf.org/internet-drafts/draft-palet-v6op=
s-464xl
    >     >     >     at-op
    >     >     >     t-cdn-caches-01.txt Status:
    >     >     >     https://datatracker.ietf.org/doc/draft-palet-v6ops-46=
4xlat-o
    >     >     >     pt-cd
    >     >     >     n-caches/ Htmlized:
    >     >     >     https://tools.ietf.org/html/draft-palet-v6ops-464xlat=
-opt-cd
    >     >     >     n-cac
    >     >     >     hes-01 Htmlized:
    >     >     >     https://datatracker.ietf.org/doc/html/draft-palet-v6o=
ps-464x
    >     >     >     lat-o
    >     >     >     pt-cdn-caches Diff:
    >     >     >     https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops=
-464xlat->     >     >     opt-c
    >     >     >     dn-caches-01    >
    >     >     >    =20
    >     >     >     Abstract:
    >     >     >        This document describes the drawbacks of IP/ICMP
    >     >     >        Translation
    >     >     >        Algorithm (SIIT), when used as a NAT46, and IPv4-o=
nly
    >     >     >        devices
    >     >     >        or
    >     >     >        applications initiate traffic flows to dual-stack =
CDNs
    >     >     >        (Content
    >     >     >        Delivery Networks) or Caches, which are forced to =
be
    >     >     >        translated
    >     >     >        back
    >     >     >        to IPv4 by a NAT64.  The document proposes possibl=
e
    >     >     >        solutions
    >     >     >        to
    >     >     >        avoid that.
    >     >     >    =20
    >     >     >     Please note that it may take a couple of minutes from=
 the
    >     >     >     time of
    >     >     >     submission until the htmlized version and diff are av=
ailable
    >     >     >     at
    >     >     >     tools.ietf.org.
    >     >     >    =20
    >     >     >     The IETF Secretariat
    >     >     >=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 th=
e
    >     >     > exclusive
    >     >     > use of the individual(s) named above and further non-expl=
icilty
    >     >     > authorized disclosure, copying, distribution or use of th=
e
    >     >     > contents
    >     >     > of this information, even if partially, including attache=
d
    >     >     > files, is
    >     >     > strictly prohibited and will be considered a criminal off=
ense.
    >     >     > If you
    >     >     > are not the intended recipient be aware that any disclosu=
re,
    >     >     > copying,
    >     >     > distribution or use of the contents of this information, =
even if
    >     >     > partially, including attached files, is strictly prohibit=
ed,
    >     >     > will be
    >     >     > considered a criminal offense, so you must reply to the o=
riginal
    >     >     > sender to inform about this communication and delete it.
    >     >     >=20
    >     >     >=20
    >     >     >=20
    >     >     > _______________________________________________
    >     >     > v6ops mailing list
    >     >     > v6ops@ietf.org
    >     >     > https://www.ietf.org/mailman/listinfo/v6ops
    >     >    =20
    >     >     --
    >     >    =20
    >     >     dave@plonka.us  http://www.cs.wisc.edu/~plonka/
    >     >=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 privi=
leged
    >     > or
    >     > confidential. The information is intended to be for the exclusi=
ve use
    >     > of
    >     > the individual(s) named above and further non-explicilty author=
ized
    >     > disclosure, copying, distribution or use of the contents of thi=
s
    >     > information, even if partially, including attached files, is st=
rictly
    >     > prohibited and will be considered a criminal offense. If you ar=
e not
    >     > the
    >     > intended recipient be aware that any disclosure, copying, distr=
ibution
    >     > or
    >     > use of the contents of this information, even if partially, inc=
luding
    >     > attached files, is strictly prohibited, will be considered a cr=
iminal
    >     > offense, so you must reply to the original sender to inform abo=
ut 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
    >=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, distributio=
n 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 thi=
s
    > 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 Fri Mar 29 01:18:11 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A514F120144 for ; Fri, 29 Mar 2019 01:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q0UpK_FmcoH for ; Fri, 29 Mar 2019 01:18:05 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5367912021B for ; Fri, 29 Mar 2019 01:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [194.228.68.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 57A1618050A25 for ; Fri, 29 Mar 2019 09:18:01 +0100 (CET)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: v6ops@ietf.org
Date: Fri, 29 Mar 2019 09:17:50 +0100
Message-ID: <3557915.46nGyDddxY@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: <9446D127-82F4-4196-BB8A-FB4D12D369D0@consulintel.es>
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com> <1600807.2ZHIhdiWcE@asclepius> <9446D127-82F4-4196-BB8A-FB4D12D369D0@consulintel.es>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2113405.grBDmYnXVu"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 08:18:09 -0000

--nextPart2113405.grBDmYnXVu
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

I'm not sure about that. In case of NAT64 it would reach the destination by=
=20
IPv4, then trough a proxy to IPv6 only host. Same goes for 464XLAT. Not=20
mentioning that in such case it should go directly over IPv6.

Maybe I'm just imagine things, I'm not in content delivery, but I think tha=
t=20
this situation might happen in IPv6-only datacenter.

Martin

Dne p=C3=A1tek 29. b=C5=99ezna 2019 9:09:44 CET, JORDI PALET MARTINEZ napsa=
l(a):
> Unless I'm wrong, this will also fail with the standard NAT64/DNS64 behav=
ior
> !
>=20
> So, we aren't breaking anything at it is broken already :-(
>=20
> Regards,
> Jordi
>=20
>=20
>=20
> =EF=BB=BFEl 29/3/19 9:06, "v6ops en nombre de Martin Hun=C4=9Bk"  en nombre de martin.hunek@tul.cz> escribi=C3=B3:
>=20
>     Let say:
>=20
>     # Here is HTTP proxy
>     www.example.com   IN A 192.0.2.64
>     www.example.net   IN A 192.0.2.64
>=20
>     # Here are IPv6-only hosts
>     www.example.com   IN AAAA 2001:db8::1:1
>     www.example.net   IN AAAA 2001:db8::2:1
>=20
>     Now if one (or multiple) host asks for both sides what would be in EA=
MT?
>=20
>     Martin
>=20
>     Dne p=C3=A1tek 29. b=C5=99ezna 2019 8:56:17 CET, JORDI PALET MARTINEZ=
 napsal(a):
>     > Hi Martin,
>     >=20
>     > Not sure to completely understand you. May be an explicit example w=
ill
>     > make
>     > it more obvious to me, but see first the following:
>     >=20
>     > The EAMT will create an entry with an AAAA (if available) for each =
A.
>     >=20
>     > So, if it works with "DNS" it will work with the EAMT.
>     >=20
>     > Regards,
>     > Jordi
>     >=20
>     >=20
>     >=20
>     > =EF=BB=BFEl 29/3/19 8:52, "v6ops en nombre de Martin Hun=C4=9Bk"
>     >      >=20
>     > en nombre de martin.hunek@tul.cz> escribi=C3=B3:
>     >     Hi Jordi,
>     >    =20
>     >     I would like to point out a question I've asked to you after
>     >     session:
>     >    =20
>     >     Would it work if a multiple sides would be under the single pro=
xy
>     >     on
>     >=20
>     > IPv4, but on separate hosts on IPv6? Wouldn't it make just one side
>     > accessible and rest would be pointed to wrong server?
>     >=20
>     >     Regards,
>     >     Martin
>     >    =20
>     >     Dne =C4=8Dtvrtek 28. b=C5=99ezna 2019 16:49:24 CET, JORDI PALET=
 MARTINEZ
>=20
>     napsal(a):
>     >     > Hi Dave,
>     >     >=20
>     >     > After the meeting, I figured out that that's probably easier =
and
>     >     > no
>     >     > need to
>     >     > determine if it is an IPv4-only host.
>     >     >=20
>     >     > We can just create the EAMT entry for any A request if there =
is
>     >     > a
>     >     > corresponding AAAA which doesn't contain the WKP or NSP. This
>     >     > means
>     >     > that
>     >     > the end-host (CDN) is dual-stacked.
>     >     >=20
>     >     > Then any host using the A record will automatically get the
>     >     > NAT46
>     >     > translated to the "real" AAAA, not the one with the WKP or NS=
P,
>     >     > so we
>     >     > fulfil the intended optimization not requiring knowing if the
>     >     > host is
>     >     > IPv4-only.
>     >     >=20
>     >     > I think that's what you are meaning?
>     >     >=20
>     >     > The other think is how to select what AAAA to use if there are
>     >     > several.
>     >     >=20
>     >     > I really think it will be interesting to get some co-authors,=
 or
>     >     > at
>     >     > least
>     >     > good inputs from CDN/caches operators on this.
>     >     >=20
>     >     > Regards,
>     >     > Jordi
>     >     >=20
>     >     > =EF=BB=BFEl 28/3/19 15:35, "Dave Plonka"  esc=
ribi=C3=B3:
>     >     >     Hi Jordi -
>     >     >    =20
>     >     >     Thanks for this draft presentation in v6ops.
>     >     >    =20
>     >     >     As we mentioned in the v6ops meeting, I don't think a CPE
>     >     >     (or any
>     >     >     remote host) can reliably determine if a given IPv4 DNS
>     >     >     client is
>     >     >     an
>     >     >     IPv4-only host.
>     >     >    =20
>     >     >     For one, this is because dual-stack hosts have at least t=
wo
>     >     >     different
>     >     >     IP addresses (v4 and v6), as you know, and there isn't a
>     >     >     simple
>     >     >     way to
>     >     >     remotely determine that a given IPv4 address and a given
>     >     >     IPv6
>     >     >     address
>     >     >     are actually bound to the same host's interface(s), or ev=
en
>     >     >     to
>     >     >     enforce
>     >     >     that a dual-stack host will query the same DNS recursive
>     >     >     service
>     >     >     when
>     >     >     using two (or more) different client (IPv4 and IPv6)
>     >     >     addresses.
>     >     >    =20
>     >     >     However, for your draft, couldn't we just eliminate any
>     >     >     attempt to
>     >     >     determine if any hosts are v4-only or not, and always
>     >     >     synthesize
>     >     >     the
>     >     >     IPv4 DNS answers?
>     >     >    =20
>     >     >     I'm not saying I'm in favor of the mechanism overall, just
>     >     >     saying
>     >     >     we
>     >     >     could avoid the unnecessary and error-prone step of trying
>     >     >     to
>     >     >     determine if a host is v4 only.
>     >     >    =20
>     >     >     Does that make sense?
>     >     >    =20
>     >     >     Thanks,
>     >     >     Dave
>     >     >    =20
>     >     >    =20
>     >     >     On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
>     >     >    =20
>     >     >      wrote:
>     >     >     > Hi all,
>     >     >     >=20
>     >     >     > We have published a new version of this document, taking
>     >     >     > in
>     >     >     > consideration a few inputs, clarified some examples, ni=
ts,
>     >     >     > etc.
>     >     >     >=20
>     >     >     > https://datatracker.ietf.org/doc/draft-palet-v6ops-464x=
lat
>     >     >     > -opt-c
>     >     >     > dn-cac
>     >     >     > hes/?include_text=3D1
>     >     >     >=20
>     >     >     > Regards,
>     >     >     > Jordi
>     >     >     >=20
>     >     >     > =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org" <=
internet-
>     >    =20
>     >     drafts@ietf.org> escribi=C3=B3:
>     >     >     >     A new version of I-D,
>     >     >     >     draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
>     >     >     >     has been successfully submitted by Jordi Palet
>     >     >     >     Martinez and
>     >     >     >     posted
>     >     >     >     to the
>     >     >     >     IETF repository.
>     >     >     >    =20
>     >     >     >     Name:             =20
>     >     >     >     draft-palet-v6ops-464xlat-opt-cdn-caches
>     >     >     >     Revision:   01
>     >     >     >     Title:              464XLAT Optimization for
>     >     >     >     CDNs/Caches
>     >     >     >     Document date:      2019-03-25
>     >     >     >     Group:              Individual Submission
>     >     >     >     Pages:              10
>     >     >     >     URL:
>     >     >     >     https://www.ietf.org/internet-drafts/draft-palet-v6=
ops
>     >     >     >     -464xl
>     >     >     >     at-op
>     >     >     >     t-cdn-caches-01.txt Status:
>     >     >     >     https://datatracker.ietf.org/doc/draft-palet-v6ops-=
464
>     >     >     >     xlat-o
>     >     >     >     pt-cd
>     >     >     >     n-caches/ Htmlized:
>     >     >     >     https://tools.ietf.org/html/draft-palet-v6ops-464xl=
at->     >     >     >     opt-cd
>     >     >     >     n-cac
>     >     >     >     hes-01 Htmlized:
>     >     >     >     https://datatracker.ietf.org/doc/html/draft-palet-v=
6op
>     >     >     >     s-464x
>     >     >     >     lat-o
>     >     >     >     pt-cdn-caches Diff:
>     >     >     >     https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6o=
ps-46
>     >     >     >     4xlat->     >     >     opt-c dn-caches-01    >
>     >     >     >    =20
>     >     >     >     Abstract:
>     >     >     >        This document describes the drawbacks of IP/ICMP
>     >     >     >        Translation
>     >     >     >        Algorithm (SIIT), when used as a NAT46, and
>     >     >     >        IPv4-only
>     >     >     >        devices
>     >     >     >        or
>     >     >     >        applications initiate traffic flows to dual-stack
>     >     >     >        CDNs
>     >     >     >        (Content
>     >     >     >        Delivery Networks) or Caches, which are forced to
>     >     >     >        be
>     >     >     >        translated
>     >     >     >        back
>     >     >     >        to IPv4 by a NAT64.  The document proposes possi=
ble
>     >     >     >        solutions
>     >     >     >        to
>     >     >     >        avoid that.
>     >     >     >    =20
>     >     >     >     Please note that it may take a couple of minutes fr=
om
>     >     >     >     the
>     >     >     >     time of
>     >     >     >     submission until the htmlized version and diff are
>     >     >     >     available
>     >     >     >     at
>     >     >     >     tools.ietf.org.
>     >     >     >    =20
>     >     >     >     The IETF Secretariat
>     >     >     >=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 attac=
hed
>     >     >     > files, is
>     >     >     > strictly prohibited and will be considered a criminal
>     >     >     > offense.
>     >     >     > If you
>     >     >     > are not the intended recipient be aware that any
>     >     >     > disclosure,
>     >     >     > copying,
>     >     >     > distribution or use of the contents of this information,
>     >     >     > even if
>     >     >     > partially, including attached files, is strictly
>     >     >     > prohibited,
>     >     >     > will be
>     >     >     > considered a criminal offense, so you must reply to the
>     >     >     > original
>     >     >     > sender to inform about this communication and delete it.
>     >     >     >=20
>     >     >     >=20
>     >     >     >=20
>     >     >     > _______________________________________________
>     >     >     > v6ops mailing list
>     >     >     > v6ops@ietf.org
>     >     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >     >    =20
>     >     >     --
>     >     >    =20
>     >     >     dave@plonka.us  http://www.cs.wisc.edu/~plonka/
>     >     >=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 t=
his
>     >     > 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
>     >=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 u=
se
>     > 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 strict=
ly
>     > prohibited and will be considered a criminal offense. If you are not
>     > the
>     > intended recipient be aware that any disclosure, copying, distribut=
ion
>     > or
>     > use of the contents of this information, even if partially, includi=
ng
>     > attached files, is strictly prohibited, will be considered a crimin=
al
>     > offense, so you must reply to the original sender to inform about t=
his
>     > 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
>=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


--nextPart2113405.grBDmYnXVu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlyd1K4ACgkQtRBl6lEd
5VwMDQgAvejtEmdB4a4MhJd1etwduKD8A5FTs9935OmJ3xxvjwQ1Ar+3Pt4veHzw
q0byTlnHZqZPffr4k3+LixhbbJN4uvhrB5qSNRYPOd2eMz49VZbVOQiAEZPPYvwY
2q0pwiIosfJpiaQmW8LmK4h8LtoIrZVcM76xiIkAIDMp2Vr8oSthIxNGmtCkIze0
XMM7eAm3dk+nzQDExnArCaxZ9S36XpqAJi+XS0U8/HoQxBZCg4NdgXoqPHD9gGGP
Cth08SrHRfeI3Yn79m9CxKmEH1ezEvx431B/61cRokAaRpJmk7nTKXmXkoyIvorP
AAwCnZrNlNEg4Vx7qxN2OXYjaia/4A==
=LhqV
-----END PGP SIGNATURE-----

--nextPart2113405.grBDmYnXVu--




From nobody Fri Mar 29 01:30: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 811FA120437 for ; Fri, 29 Mar 2019 01:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 uAglbWpn7gd6 for ; Fri, 29 Mar 2019 01:30:21 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF48E120425 for ; Fri, 29 Mar 2019 01:30:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553848219; x=1554453019; 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=FKfEBgv5 t7aa5E9IHtLz++yITAvU9TwcG6kHG/alqbU=; b=qCZPE+pavXaknr1RbvkK27N+ QlsTOPpLyFWJJSnmtAAcvkh2YhfSySggeht284mCP9cXRt3LVqsilwPkbRU/7jAH enpoGV7/DaPcQxoAK95zrurlYNaYsUKVrN4EYvr69SnpWEw4MccsDGxO5XEDhggw ZVK4QMVwfhp3GrHhue4=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 29 Mar 2019 09:30:19 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 29 Mar 2019 09:30:18 +0100
Received: from [31.133.151.187] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006202446.msg for ; Fri, 29 Mar 2019 09:30:17 +0100
X-MDRemoteIP: 2001:67c:1232:144:c8a9:c9d5:6eed:e60
X-MDHelo: [31.133.151.187]
X-MDArrival-Date: Fri, 29 Mar 2019 09:30:17 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=199112b751=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Fri, 29 Mar 2019 09:30:12 +0100
From: JORDI PALET MARTINEZ 
To: 
Message-ID: 
Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com> <1600807.2ZHIhdiWcE@asclepius> <9446D127-82F4-4196-BB8A-FB4D12D369D0@consulintel.es> <3557915.46nGyDddxY@asclepius>
In-Reply-To: <3557915.46nGyDddxY@asclepius>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 08:30:33 -0000

It may depend on "where" is located the proxy.

I don't think this is something that is used. If you have a dual-stack serv=
ice or website, I don't see why it is practical to have it in different hos=
ts. I see the same host having different apache "virtual servers" if you re=
ally want to show different contents for IPv4 and IPv6, but even do ... I r=
eally doubt.

If an IPv6-only DC is using SIIT-DC, I also don't see the case where this w=
ill fail. I will investigate a bit more, just in case.

Regards,
Jordi
=20
=20

=EF=BB=BFEl 29/3/19 9:18, "v6ops en nombre de Martin Hun=C4=9Bk"  escribi=C3=B3:

    I'm not sure about that. In case of NAT64 it would reach the destinatio=
n by=20
    IPv4, then trough a proxy to IPv6 only host. Same goes for 464XLAT. Not=
=20
    mentioning that in such case it should go directly over IPv6.
   =20
    Maybe I'm just imagine things, I'm not in content delivery, but I think=
 that=20
    this situation might happen in IPv6-only datacenter.
   =20
    Martin
   =20
    Dne p=C3=A1tek 29. b=C5=99ezna 2019 9:09:44 CET, JORDI PALET MARTINEZ n=
apsal(a):
    > Unless I'm wrong, this will also fail with the standard NAT64/DNS64 b=
ehavior
    > !
    >=20
    > So, we aren't breaking anything at it is broken already :-(
    >=20
    > Regards,
    > Jordi
    >=20
    >=20
    >=20
    > =EF=BB=BFEl 29/3/19 9:06, "v6ops en nombre de Martin Hun=C4=9Bk"  en nombre de martin.hunek@tul.cz> escribi=C3=B3:
    >=20
    >     Let say:
    >=20
    >     # Here is HTTP proxy
    >     www.example.com   IN A 192.0.2.64
    >     www.example.net   IN A 192.0.2.64
    >=20
    >     # Here are IPv6-only hosts
    >     www.example.com   IN AAAA 2001:db8::1:1
    >     www.example.net   IN AAAA 2001:db8::2:1
    >=20
    >     Now if one (or multiple) host asks for both sides what would be i=
n EAMT?
    >=20
    >     Martin
    >=20
    >     Dne p=C3=A1tek 29. b=C5=99ezna 2019 8:56:17 CET, JORDI PALET MART=
INEZ napsal(a):
    >     > Hi Martin,
    >     >=20
    >     > Not sure to completely understand you. May be an explicit examp=
le will
    >     > make
    >     > it more obvious to me, but see first the following:
    >     >=20
    >     > The EAMT will create an entry with an AAAA (if available) for e=
ach A.
    >     >=20
    >     > So, if it works with "DNS" it will work with the EAMT.
    >     >=20
    >     > Regards,
    >     > Jordi
    >     >=20
    >     >=20
    >     >=20
    >     > =EF=BB=BFEl 29/3/19 8:52, "v6ops en nombre de Martin Hun=C4=9Bk=
"
    >     >      >=20
    >     > en nombre de martin.hunek@tul.cz> escribi=C3=B3:
    >     >     Hi Jordi,
    >     >    =20
    >     >     I would like to point out a question I've asked to you afte=
r
    >     >     session:
    >     >    =20
    >     >     Would it work if a multiple sides would be under the single=
 proxy
    >     >     on
    >     >=20
    >     > IPv4, but on separate hosts on IPv6? Wouldn't it make just one =
side
    >     > accessible and rest would be pointed to wrong server?
    >     >=20
    >     >     Regards,
    >     >     Martin
    >     >    =20
    >     >     Dne =C4=8Dtvrtek 28. b=C5=99ezna 2019 16:49:24 CET, JORDI P=
ALET MARTINEZ
    >=20
    >     napsal(a):
    >     >     > Hi Dave,
    >     >     >=20
    >     >     > After the meeting, I figured out that that's probably eas=
ier and
    >     >     > no
    >     >     > need to
    >     >     > determine if it is an IPv4-only host.
    >     >     >=20
    >     >     > We can just create the EAMT entry for any A request if th=
ere is
    >     >     > a
    >     >     > corresponding AAAA which doesn't contain the WKP or NSP. =
This
    >     >     > means
    >     >     > that
    >     >     > the end-host (CDN) is dual-stacked.
    >     >     >=20
    >     >     > Then any host using the A record will automatically get t=
he
    >     >     > NAT46
    >     >     > translated to the "real" AAAA, not the one with the WKP o=
r NSP,
    >     >     > so we
    >     >     > fulfil the intended optimization not requiring knowing if=
 the
    >     >     > host is
    >     >     > IPv4-only.
    >     >     >=20
    >     >     > I think that's what you are meaning?
    >     >     >=20
    >     >     > The other think is how to select what AAAA to use if ther=
e are
    >     >     > several.
    >     >     >=20
    >     >     > I really think it will be interesting to get some co-auth=
ors, or
    >     >     > at
    >     >     > least
    >     >     > good inputs from CDN/caches operators on this.
    >     >     >=20
    >     >     > Regards,
    >     >     > Jordi
    >     >     >=20
    >     >     > =EF=BB=BFEl 28/3/19 15:35, "Dave Plonka" =
 escribi=C3=B3:
    >     >     >     Hi Jordi -
    >     >     >    =20
    >     >     >     Thanks for this draft presentation in v6ops.
    >     >     >    =20
    >     >     >     As we mentioned in the v6ops meeting, I don't think a=
 CPE
    >     >     >     (or any
    >     >     >     remote host) can reliably determine if a given IPv4 D=
NS
    >     >     >     client is
    >     >     >     an
    >     >     >     IPv4-only host.
    >     >     >    =20
    >     >     >     For one, this is because dual-stack hosts have at lea=
st two
    >     >     >     different
    >     >     >     IP addresses (v4 and v6), as you know, and there isn'=
t a
    >     >     >     simple
    >     >     >     way to
    >     >     >     remotely determine that a given IPv4 address and a gi=
ven
    >     >     >     IPv6
    >     >     >     address
    >     >     >     are actually bound to the same host's interface(s), o=
r even
    >     >     >     to
    >     >     >     enforce
    >     >     >     that a dual-stack host will query the same DNS recurs=
ive
    >     >     >     service
    >     >     >     when
    >     >     >     using two (or more) different client (IPv4 and IPv6)
    >     >     >     addresses.
    >     >     >    =20
    >     >     >     However, for your draft, couldn't we just eliminate a=
ny
    >     >     >     attempt to
    >     >     >     determine if any hosts are v4-only or not, and always
    >     >     >     synthesize
    >     >     >     the
    >     >     >     IPv4 DNS answers?
    >     >     >    =20
    >     >     >     I'm not saying I'm in favor of the mechanism overall,=
 just
    >     >     >     saying
    >     >     >     we
    >     >     >     could avoid the unnecessary and error-prone step of t=
rying
    >     >     >     to
    >     >     >     determine if a host is v4 only.
    >     >     >    =20
    >     >     >     Does that make sense?
    >     >     >    =20
    >     >     >     Thanks,
    >     >     >     Dave
    >     >     >    =20
    >     >     >    =20
    >     >     >     On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
    >     >     >    =20
    >     >     >      wrote=
:
    >     >     >     > Hi all,
    >     >     >     >=20
    >     >     >     > We have published a new version of this document, t=
aking
    >     >     >     > in
    >     >     >     > consideration a few inputs, clarified some examples=
, nits,
    >     >     >     > etc.
    >     >     >     >=20
    >     >     >     > https://datatracker.ietf.org/doc/draft-palet-v6ops-=
464xlat
    >     >     >     > -opt-c
    >     >     >     > dn-cac
    >     >     >     > hes/?include_text=3D1
    >     >     >     >=20
    >     >     >     > Regards,
    >     >     >     > Jordi
    >     >     >     >=20
    >     >     >     > =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.or=
g"      >    =20
    >     >     drafts@ietf.org> escribi=C3=B3:
    >     >     >     >     A new version of I-D,
    >     >     >     >     draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
    >     >     >     >     has been successfully submitted by Jordi Palet
    >     >     >     >     Martinez and
    >     >     >     >     posted
    >     >     >     >     to the
    >     >     >     >     IETF repository.
    >     >     >     >    =20
    >     >     >     >     Name:             =20
    >     >     >     >     draft-palet-v6ops-464xlat-opt-cdn-caches
    >     >     >     >     Revision:   01
    >     >     >     >     Title:              464XLAT Optimization for
    >     >     >     >     CDNs/Caches
    >     >     >     >     Document date:      2019-03-25
    >     >     >     >     Group:              Individual Submission
    >     >     >     >     Pages:              10
    >     >     >     >     URL:
    >     >     >     >     https://www.ietf.org/internet-drafts/draft-pale=
t-v6ops
    >     >     >     >     -464xl
    >     >     >     >     at-op
    >     >     >     >     t-cdn-caches-01.txt Status:
    >     >     >     >     https://datatracker.ietf.org/doc/draft-palet-v6=
ops-464
    >     >     >     >     xlat-o
    >     >     >     >     pt-cd
    >     >     >     >     n-caches/ Htmlized:
    >     >     >     >     https://tools.ietf.org/html/draft-palet-v6ops-4=
64xlat->     >     >     >     opt-cd
    >     >     >     >     n-cac
    >     >     >     >     hes-01 Htmlized:
    >     >     >     >     https://datatracker.ietf.org/doc/html/draft-pal=
et-v6op
    >     >     >     >     s-464x
    >     >     >     >     lat-o
    >     >     >     >     pt-cdn-caches Diff:
    >     >     >     >     https://www.ietf.org/rfcdiff?url2=3Ddraft-palet=
-v6ops-46
    >     >     >     >     4xlat->     >     >     opt-c dn-caches-01    >
    >     >     >     >    =20
    >     >     >     >     Abstract:
    >     >     >     >        This document describes the drawbacks of IP/=
ICMP
    >     >     >     >        Translation
    >     >     >     >        Algorithm (SIIT), when used as a NAT46, and
    >     >     >     >        IPv4-only
    >     >     >     >        devices
    >     >     >     >        or
    >     >     >     >        applications initiate traffic flows to dual-=
stack
    >     >     >     >        CDNs
    >     >     >     >        (Content
    >     >     >     >        Delivery Networks) or Caches, which are forc=
ed to
    >     >     >     >        be
    >     >     >     >        translated
    >     >     >     >        back
    >     >     >     >        to IPv4 by a NAT64.  The document proposes p=
ossible
    >     >     >     >        solutions
    >     >     >     >        to
    >     >     >     >        avoid that.
    >     >     >     >    =20
    >     >     >     >     Please note that it may take a couple of minute=
s from
    >     >     >     >     the
    >     >     >     >     time of
    >     >     >     >     submission until the htmlized version and diff =
are
    >     >     >     >     available
    >     >     >     >     at
    >     >     >     >     tools.ietf.org.
    >     >     >     >    =20
    >     >     >     >     The IETF Secretariat
    >     >     >     >=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 a=
ttached
    >     >     >     > files, is
    >     >     >     > strictly prohibited and will be considered a crimin=
al
    >     >     >     > offense.
    >     >     >     > If you
    >     >     >     > are not the intended recipient be aware that any
    >     >     >     > disclosure,
    >     >     >     > copying,
    >     >     >     > distribution or use of the contents of this informa=
tion,
    >     >     >     > 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 delet=
e it.
    >     >     >     >=20
    >     >     >     >=20
    >     >     >     >=20
    >     >     >     > _______________________________________________
    >     >     >     > v6ops mailing list
    >     >     >     > v6ops@ietf.org
    >     >     >     > https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >    =20
    >     >     >     --
    >     >     >    =20
    >     >     >     dave@plonka.us  http://www.cs.wisc.edu/~plonka/
    >     >     >=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 partiall=
y,
    >     >     > including
    >     >     > attached files, is strictly prohibited, will be considere=
d a
    >     >     > criminal
    >     >     > offense, so you must reply to the original sender to info=
rm
    >     >     > 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
    >     >=20
    >     > This electronic message contains information which may be privi=
leged
    >     > or
    >     > confidential. The information is intended to be for the exclusi=
ve use
    >     > of
    >     > the individual(s) named above and further non-explicilty author=
ized
    >     > disclosure, copying, distribution or use of the contents of thi=
s
    >     > information, even if partially, including attached files, is st=
rictly
    >     > prohibited and will be considered a criminal offense. If you ar=
e not
    >     > the
    >     > intended recipient be aware that any disclosure, copying, distr=
ibution
    >     > or
    >     > use of the contents of this information, even if partially, inc=
luding
    >     > attached files, is strictly prohibited, will be considered a cr=
iminal
    >     > offense, so you must reply to the original sender to inform abo=
ut 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
    >=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, distributio=
n 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 thi=
s
    > 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 Fri Mar 29 02:09: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 B1468120257 for ; Fri, 29 Mar 2019 02:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MVIdCQLT17N6 for ; Fri, 29 Mar 2019 02:08:55 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1FC120261 for ; Fri, 29 Mar 2019 02:08:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553850533; x=1554455333; 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=nn4onDSYb1XNS7tG5jhI6 buYgyWHa+Fofb03gUbDEAQ=; b=sriNR3tMxugHvMfJvo/xP02LuueOLgEEcJMoG bUGrmFeHmg+fffz2+x8Rskt5qwPmg0BGwv4vJ/Ldy/ApE4WUHaBagMLIkpaEqT7b kBKjG/Au5PKr0bRVmxtobDHhFnGzgDm/jOKFwi+qGY8+cHBZAchV6vJN2YIo4vgH ymbFiQ=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 29 Mar 2019 10:08:53 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 29 Mar 2019 10:08:53 +0100
Received: from [31.133.151.187] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006202477.msg for ; Fri, 29 Mar 2019 10:08:52 +0100
X-MDRemoteIP: 2001:67c:1232:144:c8a9:c9d5:6eed:e60
X-MDHelo: [31.133.151.187]
X-MDArrival-Date: Fri, 29 Mar 2019 10:08:52 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=199112b751=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Fri, 29 Mar 2019 10:08:49 +0100
From: JORDI PALET MARTINEZ 
To: IPv6 Operations 
Message-ID: <1A61CA23-6BFF-46E5-9603-9E9FA06FB87B@consulintel.es>
Thread-Topic: multiple A and/or AAAA in CDNs - draft-palet-v6ops-464xlat-opt-cdn-caches
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: [v6ops] multiple A and/or AAAA in CDNs - draft-palet-v6ops-464xlat-opt-cdn-caches
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 09:09:00 -0000

Question for CDN folks.

When you provide multiple A or AAAA records, from the view of a "given" ISP, all them work the same from the perspective of the host?

Otherwise, I don't see how, if a host uses a different DNS resolver (i.e., 1.1.1.1, 8.8.8.8, etc., from the ISP one) you avoid breaking "something".

If there is no "difference" in what A or AAAA is used, then we don't need to consider which one to pick for the EAMT entry (same chances than when the host is doing the choice).

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 Fri Mar 29 02:22:39 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008CF12023E for ; Fri, 29 Mar 2019 02:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUItn1x5ihrL for ; Fri, 29 Mar 2019 02:22:35 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3446A12024C for ; Fri, 29 Mar 2019 02:22:35 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id y13so1683752wrd.3 for ; Fri, 29 Mar 2019 02:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Ybd9JXS93ocY70YuUSaXLpS06WpjbSVah4u0bqxuaJI=; b=LgcadMCk8l2SnQOIcMLjwcPdy9gI99kBmNkDd2e6AX9YWLQByvKEIYD4C2yg79OiNm y00ux0XHlursGu73G/3tz51/suh0N/TcDT7d6yhAwZ32wklld4JZ+6fvKyGXFScAxdZf +uGGdbZ7K27fsAgv7OYh3LIC3LQJ9R6ZR0JmMudJn/dyibZFMtc4WbabA/6i/Xn4xRzg yYZZhzExcDPK6vuwgQDBXGu0edU2QPrVPYnMSJVFaGtk3SYCd9QcESadR7/WMSiR/stg gl6/DTWqV5wlXX9U9298I8eGstzXALhC8LZzm1opsHIuDvIy6x/BvOGBliut8hccDbpC hQaQ==
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=Ybd9JXS93ocY70YuUSaXLpS06WpjbSVah4u0bqxuaJI=; b=HaDICWurlzKeG9rt98kAO6OwAOAlX7DEbof3uxlOM/6P3TqdGQUj78jQPr5Ianiy1X w+mQ6tj8BEmdm+UPOfK1jg+itgvFPQM9gP5ox/rVa7xQE0Mf5Rvqqy1eZO4PuiwJb20L X3GJOqUFjFRuh1UHUYmzNyB7dXW5fumb81XKZYHr9SbuV6RhPrgTzhTb6VPJbQNjesxB azBfNRy4C8KtdgpJZtYNoe/kFAAPn38hBKg4uGwzhPrtOBo15KOKurbgWs1iyNVWdsUq C3egp8PUlc79gZpD62huufUVWdNywpL+y7RQC5zi9Ncq30OLfTvn+pN9+iVv9RYyinWW MWCw==
X-Gm-Message-State: APjAAAXzwapONgRUdQLWGUdzxp+4tGWTEnMIlsFLCwdnvpKefhhc967I 9g8gSJTlNsP7F6857V6z2w4=
X-Google-Smtp-Source: APXvYqxJigMyWhbJxLpDiCiayeExOcyOoG4cfxySK7lnc3WwImjnt2s9Gun4nZ6KbbQzN7L0RfodrQ==
X-Received: by 2002:adf:ec0a:: with SMTP id x10mr13784226wrn.193.1553851353720;  Fri, 29 Mar 2019 02:22:33 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:3427:feaa:c66d:4a69? ([2001:67c:1232:144:3427:feaa:c66d:4a69]) by smtp.gmail.com with ESMTPSA id t14sm1540057wmi.16.2019.03.29.02.22.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 02:22:32 -0700 (PDT)
From: Fred Baker 
Message-Id: <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C89F5BE8-30D9-423A-A1E8-4353C90E29BA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Fri, 29 Mar 2019 10:22:30 +0100
In-Reply-To: <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com>
Cc: IPv6 Operations 
To: "Rajiv Asati (rajiva)" 
References:  <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 09:22:38 -0000

--Apple-Mail=_C89F5BE8-30D9-423A-A1E8-4353C90E29BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



On Mar 29, 2019, at 7:09 AM, Rajiv Asati (rajiva)  =
wrote:
>=20
> Why is NUD not sufficient to address the problem (WAN neighbor =
unreachable)?
>=20
> I hope that the HGW devices are compliant with RFC4861 / 7048.

Well, that seems like a reasonable hope. I think that Mikael is saying =
that in IPOE environments they might not be compliant, or compliant =
implementations still have a problem. I think the key point here is to =
uncover what the issue might be in the context he is discussing, as =
opposed to simply dismissing it.

> Cheers,
> Rajiv
>=20
>> On Mar 29, 2019, at 6:44 AM, Fred Baker  =
wrote:
>>=20
>> =
https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastr=
eam/, slide 9
>>=20
>> What do we want to say on this issue? Mikael mentions =
draft-patterson-intarea-ipoe-health as possibly relevant, but I also get =
the idea that there is more to say; in this case, I think I need to send =
a note to the relevant authors and chairs asking them what the prognosis =
is and expressing operational interest. First, is there a consensus to =
do that? Second, do we have additional comments to pass along? Our =
comments might be adequately summarized by forwarding a link to this =
thread, or might rise to the level that needs to be discussed in an =
internet draft in v6ops. Comments?
>> =
--------------------------------------------------------------------------=
------
>> Victorious warriors win first and then go to war,
>> Defeated warriors go to war first and then seek to win.
>>    Sun Tzu
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops

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


--Apple-Mail=_C89F5BE8-30D9-423A-A1E8-4353C90E29BA
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+AFAlyd49YACgkQEhdRnd2G
P+AAjA//cRCo6VcypcxmsZlMXhmHwBvY+fBqL5GZqX7y45czMi9/W/5TKXs8c6Vy
OizY9e/+r1RN1JzDJvhhQJvQIRKUapgVMq8QLaLhhU83G1MTbQ2um0SbzGbLVoyf
tiKyFeopstiEystC3gCw9fg7W6GgNvoPwO56BVNaoFgpTx0tFMcu9DCoygfrCETp
H1TSvxWE5SBiLyFcXZ9w8va84vhx87AhGd6sWlC/yh9aLRLxtVCIq542GolEjtWQ
d4XuzDSRxdTyN9BvP0A9AeDigQOIanm3g8hioDbLOQfIP5p3sxKJKzpuJG0pf+ME
3sr43lBfo4oWrgw17C6ANEWAB5K7fA95MVHxU6mzO4YJvCvkcVKlBJVspF5mDeEq
1vN6SosDNB0hPck4PncrvmHrLR2QGNDGFJVSKo1rt/bgZsiopaKKOOVqsu7YdGrD
5o6W9cGmoqNrJzTo3wt9hsUfBQFZzdlOa3ixokaGsuEgRY4f56OUTUvKbO/2MpLt
CGDhbXi60uKP4eK04ueL752iwNFVsABLAJS6SenIO7NFpA4qJNtRGxXf/Qhz0T2y
a1v1UXzOyqjxaYwKskz1/6e29Co4E7P1iCIUWxd8Wv7pNhSSWNjJRkAU9nd4u8tE
mEKlyTxJXd2akSIEjcdPFzM+hPjKC2rGc53jEdiIGS4TlDVea4c=
=Xhkv
-----END PGP SIGNATURE-----

--Apple-Mail=_C89F5BE8-30D9-423A-A1E8-4353C90E29BA--


From nobody Fri Mar 29 02:41: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 5F26D12012B for ; Fri, 29 Mar 2019 02:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6i7UsyPAjOdm for ; Fri, 29 Mar 2019 02:41:53 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08886120074 for ; Fri, 29 Mar 2019 02:41:52 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5C64041B56 for ; Fri, 29 Mar 2019 10:41:49 +0100 (CET)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 4865C41202; Fri, 29 Mar 2019 10:41:49 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 3947FB68B5; Fri, 29 Mar 2019 10:41:49 +0100 (CET)
Date: Fri, 29 Mar 2019 10:41:49 +0100
From: Gert Doering 
To: Fred Baker 
Cc: "Rajiv Asati (rajiva)" , IPv6 Operations 
Message-ID: <20190329094149.GE97529@Space.Net>
References:  <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com> <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L+JAIaOTEjrbla/0"
Content-Disposition: inline
In-Reply-To: <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.11.2 (2019-01-07)
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 09:41:56 -0000

--L+JAIaOTEjrbla/0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Mar 29, 2019 at 10:22:30AM +0100, Fred Baker wrote:
> On Mar 29, 2019, at 7:09 AM, Rajiv Asati (rajiva)  wrot=
e:
> >=20
> > Why is NUD not sufficient to address the problem (WAN neighbor unreacha=
ble)?
> >=20
> > I hope that the HGW devices are compliant with RFC4861 / 7048.
>=20
> Well, that seems like a reasonable hope. I think that Mikael is
> saying that in IPOE environments they might not be compliant, or
> compliant implementations still have a problem. I think the key
> point here is to uncover what the issue might be in the context he
> is discussing, as opposed to simply dismissing it.

"Time to failure detection" might be an argument as well.

What are the NUD timers in use in typical implementations?

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Em=
mer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

--L+JAIaOTEjrbla/0
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlyd6FoACgkQ31bAZeTO
f8VN+RAAoMYu2VJEVq0IBLcEcOuHYw+zTJ5NPxw9kkewTtuT5QHm7T9oxO8XRGbn
o223Rv1Bm8k4xSjmGwrlV2X9HRQaECN2fVQoL0pwwMESA0Hl0rqsmxfLFQ0xqXpp
27gW7ZB+yeSjmIkMXb5+Ons0UceGho1I/bbjjuO1NZAnm6J9zU+UvwkKIdM/oKZS
hULQc6g6FSlV65lKmJcMtKEZkawq6mDnT60d1BckSMiaRiJKE59+Z4sKYM9eG4wH
tl6kZSaGBxzBDFc+jTf+9i8uzugkB6a2aHvPwKHkhmzw75rIRiRCWlWmkzAVavAw
tdW7ClKhOid8duJ6/5LJB4Bb1c/iR4AgLP/9DCK6+eXVQEG+vZPB8of949Uf2ydb
Hv7IjIUSBwf6q9YCFzRkWw7VdfuFtzBjkJ38jyK2jStst1gO9YP17XlQj+vzA55S
9xcEg7tsE84nSxopFh9YkS3xpUhvr/oz4XrvuKlxgSaubAWx2VLn2CMUdB6jHikl
91U6iDhICCJ4fDeEG4mxXKTd+r92+uCsDU/nxKTm9C0JzJ88hB6fFBBDotB2zsQm
TDmBE+JxApHpv/54GJ8Fdrp7GBFUrFqwq3Q50s7iC4a5nBIQazxbUUsQ5dyzgXvC
PnJZ4767eXMZ8/OOnG9GheaOzHFgtUkgVmeYa026MF5Cx+Zt3RM=
=r/Ah
-----END PGP SIGNATURE-----

--L+JAIaOTEjrbla/0--


From nobody Fri Mar 29 02:55:46 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21184120242 for ; Fri, 29 Mar 2019 02:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFVuIcBaam-z for ; Fri, 29 Mar 2019 02:55:41 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6777E120074 for ; Fri, 29 Mar 2019 02:55:41 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 41452AF; Fri, 29 Mar 2019 10:55:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1553853338; bh=8omrSPve+PeZ+0iOhvvDQFwaFwYpgeWtwnhD/D3yUE4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=NIIOLsTtiuVq41cvqFYsiT90OtYplBVr0nDyz0luqtr+TkRqLgODTbbfXBBmbYha5 mtQBk7gLeU5JjNPwswuWOigO2S2Im3Bn3wqddan2d61V0drtK/IWwbax+/OGhHFf6U u7IhdlhaV1jmqf43sxiajWQ15RZt5ijo4WT9msgI=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3F5829F; Fri, 29 Mar 2019 10:55:38 +0100 (CET)
Date: Fri, 29 Mar 2019 10:55:38 +0100 (CET)
From: Mikael Abrahamsson 
To: Fred Baker 
cc: "Rajiv Asati (rajiva)" ,  IPv6 Operations 
In-Reply-To: <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com>
Message-ID: 
References:  <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com> <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 09:55:44 -0000

On Fri, 29 Mar 2019, Fred Baker wrote:

> Well, that seems like a reasonable hope. I think that Mikael is saying 
> that in IPOE environments they might not be compliant, or compliant 
> implementations still have a problem. I think the key point here is to 
> uncover what the issue might be in the context he is discussing, as 
> opposed to simply dismissing it.

RFC7084 doesn't say (afaik) to stop announcing yourself as a default 
router on LAN when your default GW LL next-hop becomes unreachable, and 
then start doing RS, throw away your DHCPv6 prefix etc, and start to go 
back into whatever you do in an WAN interface down/up situation.

This is what is unspecified. We know pretty well what to do in an WAN 
interface down/up event, but not "softer" errors such as when the RA 
sending LL next-hop goes into ND unreachable state.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Fri Mar 29 03:30: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 58E3D1202ED for ; Fri, 29 Mar 2019 03:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Jq3S6IjR2itz for ; Fri, 29 Mar 2019 03:30:43 -0700 (PDT)
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 5E691120328 for ; Fri, 29 Mar 2019 03:30:41 -0700 (PDT)
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 m1h9omU-0000JtC; Fri, 29 Mar 2019 11:30:38 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References:  <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com> <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com>  
In-reply-to: Your message of "Fri, 29 Mar 2019 10:55:38 +0100 (CET) ."  
Date: Fri, 29 Mar 2019 11:30:37 +0100
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 10:30:48 -0000

>RFC7084 doesn't say (afaik) to stop announcing yourself as a default 
>router on LAN when your default GW LL next-hop becomes unreachable, and 
>then start doing RS, throw away your DHCPv6 prefix etc, and start to go 
>back into whatever you do in an WAN interface down/up situation.
>
>This is what is unspecified. We know pretty well what to do in an WAN 
>interface down/up event, but not "softer" errors such as when the RA 
>sending LL next-hop goes into ND unreachable state.

(terminology: I consider everything that gets a next hop router from RAs
to be a host)

I wonder if we should create an RFC that says that if a host marks a 
default router as unreachable in ND, it should cause a (simulated) link
down/up event.

In a virtual machine that is bridged through the host, you also lose link
events. So this may solve a larger class of problems.


From nobody Fri Mar 29 03:36: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 4B43D120542 for ; Fri, 29 Mar 2019 03:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2057h6UjYb1w for ; Fri, 29 Mar 2019 03:35:53 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E1712047A for ; Fri, 29 Mar 2019 03:35:53 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 158D7AF; Fri, 29 Mar 2019 11:35:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1553855752; bh=REinLt7z/K1hX5+3cvnN1KpCV0RF43DnSSxdBMi3faY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DiXw6zGQHXXG337a6W/GkPdJuiEgvZg3+EIWOo6ApnCidZY9/tiSCaSqv8FTe17/v NEnhKEqhEYvVUPFGBAocbTl6ks5SKD2Ed6pJQBGYrQ2a+w+0dggR2BdDyLgYSvYA5q Y8LBz6yn6bSmXVESeucVFTzWg5K2FhZEhTOB4s4w=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1255F9F; Fri, 29 Mar 2019 11:35:52 +0100 (CET)
Date: Fri, 29 Mar 2019 11:35:52 +0100 (CET)
From: Mikael Abrahamsson 
To: Philip Homburg 
cc: v6ops@ietf.org
In-Reply-To: 
Message-ID: 
References:  <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com> <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com>  
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 10:36:05 -0000

On Fri, 29 Mar 2019, Philip Homburg wrote:

> (terminology: I consider everything that gets a next hop router from RAs 
> to be a host)

Most things today are both routers and hosts at the same time. I find 
keeping the hard disctinction between these concepts to be not useful 
anymore.

> I wonder if we should create an RFC that says that if a host marks a 
> default router as unreachable in ND, it should cause a (simulated) link 
> down/up event.

If you mean soft "discard all information received from that specific 
router and start over" then we're in agreement. There might be other 
things on the link so simulating a down/up event might be too much.

> In a virtual machine that is bridged through the host, you also lose link
> events. So this may solve a larger class of problems.

Absolutely, that was my idea all the time.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Fri Mar 29 03:52:11 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DECB120165 for ; Fri, 29 Mar 2019 03:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 K6RgmLZreKfW for ; Fri, 29 Mar 2019 03:52:05 -0700 (PDT)
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 199DC1200A4 for ; Fri, 29 Mar 2019 03:52:05 -0700 (PDT)
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 m1h9p7D-0000GmC; Fri, 29 Mar 2019 11:52:03 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References:  <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com> <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com>    
In-reply-to: Your message of "Fri, 29 Mar 2019 11:35:52 +0100 (CET) ."  
Date: Fri, 29 Mar 2019 11:52:02 +0100
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 10:52:09 -0000

In your letter dated Fri, 29 Mar 2019 11:35:52 +0100 (CET) you wrote:
>On Fri, 29 Mar 2019, Philip Homburg wrote:
>
>> (terminology: I consider everything that gets a next hop router from RAs 
>> to be a host)
>
>Most things today are both routers and hosts at the same time. I find 
>keeping the hard disctinction between these concepts to be not useful 
>anymore.

Core IPv6 RFCs distinguish between node, host and router behavior. It is
worth keeping in mind that an interface that gets default routers from
RAs is a host interface in the terminology of ND.

>> I wonder if we should create an RFC that says that if a host marks a 
>> default router as unreachable in ND, it should cause a (simulated) link 
>> down/up event.
>
>If you mean soft "discard all information received from that specific 
>router and start over" then we're in agreement. There might be other 
>things on the link so simulating a down/up event might be too much.

There is for example RFC-6059 (Simple Procedures for Detecting Network
Attachment in IPv6)

It is worth considering if in the context of the IPv6, simulating a 
link down/up event is possible, or if that would break things.

In some contexts, it may even be beneficial to bring the physical link
down and up because of badly behaving L2 boxes in the network.


From nobody Fri Mar 29 04:46:12 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7A31203CE; Fri, 29 Mar 2019 04:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ejrIWVjUXQiO; Fri, 29 Mar 2019 04:45:42 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DDB12028B; Fri, 29 Mar 2019 04:45:42 -0700 (PDT)
Received: from [IPv6:2a02:8308:40:3000:b044:9b9a:327d:b750] (unknown [IPv6:2a02:8308:40:3000:b044:9b9a:327d:b750]) (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 AC39683975; Fri, 29 Mar 2019 12:45:38 +0100 (CET)
To: =?UTF-8?Q?Martin_Hun=c4=9bk?= , ipv6@ietf.org, V6 Ops List 
References:  <4572212.CHxXTUUyl0@asclepius>
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: <351805de-6e08-c981-367c-44915df0b8b8@si6networks.com>
Date: Fri, 29 Mar 2019 12:05:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <4572212.CHxXTUUyl0@asclepius>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] Thoughts on draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 11:45:56 -0000

On 28/3/19 21:20, Martin Huněk wrote:
> Hi,
> 
> please see reply inline for mentioned issues.
> Dne čtvrtek 28. března 2019 11:30:39 CET, Jen Linkova napsal(a): 
>> #1: High priority/must have: ensure that the host selects an address
>> from the "working" prefix for new sessions.
> 
> Wouldn't be just better to add a rule to RFC6724 which would say the longer 
> Preferred lifetime wins? Let say between rule #7 and #8?

No. In a multi-prefix network, for example, different routers might be
employing different preferred values for the different prefixes.

The semantics of the "preferred lifetime" is the amount of time for
which an address may be preferred, rather than an intrinsic measure of
"how preferred" such addresses should be.



>> #2: Med/High priority, nice to have: preserving existing connections
>> or at least explicitly quickly terminate them instead of letting them
>> timing out.
> 
> Question is if unknown prefix to the router should be treated according to BCP 
> 38 - dropped or if it should be treated as special case (for let say home 
> router) and should get rejected. And if so, what should be the code.

Either way, icmp error messages signal soft (transient) error conditions.




>> #3: Med/Low priority: ensuing that if the old prefix is reassigned to
>> another part of the network, the host can communicate to new owners of
>> the prefix
> 
> As valid lifetime should not be longer than PD lease time, then it should not 
> be a problem. As it should not be leased to another holder before the first 
> lease expires.

There are folks that employ PD lifetimes in the order of months.... SO
capping the PIO lifetimes to the PD lifetimes is not a guarantee that
you are going to get "shorter" lifetimes....




>> #4: Preventing the host from exceeding the number of allowed/supported
>> # of addresses on the interface.
> 
> I don't think that we would be able to do that. What I know such limitations 
> were placed there (at least in Linux) as reaction to RA flood attacks. By 
> rising that limitations, OS would became more vulnerable to those.

If we hit a limit of, say, 16 addresses because 15 of them are stale,
we're clearly doing a bad job at "garbage collection".



> Just a few thoughts:
> Do we really need to change the constant of default Pref./valid lifetime by 
> another constant? Would it fit all?
> 
> Wouldn't be better to specify CPE behavior towards the prefixes received by 
> DHCPv6-PD? Like valid lifetime should not exceed in any single moment 1/2 of 
> original lease time and preferred lifetime should not exceed 1/4 and either 
> should be valid longer then the lease itself (we have that already). Those 
> fractions are just example.

That *might* work. However, I'm of the idea that it is better to use
shorter lifetimes and refresh them (i.e., even if the CPE router gets a
lease of, say, 10 days, it should advertise PIOs of, say, 30 minutes,
and refresh such lifetimes as gratuitous RAs are sent on the LAN side),
rather than advertising PIOs which long lifetimes that then, if things
break, ensure brokeness for a long time.




> From ISP point of view, I'm quite happy to lease the clients prefix for 
> several days (probably not for the whole month), 

If you give clients stable prefixes, than the lease time does not really
matter.



> as I give client stable 
> prefixes, it is not problem for me. In this case having valid lifetime to be a 
> fraction of lease time would at least protect clients devices from 
> deconfiguration of valid prefix by the RA flood (at least for 2 hours). Even 
> that it doesn't save them the internet connection, at least they would be able 
> to receive packets.

If you are referring to ND/SLAAC attacks, then the idea is quite simple:
either you filter RAs, or you don't. If you do, you don't need to play
with timers to protect from such attacks. If you don't, then there are
so many possible attack vectors that simply using timers to mitigate one
specific vector will not have any practical impact.


> Maybe it has been already discussed here, in that case I apologies. But 30/10 
> minutes seems too strict and uncalled for.

Could you please elaborate?

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 Fri Mar 29 05:04: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 052AE12026F for ; Fri, 29 Mar 2019 05:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=J8Vn+m7x; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=N2embFx7
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUw56imrLpZw for ; Fri, 29 Mar 2019 05:04:22 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0277212024B for ; Fri, 29 Mar 2019 05:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20499; q=dns/txt; s=iport; t=1553861062; x=1555070662; h=from:to:cc:subject:date:message-id:mime-version; bh=GN3a3FH/7S1bQ+RvBQDBduX5tjSPvsjpBxejinQDRos=; b=J8Vn+m7xgPUw+v29iy2OZpJesSwHhClkvySIpRAAz6z9gN9uPSV0XZcB LyE9PNcuSuTRINRCKLWtsguAuazH59w1H9i3Y6fAX9Iat6U+5hJs+fSf/ KsYcTHNMNwTThiAkEdjTj/QkEnsV6w38HsTLYIEmANJZL0Xe0QEaGMTpT U=;
IronPort-PHdr: =?us-ascii?q?9a23=3Az+1QNR3QgE38trvvsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGOt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE0T5LeDjRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADBCJ5c/4wNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwEBgQ0vKScDaHQECyeEDoNHA4RSil+CMiWJOIk?= =?us-ascii?q?NhEmBLhSBEANUDQEBIwmEQAIXhSAiNAkNAQEDAQEJAQMCbRwMQgEOAYR4AQY?= =?us-ascii?q?jChMBATcBEQEIDgMDAQIoAwIEHxEUCQoEAQ0FgldLAYERTAMVAQIMnhUCihR?= =?us-ascii?q?xgS+CeAEBBYJHgj8NC4IMAwWBLwGLMReBQD+BEScME4JMPoIaRwEBAgGBKwE?= =?us-ascii?q?SAT8NCYJUMYImikOCOYQih0qMEDYJAodqiByDPxqUDIsshgmBPIt1AgQCBAU?= =?us-ascii?q?CDgEBBYFNOGVxcBVlAYJBggqBIwECgkiFFIU/cgEBgSaGdoUZgj4BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,284,1549929600";  d="scan'208,217";a="251576459"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 12:04:20 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x2TC4Kqp029971 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 12:04:20 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 07:04:20 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 07:04:19 -0500
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 29 Mar 2019 08:04:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GN3a3FH/7S1bQ+RvBQDBduX5tjSPvsjpBxejinQDRos=; b=N2embFx7nM4sgvAdqNXXbElXFD7+VzhHxqms6kyO8IPuZit0gdDBCmzK70o/1nB24aJ0EH7ZCqpVdT/Tke0AxxXI4OKaN6XMpKtVhZ0ESm1KMir9JjJs1QtH00cQCRlaPFTnOgWr12C/4qQqds2/u0wBNgSrb9CikWkc95MV2Pw=
Received: from DM6PR11MB3068.namprd11.prod.outlook.com (20.177.218.153) by DM6PR11MB4138.namprd11.prod.outlook.com (20.176.126.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Fri, 29 Mar 2019 12:04:17 +0000
Received: from DM6PR11MB3068.namprd11.prod.outlook.com ([fe80::5d16:a8db:b524:e147]) by DM6PR11MB3068.namprd11.prod.outlook.com ([fe80::5d16:a8db:b524:e147%4]) with mapi id 15.20.1750.014; Fri, 29 Mar 2019 12:04:17 +0000
From: "Rajiv Asati (rajiva)" 
To: Mikael Abrahamsson , Fred Baker 
CC: IPv6 Operations 
Thread-Topic: [v6ops] Operational Headache: Upstream liveness 
Thread-Index: AQHU5ieILiW18HOEe0a89cqXo6Z4FA==
Date: Fri, 29 Mar 2019 12:04:17 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.17.0.190309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rajiva@cisco.com; 
x-originating-ip: [2001:420:c0cc:1003::9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be72dc2e-16a4-4f8a-07a8-08d6b43eab78
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR11MB4138; 
x-ms-traffictypediagnostic: DM6PR11MB4138:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(39860400002)(376002)(346002)(189003)(199004)(51914003)(51444003)(102836004)(8676002)(966005)(71190400001)(478600001)(71200400001)(86362001)(36756003)(97736004)(6486002)(5660300002)(25786009)(46003)(2906002)(256004)(7736002)(66574012)(4326008)(82746002)(14454004)(106356001)(99286004)(83716004)(58126008)(186003)(110136005)(606006)(8936002)(6512007)(236005)(6306002)(790700001)(6116002)(54896002)(68736007)(6506007)(4743002)(486006)(2616005)(476003)(6246003)(229853002)(316002)(105586002)(53936002)(81156014)(6436002)(33656002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4138; H:DM6PR11MB3068.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 0jlIqvGDiyLPU1/tYoB3QvN3I+zP3ZANCMPyfUU61R0qp352ceZELcPeflm0Hxeep+SiJ6motFiSEg40O3EZd3xavFV/6JF9KccGIwCY5ot2Cfjw8rTkWEmU+ba2NV85C+uvRPZhNG/SAqRbvX7S2f3+k2YdaRUdwSHMPqJCZuKziHrp+hvvydD08eS+/GLXgrJQMzVlkCCgzM6yYWyuFyLypMxfqTOHyE0t0FL60KMks3K3Fb+C67kTKJwz8akdiPViTzjllbSLeOoGkmgK5d2X3v/2VPCvoZ/AcPMFemdmLRt3pCQ9ZqvCgtPz2TgOENJKAHSAIXpL2QFt/85U8u5Drrghp8FxAQT5wgDgWTQoKRFsVDYawN2ABwGjvURU2/YNQNyeLxo1CxDS4QorhuAoWMiFycCrxjPTpzbcjTQ=
Content-Type: multipart/alternative; boundary="_000_AB95DF589620476689325E6D80038495ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: be72dc2e-16a4-4f8a-07a8-08d6b43eab78
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 12:04:17.5644 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4138
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 12:04:25 -0000

--_000_AB95DF589620476689325E6D80038495ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TWlrYWVsLA0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaXR5LiBMb29raW5nIGF0IFJGQzcwODQgMy4y
LjEgYW5kIDQuMSBzZWN0aW9ucywgdGhlIHNjZW5hcmlvIG9mIGEgcHJldmlvdXNseSBhZHZlcnRp
c2VkL3JlYWNoYWJsZSBkZWZhdWx0IHJvdXRlciBvbiBXQU4gbGluayBiZWNvbWluZyB1bnJlYWNo
YWJsZSwgaXMgbm90IGV4cGxpY2l0bHkgbWVudGlvbmVkLg0KDQoNCmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9yZmM3MDg0I3NlY3Rpb24tMy4yLjENCg0KICAgaG9zdCBpbXBsZW1lbnRhdGlv
bnMgdGhhdCBkbyBub3QgaGFuZGxlIG11bHRpaG9taW5nIGluIGEgbXVsdGktcHJlZml4DQogICBl
bnZpcm9ubWVudCBbTVVMVElIT01JTkctV0lUSE9VVC1OQVQ8aHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL3JmYzcwODQjcmVmLU1VTFRJSE9NSU5HLVdJVEhPVVQtTkFUPl0sIHRoZSBJUHY2IENF
IHJvdXRlciBzaG91bGQgbm90LA0KICAgYXMgZGV0YWlsZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBi
ZWxvdywgYWR2ZXJ0aXNlIGl0c2VsZiBhcyBhIGRlZmF1bHQNCiAgIHJvdXRlciBvbiB0aGUgTEFO
IGludGVyZmFjZShzKSB3aGVuIGl0IGRvZXMgbm90IGhhdmUgSVB2Ng0KICAgY29ubmVjdGl2aXR5
IG9uIHRoZSBXQU4gaW50ZXJmYWNlIG9yIHdoZW4gaXQgaXMgbm90IHByb3Zpc2lvbmVkIHdpdGgN
CiAgIElQdjYgYWRkcmVzc2VzLg0KDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3
MDg0I3NlY3Rpb24tNC4xDQoNCg0KICAgRy00OiAgQnkgZGVmYXVsdCwgYW4gSVB2NiBDRSByb3V0
ZXIgdGhhdCBoYXMgbm8gZGVmYXVsdCByb3V0ZXIocykgb24NCiAgICAgICAgIGl0cyBXQU4gaW50
ZXJmYWNlIE1VU1QgTk9UIGFkdmVydGlzZSBpdHNlbGYgYXMgYW4gSVB2NiBkZWZhdWx0DQogICAg
ICAgICByb3V0ZXIgb24gaXRzIExBTiBpbnRlcmZhY2VzLiAgVGhhdCBpcywgdGhlICJSb3V0ZXIg
TGlmZXRpbWUiDQogICAgICAgICBmaWVsZCBpcyBzZXQgdG8gemVybyBpbiBhbGwgUm91dGVyIEFk
dmVydGlzZW1lbnQgbWVzc2FnZXMgaXQNCiAgICAgICAgIG9yaWdpbmF0ZXMgW1JGQzQ4NjE8aHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ4NjE+XS4NCg0KICAgRy01OiAgQnkgZGVmYXVs
dCwgaWYgdGhlIElQdjYgQ0Ugcm91dGVyIGlzIGFuIGFkdmVydGlzaW5nIHJvdXRlciBhbmQNCiAg
ICAgICAgIGxvc2VzIGl0cyBJUHY2IGRlZmF1bHQgcm91dGVyKHMpIGFuZC9vciBkZXRlY3RzIGxv
c3Mgb2YNCiAgICAgICAgIGNvbm5lY3Rpdml0eSBvbiB0aGUgV0FOIGludGVyZmFjZSwgaXQgTVVT
VCBleHBsaWNpdGx5DQogICAgICAgICBpbnZhbGlkYXRlIGl0c2VsZiBhcyBhbiBJUHY2IGRlZmF1
bHQgcm91dGVyIG9uIGVhY2ggb2YgaXRzDQogICAgICAgICBhZHZlcnRpc2luZyBpbnRlcmZhY2Vz
IGJ5IGltbWVkaWF0ZWx5IHRyYW5zbWl0dGluZyBvbmUgb3IgbW9yZQ0KICAgICAgICAgUm91dGVy
IEFkdmVydGlzZW1lbnQgbWVzc2FnZXMgd2l0aCB0aGUgIlJvdXRlciBMaWZldGltZSIgZmllbGQN
CiAgICAgICAgIHNldCB0byB6ZXJvIFtSRkM0ODYxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9yZmM0ODYxPl0uDQoNCg0KDQotLQ0KQ2hlZXJzLA0KUmFqaXYNCg0KRnJvbTogTWlrYWVsIEFi
cmFoYW1zc29uIDxzd21pa2VAc3dtLnBwLnNlPg0KT3JnYW5pemF0aW9uOiBQZW9wbGUncyBGcm9u
dCBBZ2FpbnN0IFdXVw0KRGF0ZTogRnJpZGF5LCBNYXJjaCAyOSwgMjAxOSBhdCA1OjU2IEFNDQpU
bzogRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPg0KQ2M6IFJhaml2IEFzYXRp
IDxyYWppdmFAY2lzY28uY29tPiwgInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQpT
dWJqZWN0OiBSZTogW3Y2b3BzXSBPcGVyYXRpb25hbCBIZWFkYWNoZTogVXBzdHJlYW0gbGl2ZW5l
c3MNCg0KT24gRnJpLCAyOSBNYXIgMjAxOSwgRnJlZCBCYWtlciB3cm90ZToNCg0KV2VsbCwgdGhh
dCBzZWVtcyBsaWtlIGEgcmVhc29uYWJsZSBob3BlLiBJIHRoaW5rIHRoYXQgTWlrYWVsIGlzIHNh
eWluZw0KdGhhdCBpbiBJUE9FIGVudmlyb25tZW50cyB0aGV5IG1pZ2h0IG5vdCBiZSBjb21wbGlh
bnQsIG9yIGNvbXBsaWFudA0KaW1wbGVtZW50YXRpb25zIHN0aWxsIGhhdmUgYSBwcm9ibGVtLiBJ
IHRoaW5rIHRoZSBrZXkgcG9pbnQgaGVyZSBpcyB0bw0KdW5jb3ZlciB3aGF0IHRoZSBpc3N1ZSBt
aWdodCBiZSBpbiB0aGUgY29udGV4dCBoZSBpcyBkaXNjdXNzaW5nLCBhcw0Kb3Bwb3NlZCB0byBz
aW1wbHkgZGlzbWlzc2luZyBpdC4NCg0KUkZDNzA4NCBkb2Vzbid0IHNheSAoYWZhaWspIHRvIHN0
b3AgYW5ub3VuY2luZyB5b3Vyc2VsZiBhcyBhIGRlZmF1bHQNCnJvdXRlciBvbiBMQU4gd2hlbiB5
b3VyIGRlZmF1bHQgR1cgTEwgbmV4dC1ob3AgYmVjb21lcyB1bnJlYWNoYWJsZSwgYW5kDQp0aGVu
IHN0YXJ0IGRvaW5nIFJTLCB0aHJvdyBhd2F5IHlvdXIgREhDUHY2IHByZWZpeCBldGMsIGFuZCBz
dGFydCB0byBnbw0KYmFjayBpbnRvIHdoYXRldmVyIHlvdSBkbyBpbiBhbiBXQU4gaW50ZXJmYWNl
IGRvd24vdXAgc2l0dWF0aW9uLg0KDQpUaGlzIGlzIHdoYXQgaXMgdW5zcGVjaWZpZWQuIFdlIGtu
b3cgcHJldHR5IHdlbGwgd2hhdCB0byBkbyBpbiBhbiBXQU4NCmludGVyZmFjZSBkb3duL3VwIGV2
ZW50LCBidXQgbm90ICJzb2Z0ZXIiIGVycm9ycyBzdWNoIGFzIHdoZW4gdGhlIFJBDQpzZW5kaW5n
IExMIG5leHQtaG9wIGdvZXMgaW50byBORCB1bnJlYWNoYWJsZSBzdGF0ZS4NCg0KLS0NCk1pa2Fl
bCBBYnJhaGFtc3NvbiAgICBlbWFpbDogc3dtaWtlQHN3bS5wcC5zZTxtYWlsdG86c3dtaWtlQHN3
bS5wcC5zZT4NCg0K

--_000_AB95DF589620476689325E6D80038495ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk
aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0
eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pa2FlbCwgPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlRoYW5rcyBmb3IgdGhlIGNsYXJpdHkuIExvb2tpbmcgYXQgUkZDNzA4NCAzLjIuMSBhbmQgNC4x
IHNlY3Rpb25zLCB0aGUgc2NlbmFyaW8gb2YgYSBwcmV2aW91c2x5IGFkdmVydGlzZWQvcmVhY2hh
YmxlIGRlZmF1bHQgcm91dGVyIG9uIFdBTiBsaW5rIGJlY29taW5nIHVucmVhY2hhYmxlLCBpcyBu
b3QgZXhwbGljaXRseSBtZW50aW9uZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL3JmYzcwODQjc2VjdGlvbi0zLjIuMSI+aHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL3JmYzcwODQjc2VjdGlvbi0zLjIuMTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBob3N0IGltcGxlbWVudGF0aW9u
cyB0aGF0IGRvIG5vdCBoYW5kbGUgbXVsdGlob21pbmcgaW4gYSBtdWx0aS1wcmVmaXg8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj
ayI+Jm5ic3A7Jm5ic3A7IGVudmlyb25tZW50IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvcmZjNzA4NCNyZWYtTVVMVElIT01JTkctV0lUSE9VVC1OQVQiIHRpdGxlPSImcXVv
dDtJUHY2IE11bHRpaG9taW5nIHdpdGhvdXQgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9uJnF1
b3Q7Ij5NVUxUSUhPTUlORy1XSVRIT1VULU5BVDwvYT5dLA0KIHRoZSBJUHY2IENFIHJvdXRlciBz
aG91bGQgbm90LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYXMgZGV0YWlsZWQgaW4gdGhlIHJlcXVp
cmVtZW50cyBiZWxvdywgYWR2ZXJ0aXNlIGl0c2VsZiBhcyBhIGRlZmF1bHQ8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7IHJvdXRlciBvbiB0aGUgTEFOIGludGVyZmFjZShzKSB3aGVuIGl0IGRvZXMgbm90
IGhhdmUgSVB2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY29ubmVjdGl2aXR5IG9uIHRoZSBXQU4g
aW50ZXJmYWNlIG9yIHdoZW4gaXQgaXMgbm90IHByb3Zpc2lvbmVkIHdpdGg8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7IElQdjYgYWRkcmVzc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwODQjc2VjdGlvbi00LjEiPmh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDg0I3NlY3Rpb24tNC4xPC9hPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEctNDombmJzcDsgQnkgZGVmYXVsdCwgYW4g
SVB2NiBDRSByb3V0ZXIgdGhhdCBoYXMgbm8gZGVmYXVsdCByb3V0ZXIocykgb248bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0cyBXQU4g
aW50ZXJmYWNlIE1VU1QgTk9UIGFkdmVydGlzZSBpdHNlbGYgYXMgYW4gSVB2NiBkZWZhdWx0PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6
YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBy
b3V0ZXIgb24gaXRzIExBTiBpbnRlcmZhY2VzLiZuYnNwOyBUaGF0IGlzLCB0aGUgJnF1b3Q7Um91
dGVyIExpZmV0aW1lJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBmaWVsZCBpcyBzZXQgdG8gemVybyBpbiBhbGwgUm91dGVyIEFk
dmVydGlzZW1lbnQgbWVzc2FnZXMgaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yaWdpbmF0ZXMgWzxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM0ODYxIiB0aXRsZT0iJnF1b3Q7TmVpZ2hib3IgRGlzY292ZXJ5
IGZvciBJUCB2ZXJzaW9uIDYgKElQdjYpJnF1b3Q7Ij5SRkM0ODYxPC9hPl0uPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgRy01OiZuYnNwOyBCeSBkZWZhdWx0LCBpZiB0aGUg
SVB2NiBDRSByb3V0ZXIgaXMgYW4gYWR2ZXJ0aXNpbmcgcm91dGVyIGFuZDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbG9zZXMgaXRzIElQ
djYgZGVmYXVsdCByb3V0ZXIocykgYW5kL29yIGRldGVjdHMgbG9zcyBvZjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29ubmVjdGl2aXR5
IG9uIHRoZSBXQU4gaW50ZXJmYWNlLCBpdCBNVVNUIGV4cGxpY2l0bHk8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludmFsaWRhdGUgaXRz
ZWxmIGFzIGFuIElQdjYgZGVmYXVsdCByb3V0ZXIgb24gZWFjaCBvZiBpdHM8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkdmVydGlzaW5n
IGludGVyZmFjZXMgYnkgaW1tZWRpYXRlbHkgdHJhbnNtaXR0aW5nIG9uZSBvciBtb3JlPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb3V0
ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdlcyB3aXRoIHRoZSAmcXVvdDtSb3V0ZXIgTGlmZXRpbWUm
cXVvdDsgZmllbGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHNldCB0byB6ZXJvIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjNDg2MSIgdGl0bGU9IiZxdW90O05laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVy
c2lvbiA2IChJUHY2KSZxdW90OyI+UkZDNDg2MTwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs
YWNrIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Q2hlZXJz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5SYWppdiAmbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5NaWthZWwgQWJyYWhhbXNzb24g
Jmx0O3N3bWlrZUBzd20ucHAuc2UmZ3Q7PGJyPg0KPGI+T3JnYW5pemF0aW9uOiA8L2I+UGVvcGxl
J3MgRnJvbnQgQWdhaW5zdCBXV1c8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBNYXJjaCAyOSwg
MjAxOSBhdCA1OjU2IEFNPGJyPg0KPGI+VG86IDwvYj5GcmVkIEJha2VyICZsdDtmcmVkYmFrZXIu
aWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5SYWppdiBBc2F0aSAmbHQ7cmFqaXZh
QGNpc2NvLmNvbSZndDssICZxdW90O3Y2b3BzQGlldGYub3JnJnF1b3Q7ICZsdDt2Nm9wc0BpZXRm
Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFt2Nm9wc10gT3BlcmF0aW9uYWwgSGVh
ZGFjaGU6IFVwc3RyZWFtIGxpdmVuZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIEZyaSwgMjkgTWFyIDIwMTksIEZyZWQgQmFrZXIgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQu
NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1y
aWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2VsbCwgdGhh
dCBzZWVtcyBsaWtlIGEgcmVhc29uYWJsZSBob3BlLiBJIHRoaW5rIHRoYXQgTWlrYWVsIGlzIHNh
eWluZw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dGhhdCBpbiBJUE9FIGVudmlyb25tZW50cyB0aGV5
IG1pZ2h0IG5vdCBiZSBjb21wbGlhbnQsIG9yIGNvbXBsaWFudA0KPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+aW1wbGVtZW50YXRpb25zIHN0aWxsIGhhdmUgYSBwcm9ibGVtLiBJIHRoaW5rIHRoZSBrZXkg
cG9pbnQgaGVyZSBpcyB0bw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dW5jb3ZlciB3aGF0IHRoZSBp
c3N1ZSBtaWdodCBiZSBpbiB0aGUgY29udGV4dCBoZSBpcyBkaXNjdXNzaW5nLCBhcw0KPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+b3Bwb3NlZCB0byBzaW1wbHkgZGlzbWlzc2luZyBpdC48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SRkM3
MDg0IGRvZXNuJ3Qgc2F5IChhZmFpaykgdG8gc3RvcCBhbm5vdW5jaW5nIHlvdXJzZWxmIGFzIGEg
ZGVmYXVsdA0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+cm91dGVyIG9uIExBTiB3aGVuIHlvdXIgZGVm
YXVsdCBHVyBMTCBuZXh0LWhvcCBiZWNvbWVzIHVucmVhY2hhYmxlLCBhbmQNCjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPnRoZW4gc3RhcnQgZG9pbmcgUlMsIHRocm93IGF3YXkgeW91ciBESENQdjYgcHJl
Zml4IGV0YywgYW5kIHN0YXJ0IHRvIGdvDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5iYWNrIGludG8g
d2hhdGV2ZXIgeW91IGRvIGluIGFuIFdBTiBpbnRlcmZhY2UgZG93bi91cCBzaXR1YXRpb24uPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhpcyBpcyB3aGF0
IGlzIHVuc3BlY2lmaWVkLiBXZSBrbm93IHByZXR0eSB3ZWxsIHdoYXQgdG8gZG8gaW4gYW4gV0FO
DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj5pbnRlcmZhY2UgZG93bi91cCBldmVudCwgYnV0IG5vdCAm
cXVvdDtzb2Z0ZXImcXVvdDsgZXJyb3JzIHN1Y2ggYXMgd2hlbiB0aGUgUkENCjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPnNlbmRpbmcgTEwgbmV4dC1ob3AgZ29lcyBpbnRvIE5EIHVucmVhY2hhYmxlIHN0
YXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0tIDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPk1pa2FlbCBBYnJhaGFtc3NvbiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO2VtYWlsOiA8YSBocmVmPSJtYWlsdG86c3dtaWtlQHN3bS5wcC5zZSI+DQpzd21pa2VAc3dt
LnBwLnNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_AB95DF589620476689325E6D80038495ciscocom_--


From nobody Fri Mar 29 06:14: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 77E491202CE for ; Fri, 29 Mar 2019 06:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vp_yX55wFXXF for ; Fri, 29 Mar 2019 06:14:38 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838F5120252 for ; Fri, 29 Mar 2019 06:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553865275; x=1554470075; 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=yfeYKfmg kH17qjcpkF+eKb8sar5GJWRVhb4i0QkCGo4=; b=JnQ0yiaKtURg/4pZipmPxuTw Hvbv3TeDc4PZZOoKd1lWy6k2jijpm2tdGl/mmztY7fpkbTYAj1iniux9k3fYgBHr OU3Fow3jg6MzEh2rZgw49ortxCbOcu4ybBydyJ7toGn9oseek5Zpkq4riBVrxJ6t 6fH+Qt5gF1UVbrhaaBA=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 29 Mar 2019 14:14:35 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 29 Mar 2019 14:14:34 +0100
Received: from [10.17.42.251] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006202665.msg for ; Fri, 29 Mar 2019 14:14:34 +0100
X-MDRemoteIP: 10.8.10.6
X-MDHelo: [10.17.42.251]
X-MDArrival-Date: Fri, 29 Mar 2019 14:14:34 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=199112b751=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Fri, 29 Mar 2019 14:14:31 +0100
From: JORDI PALET MARTINEZ 
To: IPv6 Operations 
Message-ID: <272D053B-3274-4CDF-94BD-CECCBC33C496@consulintel.es>
Thread-Topic: [v6ops] Default DNS Server
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>     <0153779E-91C8-4D9F-9454-CE44E2E9A9A8@gmail.com>
In-Reply-To: <0153779E-91C8-4D9F-9454-CE44E2E9A9A8@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Default DNS Server
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 13:14:41 -0000

Hi Fred,

I fully agree. It breaks things, even it may happen that it means that some=
 networks avoid those devices working at all, because they have strict rule=
s about the use of their own DNS resolvers, etc. (not saying either this is=
 right).

I've described that as "manual configuration of foreign DNS" in https://dat=
atracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/.

In the case of NAT64 it simply means you break your connectivity for those =
devices/apps that are IPv4-only, which fortunately doesn't happen with 464X=
LAT, but you lose optimization (forcing the use of the CLAT), but at the sa=
me time it provides the advantage of ensuring that DNSSEC is not broken.

All that said, how we avoid that?

Do you think a BCP will solve it? Do app/device developers follow it?

Regards,
Jordi
=20
=20

=EF=BB=BFEl 29/3/19 6:57, "v6ops en nombre de Fred Baker"  escribi=C3=B3:

    On Mar 28, 2019, at 5:11 PM, JORDI PALET MARTINEZ  wrote:
    > 1) Mikael mention that Chromecast (and other devices), use a manually=
 configured DNS such as 8.8.8.8.
   =20
    This is a different comment than Jordi's topic, but I'm of the opinion =
that the use of services like 8.8.8.8 by default overrides what might be lo=
cal policy. I'd really like to see such things use 8.8.8.8 (or 1.1.1.1 or w=
hatever) only as a backup in case the network didn't tell it what DNS serve=
r to use.
   =20
    Reason: if nothing else, the device might be used in a network that has=
 local services that need to be accessible. Google is well informed, but ev=
en Google doesn't know everything, and specifically doesn't know about such=
 services. To me, this design decision borders on arrogance, and certainly =
isn't about enabling user control of the services they use. Net Neutrality =
and all that...
    -----------------------------------------------------------------------=
---------
    The fact that there is a highway to hell and a stairway to heaven is an=
 interesting comment on projected traffic volume...
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20



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

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Fri Mar 29 06:24: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 8C7311202A7 for ; Fri, 29 Mar 2019 06:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 ooXmAm2e0EN6 for ; Fri, 29 Mar 2019 06:24:51 -0700 (PDT)
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 614B6120279 for ; Fri, 29 Mar 2019 06:24:51 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id a84so821024ybg.10 for ; Fri, 29 Mar 2019 06:24:51 -0700 (PDT)
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:content-transfer-encoding; bh=g21wuCdii6CmVS4gTHO0mj2GtiHZAWCoTPm1ESah9+E=; b=nU0klCd2+H3yAZjzJx2Gkl8t7NizmzMcfMYLCcSBwSJqFNYrAypTauh5WPK9WGCLBm 0Lu0QhUngY1LLsIbFH+ZWNFleLuLtEX2hqvsArnQ26ugYIWBLu97EFwVNZfPL7d58RmC FdqteeYNQZnUdd2PkQdRvAocGaJUZUck1jRWIjfZeBGnG0fhAFFKnc0fqsYxCj+JOJSp FAFJVEOitenWlCi0DDoRgQDAwkFFh1b+5J6F4GAF5wiq8HGz6TtpTQdBKx7twyESG0bK gVoF/sA1X+sb7BAV2uVoXiYoZbqCMrm0vRtDsq1qI7DQCBmvqYemMqJSU0bgvr5qy82q KlnA==
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=g21wuCdii6CmVS4gTHO0mj2GtiHZAWCoTPm1ESah9+E=; b=tYHDIkHgxt61yEKJ2e1iSZzb+3D2sYnjZSwmHvhfjvibS2vJhIxuMKMZ7/1SbXn77F iFWfF5/tQCNW6UKvcFn5ML5sYONLPDpoFTD83lU5YU+BYrHVcbe394zsnNIWvNoqpFvW L8FOjAxsBeRtiAd1PuF0dvAr/jtVdRQN2bS9KgQOwe65CNU8cW1F0nlNCpq4Opx5DtbI 11ZEYcPxyPWzXBMdkwFXINY73r/048l2jRyi2r22LGNZae+mjFAZ26zF1c69zGAQKcI8 fOQQf5Pnh+v7w361c0557YgtillAEZdEO7V06x6Tu8HvPlD/EmX3au8ZC25LxEOrn8da tocw==
X-Gm-Message-State: APjAAAUW6aoCJYTGAsK0PmrJwvHnhcV8FeBXPqVrVE5EoAGMQYVJoToX NXf7cmBtZscTS5cm5odVoj0V2/B+KaE=
X-Google-Smtp-Source: APXvYqw/5HbdBl6cz3pzDwJhG2aDpd7uZ44q6fLhGVmwxUIZtgajSgL5T3otZSf+qJjRi7tfpA5lZA==
X-Received: by 2002:a25:8492:: with SMTP id v18mr5490643ybk.17.1553865890298;  Fri, 29 Mar 2019 06:24:50 -0700 (PDT)
Received: from mail-yw1-f43.google.com (mail-yw1-f43.google.com. [209.85.161.43]) by smtp.gmail.com with ESMTPSA id c205sm684208ywc.66.2019.03.29.06.24.49 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 06:24:49 -0700 (PDT)
Received: by mail-yw1-f43.google.com with SMTP id j66so651242ywc.10 for ; Fri, 29 Mar 2019 06:24:49 -0700 (PDT)
X-Received: by 2002:a81:e52:: with SMTP id 79mr41071783ywo.367.1553865889050;  Fri, 29 Mar 2019 06:24:49 -0700 (PDT)
MIME-Version: 1.0
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com> 
In-Reply-To: 
From: Richard Patterson 
Date: Fri, 29 Mar 2019 14:24:37 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Operations 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 13:24:55 -0000

Jordi, implementation details aside, I think this is a useful topic to
discuss and document.  Bypassing network-side translators has a very
tangible financial benefit to an operator, and was definitely taken in
to consideration during my IPv4aaS technology assessment and decision
making.

I'd like to add an alternative to the DNS/CLAT-based approach, there's
also the "deterministic addressing" approach that could be used, as
briefly touched on in RFC75977 Section 12.3.
i.e. if the CDN supports IPv4-derived IPv6 address using RFC6052, from
the NAT64 prefix, or the prefix defined in the MAP DMR, then we won't
need to do any DNS record-synthesizing, the network will simply use
the more specific IPv6 route direct to the CDN node, bypassing the
NAT64 translator.

-Rich

On Mon, 25 Mar 2019 at 15:09, JORDI PALET MARTINEZ
 wrote:
>
> Hi all,
>
> We have published a new version of this document, taking in consideration=
 a few inputs, clarified some examples, nits, etc.
>
> https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches=
/?include_text=3D1
>
> Regards,
> Jordi
>
>
>
>
> =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
>
>
>     A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
>     has been successfully submitted by Jordi Palet Martinez and posted to=
 the
>     IETF repository.
>
>     Name:               draft-palet-v6ops-464xlat-opt-cdn-caches
>     Revision:   01
>     Title:              464XLAT Optimization for CDNs/Caches
>     Document date:      2019-03-25
>     Group:              Individual Submission
>     Pages:              10
>     URL:            https://www.ietf.org/internet-drafts/draft-palet-v6op=
s-464xlat-opt-cdn-caches-01.txt
>     Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-46=
4xlat-opt-cdn-caches/
>     Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat=
-opt-cdn-caches-01
>     Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6o=
ps-464xlat-opt-cdn-caches
>     Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops=
-464xlat-opt-cdn-caches-01
>
>     Abstract:
>        This document describes the drawbacks of IP/ICMP Translation
>        Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
>        applications initiate traffic flows to dual-stack CDNs (Content
>        Delivery Networks) or Caches, which are forced to be translated ba=
ck
>        to IPv4 by a NAT64.  The document proposes possible solutions to
>        avoid that.
>
>
>
>
>     Please note that it may take a couple of minutes from the time of sub=
mission
>     until the htmlized version and diff are available at tools.ietf.org.
>
>     The IETF Secretariat
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or c=
onfidential. The information is intended to be for the exclusive use of the=
 individual(s) named above and further non-explicilty authorized disclosure=
, copying, distribution or use of the contents of this information, even if=
 partially, including attached files, is strictly prohibited and will be co=
nsidered a criminal offense. If you are not the intended recipient be aware=
 that any disclosure, copying, distribution or use of the contents of this =
information, even if partially, including attached files, is strictly prohi=
bited, will be considered a criminal offense, so you must reply to the orig=
inal sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Fri Mar 29 06:43: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 BE2B1120260 for ; Fri, 29 Mar 2019 06:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 QuRzul3ADana for ; Fri, 29 Mar 2019 06:43:35 -0700 (PDT)
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 411B5120254 for ; Fri, 29 Mar 2019 06:43:35 -0700 (PDT)
Received: from astfgl.hanazo.no (77.16.59.105.tmi.telenormobil.no [77.16.59.105]) (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 7228AFECC12F; Fri, 29 Mar 2019 13:43:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id ED8E2123F23E; Fri, 29 Mar 2019 14:43:28 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Ole Troan 
In-Reply-To: <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com>
Date: Fri, 29 Mar 2019 14:43:28 +0100
Cc: Fred Baker , IPv6 Operations 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CABACF0-DEDA-4743-9DE1-F3D0F171A6B2@employees.org>
References:  <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com>
To: "Rajiv Asati (rajiva)" 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 13:43:38 -0000

>=20
> Why is NUD not sufficient to address the problem (WAN neighbor =
unreachable)?=20
>=20
> I hope that the HGW devices are  compliant with RFC4861 / 7048.=20

With the typical deployment of a DHCPv6 PD snooping relay (for the =
purpose of route injection) it is helpful having a mechanism that also =
verifies the forwarding state of the first-hop router (PE).=20

Cheers,
Ole


>=20
> Cheers,
> Rajiv =20
>=20
>> On Mar 29, 2019, at 6:44 AM, Fred Baker  =
wrote:
>>=20
>> =
https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastr=
eam/, slide 9
>>=20
>> What do we want to say on this issue? Mikael mentions =
draft-patterson-intarea-ipoe-health as possibly relevant, but I also get =
the idea that there is more to say; in this case, I think I need to send =
a note to the relevant authors and chairs asking them what the prognosis =
is and expressing operational interest. First, is there a consensus to =
do that? Second, do we have additional comments to pass along? Our =
comments might be adequately summarized by forwarding a link to this =
thread, or might rise to the level that needs to be discussed in an =
internet draft in v6ops. Comments?
>> =
--------------------------------------------------------------------------=
------
>> Victorious warriors win first and then go to war,
>> Defeated warriors go to war first and then seek to win.
>>    Sun Tzu
>>=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 Fri Mar 29 06:51:16 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F02120280 for ; Fri, 29 Mar 2019 06:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 hmPrrjGSlvp5 for ; Fri, 29 Mar 2019 06:51:12 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED102120141 for ; Fri, 29 Mar 2019 06:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553867470; x=1554472270; i=jordi.palet@consulintel.es; q=dns/txt; h=Content-Transfer-Encoding: Content-Type:From:Mime-Version:Date:Message-Id:Subject: References:In-Reply-To:To; bh=ATrt+pr/HjjGOeT+3tDSkesF2rFlacgdvI jlzX5UA0k=; b=s3Q0MEGBCX8+c/plFo7d3aAQsXf7o4+dxONzmNXInHIz80h2qQ /3cdpnk2YXjIZnRPizfQAM8B/mg3ot6txitKWnQBjJlQBvefKvZfz+pqpj/oD7I7 4KWu3Ialix/27v+XWw1QzpY9VIz7/01ifYp+fyU5Nal7iIh831eb11K3o=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 29 Mar 2019 14:51:10 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 29 Mar 2019 14:51:09 +0100
Received: from [10.8.10.10] by mail.consulintel.es (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v16.5.2)  with ESMTPSA id md50006202699.msg for ; Fri, 29 Mar 2019 14:51:09 +0100
X-MDRemoteIP: 10.8.10.10
X-MDHelo: [10.8.10.10]
X-MDArrival-Date: Fri, 29 Mar 2019 14:51:09 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=199112b751=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
From: Jordi Palet Martinez 
Mime-Version: 1.0 (1.0)
Date: Fri, 29 Mar 2019 14:51:07 +0100
Message-Id: 
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>  
In-Reply-To: 
To: v6ops@ietf.org
X-Mailer: iPhone Mail (16D57)
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 13:51:15 -0000

I guess you don=E2=80=99t mean RFC75977 ?

I agree and we=E2=80=99ve investigated that as well, I think is the same we=
 described as the first approach in the ID, however:
A) Some CDN operators don=E2=80=99t want to use the WKP or NSP, at least I =
got those responses at the moment. They even mention a charge to customers =
for that.
B) This will not work when the CDN/caches aren=E2=80=99t in the ISP network=
, i.e., in a IX

I think it will be better a =E2=80=9Cself-contained=E2=80=9D solution, even=
 if the optimization may be not done in 100% of the cases.

Regards,
Jordi


> El 29 mar 2019, a las 14:24, Richard Patterson  esc=
ribi=C3=B3:
>=20
> Jordi, implementation details aside, I think this is a useful topic to
> discuss and document.  Bypassing network-side translators has a very
> tangible financial benefit to an operator, and was definitely taken in
> to consideration during my IPv4aaS technology assessment and decision
> making.
>=20
> I'd like to add an alternative to the DNS/CLAT-based approach, there's
> also the "deterministic addressing" approach that could be used, as
> briefly touched on in RFC75977 Section 12.3.
> i.e. if the CDN supports IPv4-derived IPv6 address using RFC6052, from
> the NAT64 prefix, or the prefix defined in the MAP DMR, then we won't
> need to do any DNS record-synthesizing, the network will simply use
> the more specific IPv6 route direct to the CDN node, bypassing the
> NAT64 translator.
>=20
> -Rich
>=20
> On Mon, 25 Mar 2019 at 15:09, JORDI PALET MARTINEZ
>  wrote:
>>=20
>> Hi all,
>>=20
>> We have published a new version of this document, taking in consideratio=
n a few inputs, clarified some examples, nits, etc.
>>=20
>> https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-cache=
s/?include_text=3D1
>>=20
>> Regards,
>> Jordi
>>=20
>>=20
>>=20
>>=20
>> =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
>>=20
>>=20
>>   A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
>>   has been successfully submitted by Jordi Palet Martinez and posted to =
the
>>   IETF repository.
>>=20
>>   Name:               draft-palet-v6ops-464xlat-opt-cdn-caches
>>   Revision:   01
>>   Title:              464XLAT Optimization for CDNs/Caches
>>   Document date:      2019-03-25
>>   Group:              Individual Submission
>>   Pages:              10
>>   URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops=
-464xlat-opt-cdn-caches-01.txt
>>   Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-464=
xlat-opt-cdn-caches/
>>   Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat-=
opt-cdn-caches-01
>>   Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6op=
s-464xlat-opt-cdn-caches
>>   Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-=
464xlat-opt-cdn-caches-01
>>=20
>>   Abstract:
>>      This document describes the drawbacks of IP/ICMP Translation
>>      Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
>>      applications initiate traffic flows to dual-stack CDNs (Content
>>      Delivery Networks) or Caches, which are forced to be translated bac=
k
>>      to IPv4 by a NAT64.  The document proposes possible solutions to
>>      avoid that.
>>=20
>>=20
>>=20
>>=20
>>   Please note that it may take a couple of minutes from the time of subm=
ission
>>   until the htmlized version and diff are available at tools.ietf.org.
>>=20
>>   The IETF Secretariat
>>=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 th=
e individual(s) named above and further non-explicilty authorized disclosur=
e, copying, distribution or use of the contents of this information, even i=
f partially, including attached files, is strictly prohibited and will be c=
onsidered a criminal offense. If you are not the intended recipient be awar=
e that any disclosure, copying, distribution or use of the contents of this=
 information, even if partially, including attached files, is strictly proh=
ibited, will be considered a criminal offense, so you must reply to the ori=
ginal 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


**********************************************
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 Mar 29 07:00:53 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD086120296 for ; Fri, 29 Mar 2019 07:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 fAj7gPsKpOeG for ; Fri, 29 Mar 2019 07:00:49 -0700 (PDT)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 07367120141 for ; Fri, 29 Mar 2019 07:00:49 -0700 (PDT)
Received: by mail-yb1-xb2d.google.com with SMTP id y4so869595ybr.8 for ; Fri, 29 Mar 2019 07:00:48 -0700 (PDT)
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:content-transfer-encoding; bh=lQm/RH3WKt3CrXCgXT1qHachsiqOIsGU6eADwCpnQ/w=; b=tUKcFNs+cYNYUC3hy3G850STPDlQ9OfI9Asno1vkU2YN8xcIKlBKRXS+7fNop1LQLL UNQMsRSPfu7aM8yzgRVqhKWYbdig3zq96b8Le6cC0f1/FeeVjIbQmQiehe/eB59RMm3g IAs2JyxHonIaWhOce0dIR+LyExEooItb3x3Gt3yKeGeF5i8M//kFI1d4LsJUKAafskOD BG792nj1bCcEt4hgFgV7ieoUUZxsN3yDkQaH0eChlaVECTUVLyK/++u0qm7rl6N4yv0Q Ju04mVdhpyTSfWAzjH0tVy4yzMhz1ZQ7zbhp4WnUCAyLDqDjQaajSlAaV8u1p7DXWHm6 mHzw==
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=lQm/RH3WKt3CrXCgXT1qHachsiqOIsGU6eADwCpnQ/w=; b=K/I61W7oXCgEJdHvFj5RJHeKkOoOC28Z1Zs/CqNuf0cSbpPkzovBJvMoe+b/oLitd5 ZSN2wycWHhc9B/haFX7AVYEDP+FZ24KneEzaP9T1lnEcEL89fQBlIDKXDmP+oXvFE56X OPjZY6AzSLc4l52y6uz8iyuh/wD7yJdYYYigoqJb6GQufmhte7pCkVXbltmEwDnf7pNX BbE2M+9bIcoznDaxS7OKxMzh8Roq9bMEoD7XcMYRNN3f8zaW15SWpMj6Bk2vAckxIq6v scS2DNLA+/33rHUEMPeCk70v48oT6n+oZKzyiNSSfvlGCS+PxJSxqoGWOyO6i4LlhxQ2 KfUw==
X-Gm-Message-State: APjAAAXTQktAbq7LKMgO63jqAK/aohaLqynd8J780txjB0BedKxjCUYS pCHvflZsWMxAaL/VBKK2gxOfRmN3goY=
X-Google-Smtp-Source: APXvYqyfzCTWU3o4RkUHhFGC/40fGsMTcOfLmovLv0LRnncgB/l2l2aotBwGTniuUMfNYjmFzg9p5A==
X-Received: by 2002:a5b:70f:: with SMTP id g15mr37812653ybq.382.1553868047873;  Fri, 29 Mar 2019 07:00:47 -0700 (PDT)
Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id 79sm1056267ywr.110.2019.03.29.07.00.47 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 07:00:47 -0700 (PDT)
Received: by mail-yb1-f170.google.com with SMTP id i10so890528ybk.0 for ; Fri, 29 Mar 2019 07:00:47 -0700 (PDT)
X-Received: by 2002:a25:9305:: with SMTP id f5mr7651642ybo.193.1553868046780;  Fri, 29 Mar 2019 07:00:46 -0700 (PDT)
MIME-Version: 1.0
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>   
In-Reply-To: 
From: Richard Patterson 
Date: Fri, 29 Mar 2019 15:00:35 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Jordi Palet Martinez 
Cc: "v6ops@ietf.org list" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.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: Fri, 29 Mar 2019 14:00:52 -0000

Sorry, RFC7599 MAP-T.

On Fri, 29 Mar 2019 at 14:52, Jordi Palet Martinez
 wrote:
>
>
> I guess you don=E2=80=99t mean RFC75977 ?
>
> I agree and we=E2=80=99ve investigated that as well, I think is the same =
we described as the first approach in the ID, however:
> A) Some CDN operators don=E2=80=99t want to use the WKP or NSP, at least =
I got those responses at the moment. They even mention a charge to customer=
s for that.
> B) This will not work when the CDN/caches aren=E2=80=99t in the ISP netwo=
rk, i.e., in a IX
>
> I think it will be better a =E2=80=9Cself-contained=E2=80=9D solution, ev=
en if the optimization may be not done in 100% of the cases.
>
> Regards,
> Jordi
>
>
> > El 29 mar 2019, a las 14:24, Richard Patterson  e=
scribi=C3=B3:
> >
> > Jordi, implementation details aside, I think this is a useful topic to
> > discuss and document.  Bypassing network-side translators has a very
> > tangible financial benefit to an operator, and was definitely taken in
> > to consideration during my IPv4aaS technology assessment and decision
> > making.
> >
> > I'd like to add an alternative to the DNS/CLAT-based approach, there's
> > also the "deterministic addressing" approach that could be used, as
> > briefly touched on in RFC75977 Section 12.3.
> > i.e. if the CDN supports IPv4-derived IPv6 address using RFC6052, from
> > the NAT64 prefix, or the prefix defined in the MAP DMR, then we won't
> > need to do any DNS record-synthesizing, the network will simply use
> > the more specific IPv6 route direct to the CDN node, bypassing the
> > NAT64 translator.
> >
> > -Rich
> >
> > On Mon, 25 Mar 2019 at 15:09, JORDI PALET MARTINEZ
> >  wrote:
> >>
> >> Hi all,
> >>
> >> We have published a new version of this document, taking in considerat=
ion a few inputs, clarified some examples, nits, etc.
> >>
> >> https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-cac=
hes/?include_text=3D1
> >>
> >> Regards,
> >> Jordi
> >>
> >>
> >>
> >>
> >> =EF=BB=BFEl 25/3/19 15:05, "internet-drafts@ietf.org"  escribi=C3=B3:
> >>
> >>
> >>   A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-01.tx=
t
> >>   has been successfully submitted by Jordi Palet Martinez and posted t=
o the
> >>   IETF repository.
> >>
> >>   Name:               draft-palet-v6ops-464xlat-opt-cdn-caches
> >>   Revision:   01
> >>   Title:              464XLAT Optimization for CDNs/Caches
> >>   Document date:      2019-03-25
> >>   Group:              Individual Submission
> >>   Pages:              10
> >>   URL:            https://www.ietf.org/internet-drafts/draft-palet-v6o=
ps-464xlat-opt-cdn-caches-01.txt
> >>   Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-4=
64xlat-opt-cdn-caches/
> >>   Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xla=
t-opt-cdn-caches-01
> >>   Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6=
ops-464xlat-opt-cdn-caches
> >>   Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6op=
s-464xlat-opt-cdn-caches-01
> >>
> >>   Abstract:
> >>      This document describes the drawbacks of IP/ICMP Translation
> >>      Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
> >>      applications initiate traffic flows to dual-stack CDNs (Content
> >>      Delivery Networks) or Caches, which are forced to be translated b=
ack
> >>      to IPv4 by a NAT64.  The document proposes possible solutions to
> >>      avoid that.
> >>
> >>
> >>
> >>
> >>   Please note that it may take a couple of minutes from the time of su=
bmission
> >>   until the htmlized version and diff are available at tools.ietf.org.
> >>
> >>   The IETF Secretariat
> >>
> >>
> >>
> >>
> >>
> >> **********************************************
> >> IPv4 is over
> >> Are you ready for the new Internet ?
> >> http://www.theipv6company.com
> >> The IPv6 Company
> >>
> >> This electronic message contains information which may be privileged o=
r confidential. The information is intended to be for the exclusive use of =
the individual(s) named above and further non-explicilty authorized disclos=
ure, copying, distribution or use of the contents of this information, even=
 if partially, including attached files, is strictly prohibited and will be=
 considered a criminal offense. If you are not the intended recipient be aw=
are that any disclosure, copying, distribution or use of the contents of th=
is information, even if partially, including attached files, is strictly pr=
ohibited, will be considered a criminal offense, so you must reply to the o=
riginal sender to inform about this communication and delete it.
> >>
> >>
> >>
> >> _______________________________________________
> >> 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 c=
onfidential. The information is intended to be for the exclusive use of the=
 individual(s) named above and further non-explicilty authorized disclosure=
, copying, distribution or use of the contents of this information, even if=
 partially, including attached files, is strictly prohibited and will be co=
nsidered a criminal offense. If you are not the intended recipient be aware=
 that any disclosure, copying, distribution or use of the contents of this =
information, even if partially, including attached files, is strictly prohi=
bited, will be considered a criminal offense, so you must reply to the orig=
inal sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Fri Mar 29 09:09: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 EFB0912001B for ; Fri, 29 Mar 2019 09:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yebJrCNxPqIb for ; Fri, 29 Mar 2019 09:09:45 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC7F120013 for ; Fri, 29 Mar 2019 09:09:45 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id z24so3460811wmi.5 for ; Fri, 29 Mar 2019 09:09:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=68xf+dct1zKhJN9EYIOT+qE0msKdcG9Xyyl4GEs1ayY=; b=MNE7sE0ODdN/YZF/kp4ofBQsqSNFKJF/wDbOssdCVq3COq0EUDScumMb3LG5qzFphc 5TTA4RGUAGSoSwYW9SJefmVB0qoBWaaEJfImqs+yw+pZv3ZLWTnFeLgneGJTSHF39bMW kB8OxdKPXHsAmzp3bV1EMWMoq8vzx3jP7O7CKvFRy1qziua8xneGlc7cW94VlGvfp568 T9cRlxRuFoI6N7EWJFhPD+sdmPeOyaN2FUcYiGg0fsOzu3NszhnXN66LwtaxF6tS/I9W yoI7x5UM3hUAWe+h+/EUQNN+s/CYeXl8sQGmMMhRDotFdRoDHnZyyFB/QMFyChGW0MJ+ r2qQ==
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=68xf+dct1zKhJN9EYIOT+qE0msKdcG9Xyyl4GEs1ayY=; b=ZSa0RbLa/DcpZjkkDB3cV2CBTUSJHM4/QrigIhz+/XST4vbGgUhv1dVDHuf2zklPro tUmM1dmvS6wHH8qkZK660RCTJX2TbyAft76k22uxTkG0oYMhZ4Uc6+0zkcLp1kqpM+EJ 0k1goE481KnMIj7v5FPu0H4OXDbl6vCrzkM35wn2FFqbCm2lmq3oXTSjiUsvMtPE+vhj jopKfzPYkFjoK1wBXHRsTFAWMsV2Vov+Xf/n78t5dVdV8M3PJLEZsQViYK4df3Fs7Vag /LueL8n6PDpYEs876sFSotKSHkavhgm4dhaLU4Ot7eGlfws3ugrhiMUuziZE8IhDe2qH vIzA==
X-Gm-Message-State: APjAAAVumiBG4vpHApcquXrqSmDceoiJW6sZ9lcnOz3kijAa4JXNq42v ur4qlznHa5o/WgFRlf1jRBkumqbcT1E=
X-Google-Smtp-Source: APXvYqxiHsNwRrUnOG4F1CTLyqm57Ik4cASvuqpMgDSX6Gqhes+NgoK4DFZZpCedQxqrPpuPjA2jkw==
X-Received: by 2002:a1c:808c:: with SMTP id b134mr4251780wmd.16.1553875784024;  Fri, 29 Mar 2019 09:09:44 -0700 (PDT)
Received: from [10.0.6.52] ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id t81sm4675187wmb.5.2019.03.29.09.09.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 09:09:42 -0700 (PDT)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_ED568074-95E7-464F-A82B-B50DF87E0C96"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Fri, 29 Mar 2019 17:09:37 +0100
In-Reply-To: 
Cc: "Rajiv Asati (rajiva)" , IPv6 Operations 
To: Mikael Abrahamsson 
References:  <86DE9F4C-CF1F-4D23-BAA8-3051459BCC86@cisco.com> <535CB70C-1121-481E-8838-2AF031208C9B@gmail.com> 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Upstream liveness
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 16:09:48 -0000

--Apple-Mail=_ED568074-95E7-464F-A82B-B50DF87E0C96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Mar 29, 2019, at 10:55 AM, Mikael Abrahamsson  =
wrote:
>=20
> On Fri, 29 Mar 2019, Fred Baker wrote:
>=20
>> Well, that seems like a reasonable hope. I think that Mikael is =
saying that in IPOE environments they might not be compliant, or =
compliant implementations still have a problem. I think the key point =
here is to uncover what the issue might be in the context he is =
discussing, as opposed to simply dismissing it.
>=20
> RFC7084 doesn't say (afaik) to stop announcing yourself as a default =
router on LAN when your default GW LL next-hop becomes unreachable, and =
then start doing RS, throw away your DHCPv6 prefix etc, and start to go =
back into whatever you do in an WAN interface down/up situation.

Is this for VRRP purposes, or simply as a router in an RA?

One thought in the near term would be to add that as an "erratum" to the =
RFC, so it gets picked up when the RFC is revised. If we were to create =
an updating RFC entitled "what to do when your next hop moves away", is =
there anything else we would want to include?

> This is what is unspecified. We know pretty well what to do in an WAN =
interface down/up event, but not "softer" errors such as when the RA =
sending LL next-hop goes into ND unreachable state.
>=20
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se

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


--Apple-Mail=_ED568074-95E7-464F-A82B-B50DF87E0C96
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+AFAlyeQ0EACgkQEhdRnd2G
P+C54w/+NyQzGKaUB+DTEJ6DTm5B9sjwg8jEtb6URD6AF0h1nz4zRK9DB3ImLbLQ
81a24koBro5/nS5vgYUVvg26JRfKnEPz0NIeBpC/mqEudx3ZXzliUqlLQTxv0G3q
/B6GiBnpG4zednoAhEJElb0BlRlqIyrqpXDMSBPuF42jWdsAMRFVbj8wdpz0GWlb
k0W4BOAbN2vtC+CrHANaNxa7oSLGXqDEsFPpQLmmA3WmuG15qTxqzT9BaTZUVrn+
RetA02hqlKL8xQUAPSHPdwsSkSsPo1dhcmq+tzQ4tvLIK7dSH3vjS7vRUM92PGS6
ef8c/dAQ3lYq7e5f0wqOFxXgynBJOeOTspt2tJkW53xA+KBv/nx+LKGFQwVNi4+M
tzTMSyEyxKPv4Q0D7IJhCJ+hU6wEMIywlkrgajCH0cTfe1eobvO5te4Te6QkaaFP
RpyzUlsP5g+nXczVYzA2HMbWXW2AdVg3U+k1XaO/OA5yW5O6G5KqT6OeY3rhtV8K
fXTJwMzFd537TEzZdFpgARihoYMigmz+N21G4VHKkFlm026Y0vb+b8bARd7Fqy6I
l38j5O59ZubBll8tk2uR7a/IAe/x8li8mZyq+xSPNqTJ+IAO7xrut6qHEoFVzEKw
StOVrUovnuWGBKoOE2tMj+/G/tTys+FI4Eaa/12J3FmAJ8sFq+w=
=2oXK
-----END PGP SIGNATURE-----

--Apple-Mail=_ED568074-95E7-464F-A82B-B50DF87E0C96--


From nobody Fri Mar 29 09:34: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 AEDE012018F for ; Fri, 29 Mar 2019 09:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mRMCIeH7uXP6 for ; Fri, 29 Mar 2019 09:34:53 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CD812004C for ; Fri, 29 Mar 2019 09:34:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1553877291; x=1554482091; 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=vzfUVV6e tuhWOJx2PqK7uQtBw3Pg2jmtq51PEr3zw5I=; b=DvllGH6TAafyp1VkdTobJR/r pHqECPRV9U/vIJh706l3pm0o0TyDhaezid0IFezpAbfcMo7iLf55uvR4BgTLIM6s 9O9BB25NIcFGP464WlqFntqtk62MrIYPveYyDroZoH+xZ8iHL8pMeb83W3HjDfjl Re7MC0ABoC1JXZ/Duyo=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 29 Mar 2019 17:34:51 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 29 Mar 2019 17:34:50 +0100
Received: from [172.20.10.5] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006202771.msg for ; Fri, 29 Mar 2019 17:34:50 +0100
X-MDRemoteIP: 88.31.30.92
X-MDHelo: [172.20.10.5]
X-MDArrival-Date: Fri, 29 Mar 2019 17:34:50 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=199112b751=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Fri, 29 Mar 2019 17:13:32 +0100
From: JORDI PALET MARTINEZ 
To: IPv6 Operations 
Message-ID: <74D0026C-9DB6-43E1-8674-6AEF84D4DFF8@consulintel.es>
Thread-Topic: [v6ops] draft-ietf-opsec-v6
References: 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] draft-ietf-opsec-v6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 16:34:57 -0000

Hi all,

Thanks for the reminder, overdue task for me for a while ... So here is it =
(partially, as I'm working in the plane, so more in following emails).

2.1.  Addressing Architecture

   Once an address allocation has been assigned, there should be some
   thought given to an overall address allocation plan.  With the
   abundance of address space available, an address allocation may be
   structured around services along with geographic locations, which
   then can be a basis for more structured security policies to permit
   or deny services between geographic regions.

One of MOST frequent issues when you start implementing IPv6 is that people=
 tend to go to their RIR for a default allocation/assignment, and then try =
to make the addressing plan with what they have, instead of planning correc=
tly and then going to the RIR. The result is many cases is ISPs providing a=
 single /64 to customers, which is really bad.

Also, if the document is for operators and enterprises, you need to differe=
ntiate among allocation and assignment.

So, I will like to suggest rewording as:
"A key task before starting an IPv6 deployment, once the sufficient knowled=
ge has been acquired, is to prepare an addressing plan. With the abundance =
of address space available, an addressing plan may be structured around ser=
vices along with geographic locations, which then can be a basis for more s=
tructured security policies to permit or deny services between geographic r=
egions.

This may be seen as a simple task, but it is an activity within the IPv6 de=
ployment project, that requires a very in depth thinking and it makes sense=
 to invest as much time as required on it. Only once that addressing plan h=
as been designed is the right time to go to the relevant Regional Internet =
Registry (RIR) to ask for an allocation or an assignment."

Then, in the next p.:

   A common question is whether companies should use Provider
   Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from
   a security perspective there is little difference.

Replace with

"A common question is whether companies should use Provider Independent (PI=
) vs Provider Allocated (PA) space [RFC7381], but from a security perspecti=
ve there is little difference. From the RIRs policies perspective, PI space=
 is assigned to organizations if they don't need to sub-assign to third par=
ties, while PA is allocated to operators or organizations that will sub-ass=
ign to third parties. For example, a big corporation may have different sub=
sidiaries and they are legally different entities, so in this case each one=
 need their own PI space, or the responsible for the network need to get al=
located PA space. A public institution such as a Ministry, may get a PI, if=
 is only for their own use and not for other government institutions, howev=
er if it is the government entity managing the network that interconnects s=
everal institutions and provide each one their own space, they need to obta=
in PA space."

And continue with "However, one ..." in a new p.

2.1.1.  Statically Configured Addresses

Nit:
The use of well-known(such
The use of well-known (such

There are many scanning techniques and more to
   come possible, hence, operators should never relly on the 'impossible
   to find because my address is random' paradigm.

I will say:

There are many scanning techniques and more to
   come possible, hence, operators should never relly on the 'impossible
   to find because my address is random' paradigm, even if it is a good pra=
ctice to have the statically configured addresses randomly distributed acro=
ss the /64 subnets and use always DNS.

2.1.2.  Use of ULAs

I will add:

"Even if today a network is not connected to Internet, and it looks like it=
 will not be in the future, things change and it is a considerable effort t=
o renumber it. So it may be relevant to obtain an IPv6 PI assignment from t=
he RIR and have a stable addressing space since day one."

2.1.3.  Point-to-Point Links

I disagree with the mention that RFC6164 indicate that /127 is the way. RFC=
6164 is about "routers must support it". See draft-palet-v6ops-p2p-links (n=
ew version coming soon, so may be a reference to it). So I think some rewor=
ding is needed here, specially because router vendors sorted out those bugs=
 long time ago.

2.1.4.  Temporary Addresses - Privacy Extensions for SLAAC

I will add, that "In those cases where accounting/auditing/extreme granular=
 security is required, because is impractical to use DHCPv6 due to the lack=
 of support in Android based OSs, link-layer security such as IEEE802.1x ma=
y be used."

2.1.6.  DHCP/DNS Considerations

This probably belongs to another section (may be a specific one for DNS), b=
ut related:

"If there is a need for Statically Configured Addresses, it should consider=
ed using DNS to refer to them, so no hard-coded addresses are used by appli=
cations. This facilitates also debugging/troubleshooting as avoids remember=
ing addresses. In may be advisable to have multiple-faced DNS ("views") in =
order to ensure that internal-only used hosts, aren't published globally an=
d full zone transfers are disallowed."

2.1.7.  Using a /64 per host

I will add:

"This also avoids the need to "proxy" or NAT-like operations if multiple VM=
s, containers, or similar ones, need their own IPv6 address from a single /=
64 ."

Regards,
Jordi
=20
=20

=EF=BB=BFEl 29/3/19 6:19, "v6ops en nombre de Fred Baker"  escribi=C3=B3:

    Yesterday, the authors of an opec draft asked us for comments on their =
draft, which is in a second WGLC in opec (opsec@ietf.org). You may have mis=
sed the character string:
   =20
    https://datatracker.ietf.org/doc/draft-ietf-opsec-v6
    https://tools.ietf.org/html/draft-ietf-opsec-v6
      "Operational Security Considerations for IPv6 Networks", Eric Vyncke,
      Chittimaneni Kk, Merike Kaeo, Enno Rey, 2019-03-11,
   =20
    I'd encourage people to read it and comment on the opec list.
   =20
    -----------------------------------------------------------------------=
---------
    Victorious warriors win first and then go to war,
    Defeated warriors go to war first and then seek to win.
         Sun Tzu
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20



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

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Fri Mar 29 09:57: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 4DAFD120096 for ; Fri, 29 Mar 2019 09:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx2HVlFpVj9M for ; Fri, 29 Mar 2019 09:57:42 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5AA120048 for ; Fri, 29 Mar 2019 09:57:42 -0700 (PDT)
Received: from [IPv6:2a02:8308:40:3000:b044:9b9a:327d:b750] (unknown [IPv6:2a02:8308:40:3000:b044:9b9a:327d:b750]) (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 EC4688363A; Fri, 29 Mar 2019 17:57:37 +0100 (CET)
To: Enno Rey , v6ops@ietf.org
Cc: merike@doubleshotsecurity.com
References: <20190328213600.GF70134@ernw.de>
From: Fernando Gont 
Openpgp: preference=signencrypt
Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA==
Message-ID: <4348efda-0c19-d840-9d18-b867b71a659c@gont.com.ar>
Date: Fri, 29 Mar 2019 17:57:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <20190328213600.GF70134@ernw.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] draft-ietf-opsec-v6-16
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 16:57:46 -0000

Hello, Enno et al,

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

I had provided a review of the first half of the I-D on the opsec list.
I promise I will review the second half in the next week or so.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Fri Mar 29 13:59: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 0D15D1204A1 for ; Fri, 29 Mar 2019 13:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level: 
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV51lFQa_PYN for ; Fri, 29 Mar 2019 13:58:52 -0700 (PDT)
Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 BA5FD12046B for ; Fri, 29 Mar 2019 13:58:51 -0700 (PDT)
Received: by mail-wr1-f44.google.com with SMTP id w1so4202448wrp.2 for ; Fri, 29 Mar 2019 13:58:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wndfZV6mn9BhXuiRpJ7ksq7Ws716RSc3Ysbptwbiuuk=; b=YXr4p8T3egUSsQELOIrCk8zjijQfGFoqJzwDNdDTx0c98AlUEkjdsn1dm3LbbrY9Io MB/z36rxTl2ePjDKkLjfi00egRcmTnSmHaB4RU+NEgHrY2IXwzhd4CsdLu2orcWGef3y +tlwM23FEhYD2F6aH9wBW/eLkKZbZGqvVWfVmSUbyDwTDV/mNxEk023BKj7L9HEdiC47 iPGEffD8GZnExrh09LB4kFy+irXLP57gwB0cvbEyHl6HdX2zpse/K8KidSqGljF2T43S gAPb/onljLdLTY4bNl5PwwOq8cTIblAU6/AeUZv/qB6EhB386XHy0SnLMxkv0Mv3XboE T0ew==
X-Gm-Message-State: APjAAAU2Ifk+Jnesae3BJ0zJmV8J4mEQaIFuN3pywVTVeI7fW0i5/ON7 Rxz4JGdHFIQ0/8lege7Z/XQQDXKlY/kUF5d7y/s=
X-Google-Smtp-Source: APXvYqw0eZOpWDlWlnyiEAJ6vnaAoG1oKm6zlnmX9lLim/6NPCEpib+dHZfM88VTwmNhXdRjMIZXq3PEM2pYjT5EQP4=
X-Received: by 2002:a05:6000:1250:: with SMTP id j16mr31541389wrx.135.1553893129957;  Fri, 29 Mar 2019 13:58:49 -0700 (PDT)
MIME-Version: 1.0
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>     <0153779E-91C8-4D9F-9454-CE44E2E9A9A8@gmail.com>
In-Reply-To: <0153779E-91C8-4D9F-9454-CE44E2E9A9A8@gmail.com>
From: Erik Nygren 
Date: Fri, 29 Mar 2019 16:58:37 -0400
Message-ID: 
To: Fred Baker 
Cc: IPv6 Operations 
Content-Type: multipart/alternative; boundary="00000000000007b80c058541f03b"
Archived-At: 
Subject: Re: [v6ops] Default DNS Server
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 20:59:01 -0000

--00000000000007b80c058541f03b
Content-Type: text/plain; charset="UTF-8"

For those who haven't seen it, this was perhaps one of the hottest topics
at this IETF.
See the discussions in DoH, DPRIVE, a session Wednesday afternoon, and
elseswhere.
There is a strong desire by some parties to use "more trustworthy DNS
resolvers"
which means not necessarily trusting the network-offered resolver.
I suspect this may not immediately impact consumer electronics,
but it could impact some browsers.

Some response perspectives, at least one of which mentions DNS64:

https://tools.ietf.org/html/draft-reid-doh-operator-00
https://tools.ietf.org/html/draft-livingood-doh-implementation-risks-issues-03

For what it's worth, Firefox doesn't yet do DNS64 synthesis when using a
DoH server
(and actually also does happy eyeballs backwards when doing DoH),
but now has bugs open to fix both.

      Erik




On Fri, Mar 29, 2019 at 1:57 AM Fred Baker  wrote:

> On Mar 28, 2019, at 5:11 PM, JORDI PALET MARTINEZ  40consulintel.es@dmarc.ietf.org> wrote:
> > 1) Mikael mention that Chromecast (and other devices), use a manually
> configured DNS such as 8.8.8.8.
>
> This is a different comment than Jordi's topic, but I'm of the opinion
> that the use of services like 8.8.8.8 by default overrides what might be
> local policy. I'd really like to see such things use 8.8.8.8 (or 1.1.1.1 or
> whatever) only as a backup in case the network didn't tell it what DNS
> server to use.
>
> Reason: if nothing else, the device might be used in a network that has
> local services that need to be accessible. Google is well informed, but
> even Google doesn't know everything, and specifically doesn't know about
> such services. To me, this design decision borders on arrogance, and
> certainly isn't about enabling user control of the services they use. Net
> Neutrality and all that...
>
> --------------------------------------------------------------------------------
> The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--00000000000007b80c058541f03b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


For those who haven't seen it, this was perhaps one of the hottest =
topics at this IETF.
See the discussions in DoH, DPRIVE, a session Wednesday=
 afternoon, and elseswhere.
There is a strong desire by some parties to use =
"more trustworthy DNS resolvers"
which means not necessarily trust=
ing the network-offered resolver.
I suspect this may not immediately impac=
t consumer electronics,
but it could impact some browsers.

Some respons=
e perspectives, at least one of which mentions DNS64:

https://tools.ietf.org/h=
tml/draft-reid-doh-operator-00
https://tools.ietf.org/h=
tml/draft-livingood-doh-implementation-risks-issues-03

For what it&=
#39;s worth, Firefox doesn't yet do DNS64 synthesis when using a DoH se=
rver
(and actually also does happy eyeballs backwards when doing DoH), 
<=
/div>
b=
ut now has bugs open to fix both.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Eri=
k




On Fri, Mar 29, 2019 at 1:57 AM Fr=
ed Baker <fredbaker.ietf@gma=
il.com> wrote:
On Mar 28, 2019, at 5:11 PM, JORDI PALET MARTINEZ <jordi.palet=3D<=
a href=3D"mailto:40consulintel.es@dmarc.ietf.org" target=3D"_blank">40consu=
lintel.es@dmarc.ietf.org> wrote:

> 1) Mikael mention that Chromecast (and other devices), use a manually =
configured DNS such as 8.8.8.8.



This is a different comment than Jordi's topic, but I'm of the opin=
ion that the use of services like 8.8.8.8 by default overrides what might b=
e local policy. I'd really like to see such things use 8.8.8.8 (or 1.1.=
1.1 or whatever) only as a backup in case the network didn't tell it wh=
at DNS server to use.



Reason: if nothing else, the device might be used in a network that has loc=
al services that need to be accessible. Google is well informed, but even G=
oogle doesn't know everything, and specifically doesn't know about =
such services. To me, this design decision borders on arrogance, and certai=
nly isn't about enabling user control of the services they use. Net Neu=
trality and all that...

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

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



_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops




--00000000000007b80c058541f03b--


From nobody Fri Mar 29 14:14:04 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2419120273 for ; Fri, 29 Mar 2019 14:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level: 
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCgcdN5SeiMw for ; Fri, 29 Mar 2019 14:14:01 -0700 (PDT)
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E1812002F for ; Fri, 29 Mar 2019 14:14:00 -0700 (PDT)
Received: by mail-wm1-f50.google.com with SMTP id y197so4372069wmd.0 for ; Fri, 29 Mar 2019 14:14:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TZSiAOqaJqiK+S6su87wprl7NgokEyhxYv8e3ek15Rk=; b=Un4UrBfXQlSN11C8KX+ZGU7+EHw8aCBmgbPxjV2kCgfulDHFwzgqQU1G5t0REPt5LE MVV43yzUyQPFU01FWMfjeu+/JZOR+feI6diFHc2TQw/OTF9aW9vsrDAvuZOSXwNffJGC +knSrg7iVzwduB6DGFy236Q9Nuj6LqWftw4mPiPknhAaPx97jfQD3wOAEXaBFPfNPA6b iP1qfem2n/58CloIlQ/98h76PKz25wgST1QlI+zR/anqOB5r6WyDVbe+QsaoVVvbjieu NERlP7U0gO81CrULWU7a/ptEeWSHM3tmEHZW1QeZMcNlU809wu6oGDbYttt02jWZPW1y mwRg==
X-Gm-Message-State: APjAAAW4YCK7kTOqvMRs3t1PFtwCu1ZqKdylWLk/kWBds5JtwPUcCNiS E6zswrX08JFT41HDSCMPjgcdVDMq1yolbvJ/s1U=
X-Google-Smtp-Source: APXvYqwjePpD5bL9NeItyYw38rJ57EM7h5S5wKu8z58sxfVkQeKr1sYJGkecXTA8k9xOjEzlOPW2yPh16eubsI8Ub+A=
X-Received: by 2002:a7b:c446:: with SMTP id l6mr4885286wmi.80.1553894039010; Fri, 29 Mar 2019 14:13:59 -0700 (PDT)
MIME-Version: 1.0
References: <1A61CA23-6BFF-46E5-9603-9E9FA06FB87B@consulintel.es>
In-Reply-To: <1A61CA23-6BFF-46E5-9603-9E9FA06FB87B@consulintel.es>
From: Erik Nygren 
Date: Fri, 29 Mar 2019 17:13:47 -0400
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Operations 
Content-Type: multipart/alternative; boundary="00000000000036c63e0585422648"
Archived-At: 
Subject: Re: [v6ops] multiple A and/or AAAA in CDNs - draft-palet-v6ops-464xlat-opt-cdn-caches
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 21:14:03 -0000

--00000000000036c63e0585422648
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 29, 2019 at 5:09 AM JORDI PALET MARTINEZ  wrote:

> Question for CDN folks.
>
> When you provide multiple A or AAAA records, from the view of a "given"
> ISP, all them work the same from the perspective of the host?



> If there is no "difference" in what A or AAAA is used, then we don't need
> to consider which one to pick for the EAMT entry (same chances than when
> the host is doing the choice).


>From a given ISP or resolver, multiple A and AAAA records in the respective
rrsets generally is just intended for load balancing and to allow client
fail-over.  What generally matters is that they should preferably be
round-robined or permuted by clients on-average.

For the draft-palet-v6ops-464xlat-opt-cdn-caches use-case, of you see
multiple A and multiple AAAA responses, I'd suggest doing something like
randomizing or permuting their order and then pairing them up.  For example
if you have RRSETs of:

192.0.2.1
192.0.2.2
192.0.2.3
192.0.2.4

2001:db8::4:a
2001:db8::4:b
2001:db8::4:c

Then you might want to end up with a pairing like:

192.0.2.1 ==> 2001:db8::4:c
192.0.2.2 ==> 2001:db8::4:a
192.0.2.3 ==> 2001:db8::4:a
192.0.2.4 ==> 2001:db8::4:b

Don't assume both are the same length.  This preserves the ability of the
client to do fail-over and also doesn't get in the way of round-robin style
behaviors.

Otherwise, I don't see how, if a host uses a different DNS resolver (i.e.,
> 1.1.1.1, 8.8.8.8, etc., from the ISP one) you avoid breaking "something".
>

This seems to be a different topic?  But here it depends on the CDN and
their architecture.  Many CDNs do "DNS-based mapping" meaning that which
resolver you use determines which cluster you get directed to.  This makes
is strongly preferential to use the network-provided resolver as it is
generally configured to send you to a local CDN cluster.  If you use a DNS
resolver that is off-net, you may sometimes be sent to a CDN cluster
off-net.  One way that some public resolvers deal with this is by
implementing ECS (RFC 7871) whereby they send a subnet to the authority
when resolving.

     Erik

--00000000000036c63e0585422648
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Fri, Mar 29, 2019 at 5:09 AM JORDI PAL=
ET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:
Question for CDN folks.



When you provide multiple A or AAAA records, from the view of a "given=
" ISP, all them work the same from the perspective of the host?
=C2=A0
If=
 there is no "difference" in what A or AAAA is used, then we don&=
#39;t=20
need to consider which one to pick for the EAMT entry (same chances than
 when the host is doing the choice).
=C2=A0
From a given ISP or resolver, multiple A and AAAA records in the respecti=
ve rrsets generally is just intended for load balancing and to allow client=
 fail-over.=C2=A0 What generally matters is that they should preferably be =
round-robined or permuted by clients on-average. 

For the draft-palet-v6ops-464xlat-opt-cdn-caches use-case, of yo=
u see multiple A and multiple AAAA responses, I'd suggest doing somethi=
ng like randomizing or permuting their order and then pairing them up.=C2=
=A0 For example if you have RRSETs of:

192.0.2.1
192.0.2=
.2
192.0.2.3
192.0.2.4

2001:db8::4:a
200=
1:db8=
::4:b
2001:db8::4:c

Then you =
might want to end up with a pairing like:

192.=
0.2.1 =3D=3D> 2001:db8::4:c
192.0.2.2 =3D=3D> 20=
01:db8::4:a
192.0.2.3 =3D=3D> 2001:db8::4:a
192.0.2.4 =3D=3D> 2001:db8::4:b

Don't assume both are the same length.=C2=A0 This preserves the a=
bility of the client to do fail-over and also doesn't get in the way of=
 round-robin style behaviors.
<=
span class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">


Otherwise, I don't see how, if a host uses a different DNS resolver (i.=
e., 1.1.1.1, 8.8.8.8, etc., from the ISP one) you avoid breaking "some=
thing".

This seems to be a different top=
ic?=C2=A0 But here it depends on the CDN and their architecture.=C2=A0 Many=
 CDNs do "DNS-based mapping" meaning that which resolver you use =
determines which cluster you get directed to.=C2=A0 This makes is strongly =
preferential to use the network-provided resolver as it is generally config=
ured to send you to a local CDN cluster.=C2=A0 If you use a DNS resolver th=
at is off-net, you may sometimes be sent to a CDN cluster off-net.=C2=A0 On=
e way that some public resolvers deal with this is by implementing ECS (RFC=
 7871) whereby they send a subnet to the authority when resolving.

=C2=
=A0=C2=A0=C2=A0=C2=A0 Erik




--00000000000036c63e0585422648--


From nobody Fri Mar 29 16:43:39 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B289712040A for ; Fri, 29 Mar 2019 16:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, 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 (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 f8FFItOH54MS for ; Fri, 29 Mar 2019 16:43:35 -0700 (PDT)
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 09A1E1204BD for ; Fri, 29 Mar 2019 16:43:35 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id u15so3564636otq.10 for ; Fri, 29 Mar 2019 16:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UUHkQ29IB7XH/TbwR4U3sFj3j73prlsnaDwcJOxqvmU=; b=t9WJMwMz0obJjaFpfbVab8Qh+bKV322ukj+mL/HH61Pvg8C3Dyhrte0IJwOYuwnvWo 0o6KDFUKWl/zbYDRD2+Vhc6VQF/qUjYNwQqecT/RwizuYY1xFo4h7owQJOBXfaWgJEie DqVWu0s0u3WdTizfKx9f+27n1T5U0cv8OgABEAZhy8N8S9RelK8GoMU5RYUsGnFRgzk6 rUygConufCscRAq7fioucGLSHqx4wOM0Ox7re6brs2lLTVzKI93SZyRIeNJ5SgNuLZpf DwIfuNIQ+N+S0cULwRRfHXLOjsh/cFkVnj9tVudlbswKI5CjifNlBvaF9ACxWs3keI4K /iwQ==
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=UUHkQ29IB7XH/TbwR4U3sFj3j73prlsnaDwcJOxqvmU=; b=sgt5G46KxW+cfL+VmfBfazMh3+316RghXPolFqrmCsBQVI5+HiIyb7p4qkGacAmVH2 WMLXXD/SuSkPoU4IYnHTbnN6NuISGCML7qj6VzPfACgYzRzpCH1TWgJ8nczr+OrqqvM5 NQ0ysPZgUQL3h1x5VTdxG30GJZ3nfQW7GXKW4HDhfd5WkRgyW7IghLlXty8uRipdTd7M tUH8KwK4kch7c6gIBwlz7abY/oHwnfHMDLd/uiPCkwizCS0v7MJ0xFoOmGGItdmrAHxT YcYBvc/xO+HGvsHLC2tGl1Ngg9fbrRmWbiv9gDGCR7QruCLbA8WNn8sw16SO59wYu8n3 c1Uw==
X-Gm-Message-State: APjAAAVIwz/nYO2WOlGWN2oBcOJwSrYgy5Anq+5Ys99yb/35SBERk4W5 gptmHVkxY2Iq9cHnFs8tREwUTrOkATASJiqmPPE=
X-Google-Smtp-Source: APXvYqz/ch1tdLn8dGEBj8FFj91NDGuKsScV7z/YUFz0h4fLsbImzxWnLgjMUW7oQlUVVTnTG2/NcJwK+zXdwnlgoos=
X-Received: by 2002:a9d:7095:: with SMTP id l21mr37560654otj.35.1553903014060;  Fri, 29 Mar 2019 16:43:34 -0700 (PDT)
MIME-Version: 1.0
References: <155352271867.29069.14575634631344292386.idtracker@ietfa.amsl.com>     <0153779E-91C8-4D9F-9454-CE44E2E9A9A8@gmail.com>
In-Reply-To: <0153779E-91C8-4D9F-9454-CE44E2E9A9A8@gmail.com>
From: Mark Smith 
Date: Sat, 30 Mar 2019 10:43:21 +1100
Message-ID: 
To: Fred Baker 
Cc: v6ops list 
Content-Type: multipart/alternative; boundary="0000000000002b27f30585443dfc"
Archived-At: 
Subject: Re: [v6ops] Default DNS Server
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Mar 2019 23:43:38 -0000

--0000000000002b27f30585443dfc
Content-Type: text/plain; charset="UTF-8"

Hi Fred,

On Fri., 29 Mar. 2019, 16:57 Fred Baker,  wrote:

> On Mar 28, 2019, at 5:11 PM, JORDI PALET MARTINEZ  40consulintel.es@dmarc.ietf.org> wrote:
> > 1) Mikael mention that Chromecast (and other devices), use a manually
> configured DNS such as 8.8.8.8.
>
> This is a different comment than Jordi's topic, but I'm of the opinion
> that the use of services like 8.8.8.8 by default overrides what might be
> local policy. I'd really like to see such things use 8.8.8.8 (or 1.1.1.1 or
> whatever) only as a backup in case the network didn't tell it what DNS
> server to use.
>
> Reason: if nothing else, the device might be used in a network that has
> local services that need to be accessible. Google is well informed, but
> even Google doesn't know everything, and specifically doesn't know about
> such services. To me, this design decision borders on arrogance, and
> certainly isn't about enabling user control of the services they use. Net
> Neutrality and all that...
>



The trouble Google would have with retail consumer focused electronics
products like the Chromecast is that non-technical customers will likely
attribute all faults, whose effects appear on the device, to the device and
its maker, in particular if those faults occur when the customer first
tries to use it.

So if an ISP is running badly performing or unreliable DNS resolvers that
impact Chromecast performance visibly to the customer, or the customer's
CPE's DNS resolver is badly performing (which wouldn't be a surprise given
how low end their CPUs can be, and how limited their memory can be meaning
limited DNS caching), customers are likely to attribute blame to Google and
the Chromecast, rather than the ISP or the CPE that is the actual cause of
the problem.

So I think Google running and preferring their own DNS resolvers to try to
better ensure their product provides a good customer experience makes sense.

I suppose they could have instead tested ISP DNS resolver performance and
put up an error message to say "Call your ISP or replace your CPE because
DNS resolving performance is bad."

Lodging a fault with an ISP and waiting for it to be resolved also isn't a
good customer experience, and it may not have occurred to them when they
developed the Chromecast because they already had a reliable and well
performing DNS resolver service that they operated.

Google are now also running public NTP servers, I wouldn't be all that
surprised if they've gone to that expense for similar end-user/customer
experience reasons.

Regards,
Mark.




--------------------------------------------------------------------------------
> The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--0000000000002b27f30585443dfc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Hi Fred,

On F=
ri., 29 Mar. 2019, 16:57 Fred Baker, <fredbaker.ietf@gmail.com=
> wrote:
On M=
ar 28, 2019, at 5:11 PM, JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:

> 1) Mikael mention that Chromecast (and other devices), use a manually =
configured DNS such as 8.8.8.8.



This is a different comment than Jordi's topic, but I'm of the opin=
ion that the use of services like 8.8.8.8 by default overrides what might b=
e local policy. I'd really like to see such things use 8.8.8.8 (or 1.1.=
1.1 or whatever) only as a backup in case the network didn't tell it wh=
at DNS server to use.



Reason: if nothing else, the device might be used in a network that has loc=
al services that need to be accessible. Google is well informed, but even G=
oogle doesn't know everything, and specifically doesn't know about =
such services. To me, this design decision borders on arrogance, and certai=
nly isn't about enabling user control of the services they use. Net Neu=
trality and all that...

<=
/div>


The trouble Google would have with retail consumer focused electronics =
products like the Chromecast is that non-technical customers will likely at=
tribute all faults, whose effects appear on the device, to the device and i=
ts maker, in particular if those faults occur when the customer first tries=
 to use it.

So if an ISP=
 is running badly performing or unreliable DNS resolvers that impact Chrome=
cast performance visibly to the customer, or the customer's CPE's D=
NS resolver is badly performing (which wouldn't be a surprise given how=
 low end their CPUs can be, and how limited their memory can be meaning lim=
ited DNS caching), customers are likely to attribute blame to Google and th=
e Chromecast, rather than the ISP or the CPE that is the actual cause of th=
e problem.

So I think Google running =
and preferring their own DNS resolvers to try to better ensure their produc=
t provides a good customer experience makes sense.
<=
br>
I suppose they could have instead tested ISP DNS=
 resolver performance and put up an error message to say "Call your IS=
P or replace your CPE because DNS resolving performance is bad."
=


Lodging a fault with an ISP a=
nd waiting for it to be resolved also isn't a good customer experience,=
 and it may not have occurred to them when they developed the Chromecast be=
cause they already had a reliable and well performing DNS resolver service =
that they operated.

Goog=
le are now also running public NTP servers, I wouldn't be all that surp=
rised if they've gone to that expense for similar end-user/customer exp=
erience reasons.

Regards,
Mark.





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

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



_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listin=
fo/v6ops






--0000000000002b27f30585443dfc--


From nobody Fri Mar 29 17:28:20 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BF112002E for ; Fri, 29 Mar 2019 17:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQorXC_3ghtQ for ; Fri, 29 Mar 2019 17:28:17 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AA5120033 for ; Fri, 29 Mar 2019 17:28:17 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id bf11so1742389plb.12 for ; Fri, 29 Mar 2019 17:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=BKzkuNiw1JNzzvmv7hkNR5KxyoBVg83y/9YV4vmGRzQ=; b=Kjf5Gy8oQm/hLAYwv6W5liHN1VRtVYk0jR1ZWnSxV1yjPY9BGRQNyODtcmqsnvwCQx Y5YT8VkRt8q2gLlqU8uZs31y49gtZht86fRox3YnKBD230MvoXcH2Jy1pdtN7DNyWxR3 8i631JkQoC7v+om24y5dC6zy7MpFDwgTM3BSMu+j0Jvw9nwGtMXge+zB/Mm6Zqfarhow GKxJke9wFTifJocJCC2+76/b9iuKT33M3bCbSAg9OPd7ThOLHz3+hfdwIlhewQZCKtP0 FPeSyf0aa4GIzi4QCTOfPGXMNRqOTpw8GEAeujFbj6A8kY+UeyyLGc6veZIxALvLSJKz RmgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BKzkuNiw1JNzzvmv7hkNR5KxyoBVg83y/9YV4vmGRzQ=; b=juiSfhnCgNbqYUeMmVwES449W1w1NT9rRiYCD7+iTLAqoatkqWEmuOLwvnao2BU/IO IsITy25NF+dpwCotC8lzCqqe4FayrL8Xwgn9yWw7jioQi7p8V/vv3Txs4uoLbmEWDvi5 aWhNbzs3xrIxYOGCthJBTCmtZ3MWPr1Kln/SAqs9K3CNFSMvMMPfimVcVZuAgtNZVscL krO3mrbjyeQ2Y3TVkAnea4poHDlGz82zQtyZu5i1gnvtPvQeLXTZG3vFU2ZzZN45BN9o lzs5fczFQoYXiPyydfW20zIba9I2VB1PPJDFlNrGP1fVQtqxThcg0z7hCiTxuCM3F+C3 rhjg==
X-Gm-Message-State: APjAAAX1e/7jiXdMyLEnKhgaU1JCBk8eIPdjJk9NTPF5zwJbAEVOGih7 CPlEaxx2UmPV6PhcguUu3kCUKH2T
X-Google-Smtp-Source: APXvYqyOY+ZD1Tq/eSsJliw5NluyRcIrEE29jolxixK05/L/h7cwBIx3yEKgYbFnLbvkWjxDdCxsyQ==
X-Received: by 2002:a17:902:2a0b:: with SMTP id i11mr51540521plb.324.1553905696621;  Fri, 29 Mar 2019 17:28:16 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.95]) by smtp.gmail.com with ESMTPSA id g67sm5507799pfg.94.2019.03.29.17.28.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 17:28:15 -0700 (PDT)
To: Fred Baker , IPv6 Operations 
References: 
From: Brian E Carpenter 
Message-ID: 
Date: Sat, 30 Mar 2019 13:28:13 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Mar 2019 00:28:20 -0000

Well, first I'd like to understand why Terastream decided to use address bits
to convey these semantics, when diffserv was designed for this exact purpose?

Frankly I'm not surprised that using address bits in this way leads to
problems.

Regards
   Brian Carpenter

On 29-Mar-19 18:37, Fred Baker wrote:
> https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastream/, slide 5
> 
> What do we want to say on this issue? Mikael mentions draft-ietf-intarea-provisioning-domains; in this case, I think I need to send a note to the relevant authors and chairs asking them what the prognosis is and expressing operational interest. First, is there a consensus to do that? Second, do we have additional comments to pass along? Our comments might be adequately summarized by forwarding a link to this thread, or might rise to the level that needs to be discussed in an internet draft in v6ops. Comments?
> 
> --------------------------------------------------------------------------------
> The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Fri Mar 29 17:31: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 E11F512006D for ; Fri, 29 Mar 2019 17:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNnkH_G0SNzK for ; Fri, 29 Mar 2019 17:31:07 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 4D79B120059 for ; Fri, 29 Mar 2019 17:31:07 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id b11so1751389plr.7 for ; Fri, 29 Mar 2019 17:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dtCS60HefJswLmJyupymWhuZpXdcWquSbpmhOBP/KZA=; b=Uf5aTA8vMRgmre/WlkJmQ3l4Xq/qd25Th7clyWrmG+BUZ9layBcM4xtT0fxBNBPz3B AoIVDEX1V3Ak9YuARJOi65K1qGMxqJDqvS9ART2BfBrxKJtlMN2gOakEQfiX+74niY6K RLihKGVuSE9Rbc502YFbYj1xBibNqn8hx8eEnLSA245d6Th+Yozzb2nGqJCNIuMcx42F 9ms5+aweuBBMaejILRWw+1iePPbsHAqt2MPoyTDVnmmqTDWylcewrsNs27plnAjIH1cv pHXiA7UUWudhWx/IJiylQcg33PFD14SGjU0rCaV1Ldp9WB0PwaPregc2aY3Rd4t+c5Ug oiTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dtCS60HefJswLmJyupymWhuZpXdcWquSbpmhOBP/KZA=; b=b27HFCI+ppX/5rLl1UBwKHzV714gZKsDsjAvEOH3ede+DTC0gPzggyy9bmnWK40iR7 AI7AsENrFOf/jkWUQdQ/QeNTVi1K6J7vRK0+7AU3iQV5sPQjJfMvUrZvxEecq9ID7oVV XBci8mfMMgzP3IL+zbF6VeRHxhA1cXumdKPSqWzIghe6CXP4E0h0IrMBPo2/OBaMtP2V wyXC5R5NSzq47MLI/ZpDAORnGrZzNm103TdMUs6lBOPxE88LwGcTCQGnN4NutFpQ+u0P d4JrKsPOr65LhilzxOMGyNG0/cZftZ1T8ftKe0Iuh9JIIg3dQw6eZSegef8gx+74Fk43 Hx4g==
X-Gm-Message-State: APjAAAViY5t5KiQ1VXbgB+zONdhAMq4vdy+pVozn1skypDLVBH0cl4nt LXN83X1ciha/MW6s8yT60/9Fly1Q
X-Google-Smtp-Source: APXvYqygqLhAiMwRDauG8yOX1KRc1xbPPwG2LYNez56Pfsgg2hk0HdWQQz50Co3hO79VyuXu4GgpJA==
X-Received: by 2002:a17:902:28e6:: with SMTP id f93mr51919958plb.264.1553905866694;  Fri, 29 Mar 2019 17:31:06 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.95]) by smtp.gmail.com with ESMTPSA id c130sm6092833pfb.145.2019.03.29.17.31.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 17:31:05 -0700 (PDT)
To: Fred Baker , IPv6 Operations 
References: 
From: Brian E Carpenter 
Message-ID: <29ad0e7d-79be-8612-84e5-ffb10eb78e27@gmail.com>
Date: Sat, 30 Mar 2019 13:31:03 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Multi Attached Data Center Host configuration
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Mar 2019 00:31:09 -0000

Another question before starting to discuss: would this problem be helped by universal deployment of https://tools.ietf.org/html/rfc8028 ? And if not,
why not?

Regards
   Brian Carpenter

On 29-Mar-19 18:37, Fred Baker wrote:
> https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastream/, slide 6
> 
> What do we want to say on this topic? There are a number of screwball interactions, and vendor product seems to vary. This seems to call for an draft named might call for a draft draft-ietf-v6ops-operational-thoughts-on-multi-attached-hosts-in-data-centers or something like that. Is there a person or set of people that would be interested to form a design team around that topic?
> --------------------------------------------------------------------------------
> The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Sat Mar 30 01:07:28 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23C9120188 for ; Sat, 30 Mar 2019 01:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWE8IgZ48xRK for ; Sat, 30 Mar 2019 01:07:24 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879CC120183 for ; Sat, 30 Mar 2019 01:07:24 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E9687B1; Sat, 30 Mar 2019 09:07:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1553933240; bh=oA+iQ8Qt0w9yEsC8tedgLq72/iNkJYdDFR0xDE5HmAc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Itp3G/erzsKHtDh7NLln7Dn5aIZilLqGvnZjHXkJr+5VLy8f/dnLoG96ZIGrL+jiy mAfln1KKzjBun2MDWKl+J8fJT/i0bg2ULigUpH6lyXAL7bjc1gclE5g3I3ZmKaPbH7 6SVcRXekgF5A0tXtzxJGCCyzzZWR6HZ4BXwKWiqw=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E59D4B0; Sat, 30 Mar 2019 09:07:20 +0100 (CET)
Date: Sat, 30 Mar 2019 09:07:20 +0100 (CET)
From: Mikael Abrahamsson 
To: Brian E Carpenter 
cc: Fred Baker , IPv6 Operations 
In-Reply-To: 
Message-ID: 
References:  
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] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Mar 2019 08:07:27 -0000

On Sat, 30 Mar 2019, Brian E Carpenter wrote:

> Well, first I'd like to understand why Terastream decided to use address bits
> to convey these semantics, when diffserv was designed for this exact purpose?

It doesn't matter exactly what we call it. Think of it as "walled garden", 
"network policy" or whatever. It all results in the same thing. It's more 
than what diffserv does.

> Frankly I'm not surprised that using address bits in this way leads to 
> problems.

Please don't rathole on the diffserv part of it. The problem space for 
"VPN" etc is the same.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sat Mar 30 13:00: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 4844E120269 for ; Sat, 30 Mar 2019 13:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lLzp7opiC_u for ; Sat, 30 Mar 2019 13:00:32 -0700 (PDT)
Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 75CD112021B for ; Sat, 30 Mar 2019 13:00:32 -0700 (PDT)
Received: by mail-pf1-x443.google.com with SMTP id 10so2613517pfo.5 for ; Sat, 30 Mar 2019 13:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SiGGE0xjCaxbRB9BDJ01uJ4V0KOWMmqM14x5sj18kMs=; b=sfV9GzP2LQ2wvSryc1UQ/VRddoShK+JN2pqF8VWgUOHzp1xINexmyysXmGHtPM+A4L PES9LzuqihtP7h8dEFAWyxIiCdzmZ9TS2SzBqXcuK2Q864JOB8H4qMDJzLLJGtr4EvIJ iE6u5Ngpfo0YCdXGE++8FSxo1az9dV5NSzZA1/dwroNRb9yeyy5oDj0ka0rcBwMmur+E 7fhEZIQRtCXMXf4q9es2bT3Q5yk0G+r5hcw8mIuG+IQsgx4WGYPC1a9f+EyAuYb9qeHy +GwHUt0ErmWORS98yfDFffdRbdO2KBbPZ7wKz5PA/nNO4efwxgUcL1MhPN1C56hc/sNR rKEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SiGGE0xjCaxbRB9BDJ01uJ4V0KOWMmqM14x5sj18kMs=; b=S1bNJyTNC2IA1D2RGaLewHNUxxMpsJyjZfsb3jcQgI4Z6ezv0MUbo4cgVngNT6pcde iWRRVl5os4MbfAR3cxhzAgUwMB22tMmSzfVKQc06T33yU7/O9YALJiV56Ae4GvS/tP4H FUaa8KPku6vj5Jp2syx4nYlY0slZMJzgt/2ENS+ybBsHCljJ3Vtyw/3pZujTo+wOJhmy GxBTAaryH7ZmDrWYmLw2V08Exlm85aaKDqPq0XvKokd+Yzqy+9Tfg6v7WVIGxby4bNAq ckXncFEO3z00lycNHPVJGPf+WmgHpf1dPVkVx37vS6Avco7LThzRRJRqoSb5IgSZ5Nza TyYQ==
X-Gm-Message-State: APjAAAVIDk3pl3JPln0nm34eMP24082aoBHK649Vymw7Y7PtStILl0Jy JQICxM6/8TKbS4Jh7w/rZTvjbU6j
X-Google-Smtp-Source: APXvYqxvTTS4/TMBhnR7kgtUbADvb3WQOnm19V1GXo1eJi6grEohL3KwB09tGH8w3EkcJ7kB9y1t+g==
X-Received: by 2002:a63:2158:: with SMTP id s24mr43898498pgm.156.1553976031702;  Sat, 30 Mar 2019 13:00:31 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.95]) by smtp.gmail.com with ESMTPSA id r10sm8367330pfn.188.2019.03.30.13.00.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Mar 2019 13:00:30 -0700 (PDT)
To: Mikael Abrahamsson 
Cc: Fred Baker , IPv6 Operations 
References:   
From: Brian E Carpenter 
Message-ID: 
Date: Sun, 31 Mar 2019 09:00:29 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Mar 2019 20:00:34 -0000

Hi Mikael,

On 30-Mar-19 21:07, Mikael Abrahamsson wrote:
> On Sat, 30 Mar 2019, Brian E Carpenter wrote:
> 
>> Well, first I'd like to understand why Terastream decided to use address bits
>> to convey these semantics, when diffserv was designed for this exact purpose?
> 
> It doesn't matter exactly what we call it. Think of it as "walled garden", 
> "network policy" or whatever. It all results in the same thing. It's more 
> than what diffserv does.

Yes, but that doesn't really answer my question. What does this do for you
that diffserv traffic classes don't already provide?

I see this in your slide:
> without needing DPI for setting TOS etc.
In an ideal world, you need the host to do that. But in any case
your requirements seem to need significant changes to the host stack,
especially to support PVDs.

Note that I am not not denying the requirement for localised behaviours.
Please see https://tools.ietf.org/html/draft-carpenter-limited-domains .

>> Frankly I'm not surprised that using address bits in this way leads to 
>> problems.
> 
> Please don't rathole on the diffserv part of it. The problem space for 
> "VPN" etc is the same.

If I'm ratholing, it's on the use of address bits to carry traffic semantics.

   Brian


 


From nobody Sat Mar 30 14:12: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 8E5581202A7 for ; Sat, 30 Mar 2019 14:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiOf2rOq0WCU for ; Sat, 30 Mar 2019 14:12:48 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C21112027B for ; Sat, 30 Mar 2019 14:12:48 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 781DAB1; Sat, 30 Mar 2019 22:12:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1553980365; bh=fO2jHbI39n3drsVpqpFFP1rt3v73OEJLz9YTPSteC7M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WcNVX0TshUjJrWNbosn2wqiZZ4xgTfrgSWwHOaCtN8WzZNwMmsQJAqnuW1klCfYWU nMFoqsQuL7JOayQMBXyG3mKga4+2Gum2OTIL4u+Ocxef1/FYtIW3/2UEgE80qPP57a BADO3soi85MoTYfsWhM39ZiZ8wEXCn1KVEGVQTkw=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 743AFB0; Sat, 30 Mar 2019 22:12:45 +0100 (CET)
Date: Sat, 30 Mar 2019 22:12:45 +0100 (CET)
From: Mikael Abrahamsson 
To: Brian E Carpenter 
cc: Fred Baker , IPv6 Operations 
In-Reply-To: 
Message-ID: 
References:    
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Mar 2019 21:12:50 -0000

On Sun, 31 Mar 2019, Brian E Carpenter wrote:

> In an ideal world, you need the host to do that. But in any case your 
> requirements seem to need significant changes to the host stack, 
> especially to support PVDs.

I don't understand your apparent opposition to PVD support. You might 
consider our use of PVD strange, but that doesn't invalidate the other 
use-cases for PVDs.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sat Mar 30 15:56: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 E48A1120322 for ; Sat, 30 Mar 2019 15:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F03WReW5jdI for ; Sat, 30 Mar 2019 15:56:20 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C8212031E for ; Sat, 30 Mar 2019 15:56:20 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id y6so2685883plt.1 for ; Sat, 30 Mar 2019 15:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2VVTDJRl2NRU8VhJT7jPnSjcYnVJNcsU3EF/64/d0Ig=; b=PrVKj+PqTv6vCnuq0l7h3ddLL69LNZ4L93T64o3615mmHaW7mMvRruNodYnE+xtQMS CSgwnIjEjP0/N0w4qL1c3jlAxfbOSRO/+9+Z/BKFwvXSoWMovZ3+kAt/+E42j7H5ryJE edlBLah0JwuKT+fyeVXyLsJKgvcZr21I6XRcCZyeGOIeQaTrQRcl2u6Lf5S4IGjiYPHu uVwJu0CgzUBoBcLYdJ6SdIkecgzZ6FAxVa5qGqitp+iYqqH3aNpnZDfEmBVo/uNBQYvZ Fpp71jGexgz8bTHOUuK2GraPgDfNcZtcS+8kZnjqN4x7OaqkmfBLyWx2NwH9E4WaDMzN DVCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2VVTDJRl2NRU8VhJT7jPnSjcYnVJNcsU3EF/64/d0Ig=; b=dKUN3Rxot0HdmbcNv5zrYBp+gxAY8bxlFN7cTPafHD3kyB+49ahdiqKBxkqYOhn0Jw cORbFOudPNC3S+Ijdn1WIiOvcYUYa/Qtd4TTgmFtPj59RxXwYjigV7+MW7iWua3LsBXQ KQiUH9/d4d/6KZCQFwE2DWDD/G3DfKcZDvrZd6VT1zHIHtZf4VoLcn+nlYg/MEJtzeMR V+zgzadntZku30xSDEKzdOv0n2Z8j4piXXFgZbWCHCau+DoqFlMJWhv7fwexBifkCvR2 yWYoX3e7ZRxhJySbRVDD1cCcLbbtRKWczp0dpkFf+PC3SeF/UMuyluQf6c8+uT/JGwVN +nQg==
X-Gm-Message-State: APjAAAXr3wb4l2UmalFCNVXwGV1ixWSuFydH0xBSoJQW6Cdq/kh1X3qa BlYocwuzOZAi5Tre10ScX/jaTfao
X-Google-Smtp-Source: APXvYqxjvSpTrz76E0iB5h3l9ADmoOGOTPG7B6C0OfhMgFdmUX0W+oYHBAuQo0jYHeSGdNjADRI4Ig==
X-Received: by 2002:a17:902:7896:: with SMTP id q22mr57807962pll.66.1553986579956;  Sat, 30 Mar 2019 15:56:19 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.95]) by smtp.gmail.com with ESMTPSA id r10sm8624179pfn.188.2019.03.30.15.56.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Mar 2019 15:56:18 -0700 (PDT)
To: Mikael Abrahamsson 
Cc: Fred Baker , IPv6 Operations 
References:     
From: Brian E Carpenter 
Message-ID: <92e28c87-5c05-af81-8258-64c3bca9be78@gmail.com>
Date: Sun, 31 Mar 2019 11:56:16 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Mar 2019 22:56:23 -0000

On 31-Mar-19 10:12, Mikael Abrahamsson wrote:
> On Sun, 31 Mar 2019, Brian E Carpenter wrote:
> 
>> In an ideal world, you need the host to do that. But in any case your 
>> requirements seem to need significant changes to the host stack, 
>> especially to support PVDs.
> 
> I don't understand your apparent opposition to PVD support. You might 
> consider our use of PVD strange, but that doesn't invalidate the other 
> use-cases for PVDs.

I didn't say I'm against PVDs. I just said that they need widespread
host support to be useful. (As does RFC8028, to alleviate some of the
problems even without PVDs.)

By the way, there was this a few years ago:
https://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix
I'm still worried by using bits in a GUA prefix for essentially
semantic purposes. I fully realise we have a large supply of IPv6
prefixes. But mixing addresses and service semantics just seems
very likely to cause problems sooner or later. I'm sorry, that
reads like FUD, but that's my feeling.

    Brian


From nobody Sat Mar 30 22: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 E0C4312014A for ; Sat, 30 Mar 2019 22:04:04 -0700 (PDT)
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 ujG2b_UxoLKX for ; Sat, 30 Mar 2019 22:04:02 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC16120142 for ; Sat, 30 Mar 2019 22:04:02 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id AD6CAB1; Sun, 31 Mar 2019 07:03:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554008639; bh=QKUTuLWOmrwwF5nOwA3NqI/uMVSZ7SrCpo8yUlU2moY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ufbCrlj1/9rMAer6SS3WKfV4lsENQqfnCT5qdSBno+wzjX0ODthEKEtexKYZ6NuEi p/8qdmk9y1HfTZshy1asVAcDO6170oEbZgErkATmMq/QYwVMuPUMs3E9Wi+Nsowc8G tBT9g/v+yILs8MoeLkT9KLMsu1foWOLteNmksM0g=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AB5C3B0; Sun, 31 Mar 2019 07:03:59 +0200 (CEST)
Date: Sun, 31 Mar 2019 07:03:59 +0200 (CEST)
From: Mikael Abrahamsson 
To: Brian E Carpenter 
cc: Fred Baker , IPv6 Operations 
In-Reply-To: <92e28c87-5c05-af81-8258-64c3bca9be78@gmail.com>
Message-ID: 
References:      <92e28c87-5c05-af81-8258-64c3bca9be78@gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 05:04:05 -0000

On Sun, 31 Mar 2019, Brian E Carpenter wrote:

> By the way, there was this a few years ago:
> https://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix

Yes, my colleague Ian Farrer is co-author of that document.

> I'm still worried by using bits in a GUA prefix for essentially semantic 
> purposes. I fully realise we have a large supply of IPv6 prefixes. But 
> mixing addresses and service semantics just seems very likely to cause 
> problems sooner or later. I'm sorry, that reads like FUD, but that's my 
> feeling.

I share your concern and this approach has to be done with care. However, 
it's not uncommon for operators to have 3-4 different vlans to the HGW to 
separate services video/voice/management/Internet. This basically does the 
same thing.

We also use diffserv to do some PHB differentiation within the same 
prefix.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sun Mar 31 03:06:23 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2E120183 for ; Sun, 31 Mar 2019 03:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcx1_MkxJZWG for ; Sun, 31 Mar 2019 03:06:20 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 F3AB712017F for ; Sun, 31 Mar 2019 03:06:19 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id a25so5573104edc.8 for ; Sun, 31 Mar 2019 03:06:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aNF+T32kHuONnWUnrOmLb3o92dfMcJl2KAgW0JLtl5g=; b=swYkphdNovOGBjqV+K9Z4CBkJByragYqQg7XVmbrgOx3yYXjqVFhJ6gk3GpxA/r0Dj suXBGGPxTrmRSYi2VBcF10aevcOEOPH0ICLUIDqZi0L+63VSK9m4oAGt1gawg7foB+Q5 66TLSOVfivANM/rnDjOGYWmnqmNES1EfrirPgBMmvctd3YamzFO1vgT+bvaWC/ls8fo1 bnnWjBfoSTJT96qin7/9IIfZRuhLrJBTZAaLtjy7EJLL3sOJiUB0BePH0TE4sbgew94l EVgK3JE4E6PSXGy23cxUjgijS0onRqsXTumWKSO3gC7yXCcILdzgIlNKD13owtgaM9Fi RRaw==
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=aNF+T32kHuONnWUnrOmLb3o92dfMcJl2KAgW0JLtl5g=; b=KizbqKcKDNB+gIItdtAcsDMV/dfXNVnJE9gIow3G24+QISZmrG7IBrlwHBuRzuKXs9 nouELz4EP2PkBVkT48nhkjzlJXMnddfg0mrHkj7HY6Gs7bqdmaZymi6Wdm58QYXmofSm ujWfluq4JAofFvs9t3KH3z9TesyF8jHuNINX65vpC1A9c5EU2mjc1qNJDrbXZNTtn7hH ym/loraXKUfbv9xTkvSyPZqH62Du2milkYw1FvmxcRIr9OMeqCdFcytB2FL3Gw7A3034 91yibljOpBHF87QWdkViPw02vo81LHFpyIfHJOX/ey/7lZQE9swRLwuZbDZQxrrEhfzt Ad2A==
X-Gm-Message-State: APjAAAVFlGT2+VBEoYCqfGox4BIJ8UJr0lJm6UMlART95AVFxPEnv0oT MWibSCqVy9FIzqKsJW1CBeE=
X-Google-Smtp-Source: APXvYqwJ5sWvKyXyANk6f8P9//pZHEdtx3uNHTR9Tj0s6kGyeghEYZfpoHDjpwK4Bx8e7OO21kPtLQ==
X-Received: by 2002:a50:a4e4:: with SMTP id x33mr17977968edb.61.1554026778591;  Sun, 31 Mar 2019 03:06:18 -0700 (PDT)
Received: from 245.66.20.149.in-addr.arpa (245.66.20.149.in-addr.arpa. [149.20.66.245]) by smtp.gmail.com with ESMTPSA id v7sm2153974edy.45.2019.03.31.03.06.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Mar 2019 03:06:16 -0700 (PDT)
From: Fred Baker 
Message-Id: <09B9AD86-B21F-4A9E-A6A5-A06FB361BF17@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_8AD8A988-4902-446A-8926-DA0D11558E49"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Sun, 31 Mar 2019 12:06:11 +0200
In-Reply-To: <92e28c87-5c05-af81-8258-64c3bca9be78@gmail.com>
Cc: Mikael Abrahamsson , IPv6 Operations 
To: Brian E Carpenter 
References:      <92e28c87-5c05-af81-8258-64c3bca9be78@gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 10:06:22 -0000

--Apple-Mail=_8AD8A988-4902-446A-8926-DA0D11558E49
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Mar 30, 2019, at 11:56 PM, Brian E Carpenter =
 wrote:
>=20
> By the way, there was this a few years ago: =
https://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix I'm still =
worried by using bits in a GUA prefix for essentially semantic purposes. =
I fully realise we have a large supply of IPv6 prefixes. But mixing =
addresses and service semantics just seems very likely to cause problems =
sooner or later. I'm sorry, that reads like FUD, but that's my feeling.

No hats

That, BTW, was the reason I pushed back on Jiang's draft, and I have the =
same fundamental question about Terastream's use case. I understand both =
concepts to essentially say something about what address one uses for an =
application; putting it into the address has the characteristic of =
ensuring that the same set of bits is present in the packet end to end, =
which differs from DiffServ. It basically allows DT to make an end to =
end service, and change the IPv6 head to support it, with actually =
having to change the IPv6 header. It affects, or can affect, routing, =
and as I understand it required DT to allocate a truly large prefix. I =
find myself wondering - what if this were general? Everybody was =
allocating /24 or larger prefixes to get the equivalent of a DSCP to be =
usable end to end? The fact of asking the question seems crazy, but at =
some point, that seems to me to limit the availability of IPv6 address =
space. Is that a rathole we want the network to go down?

Just me worrying.
=
--------------------------------------------------------------------------=
------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu


--Apple-Mail=_8AD8A988-4902-446A-8926-DA0D11558E49
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+AFAlygkRMACgkQEhdRnd2G
P+A4xw/+NDLRipD7rakpyf/q9CXczvNVwcSHJn62G5Pkbavybzn1hv18sxhWJPl4
WVWnppSwzkuVkdEcj7qlOYB06JTaEAl7A4xMxyNupHDFrEGyef4RcAaONKBFeD/d
kPHJkfDq3A8W7j6GowXkTiw3E9w2Xfjgd7XshAXTsRwK6TKjX2I4UTXftAYYeVBK
B8qyqchUEilxd5dvyWXRrK0Kj6SqKHi+oYvUQMD5Lv7ywjh4cxyjzfJg0A69QlEP
559iM9AM+y53Prnt2nFXoMpzUmsGdA7RaKJQgjvKvc2M2vrlMwlkDPbhckd6al6g
nBavxktEq695KSeSgtmgxdsUecFbI8jx7hRZHlU5nBkzxzHB+L0ayyAhZ0rs+414
Ifhc1DyNXQFyVssBDvoXLr0aVxR+l4xA/OJDbEH46KzJksT5kK6QaLAK18bZpsDU
/GupqdOWOS8uClcmL5rhcd+e/2I5yJ8euRS5ytv1ZEb49Y7pdVebHvHmnbNH4A3Q
Rh9byq0t6h+d1V56kiErwDJZF5hINmX3ALN8R0aNqeUD0FrNcCEN8z+5MKW7Qbml
Va0JhxjOYxKpmCGYzmSt2NRu3bIC2vIPMsxGJbxtK06/INgUX6979aJVvJ0DWVFI
arU+tymBGKx75AbFgpcsc0hlbuwCwMMJ7mbxuhjkMI5v4m3V7xo=
=jKOl
-----END PGP SIGNATURE-----

--Apple-Mail=_8AD8A988-4902-446A-8926-DA0D11558E49--


From nobody Sun Mar 31 03:23: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 7FE8A120180 for ; Sun, 31 Mar 2019 03:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 7ZTCFKhNUQyk for ; Sun, 31 Mar 2019 03:23:44 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E80112017B for ; Sun, 31 Mar 2019 03:23:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1554027821; x=1554632621; 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=L6yy3YC1 pndvuti4Dvjp8pJzGzlQvcbs2pIe/CYBgOY=; b=cO1E0UlEdMfbxja8zKjnPRdW SCLOWtfAgYbXrV73gB3UX7I9KP5/WTga5VA9rJoNxMQB1yYpR6dGS38AsHfHXJqZ c1hJmPY5BKnET1yNUUrLdduUdf3TO9p1MB/P6TUqH3F0FO8xFVWlklBQ00lXdt0n sBsTY7TIlAJlatlrb14=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sun, 31 Mar 2019 12:23:41 +0200
X-Spam-Processed: mail.consulintel.es, Sun, 31 Mar 2019 12:23:41 +0200
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006204160.msg for ; Sun, 31 Mar 2019 12:23:39 +0200
X-MDRemoteIP: 2001:470:1f09:495:d1bd:2e0c:ec3a:b6b8
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Sun, 31 Mar 2019 12:23:39 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1993a37826=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Sun, 31 Mar 2019 12:23:35 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Operations 
Message-ID: <87852798-A428-4434-84FF-239276D120A6@consulintel.es>
Thread-Topic: [v6ops] Operational Headache: Provisioning domains
References:      <92e28c87-5c05-af81-8258-64c3bca9be78@gmail.com> <09B9AD86-B21F-4A9E-A6A5-A06FB361BF17@gmail.com>
In-Reply-To: <09B9AD86-B21F-4A9E-A6A5-A06FB361BF17@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 10:23:46 -0000

If we have a way to say (just examples, in a common case):

1) This residential user gets this /48, assigned with DHCPv6-PD
2) The 1st /64 is reserved for the point to point link, WAN port
3) The 2nd /64 is for VoIP in VLAN 2, Eth2
4) The 3rd /64 is for IPTV in VLAN 3, Eth3
5) The 4th /64 is for x in VLAN 4 ...
6) The user can use all the others (automatic LAN numbering), Eth0, WiFi, e=
tc.
7) The CE recognize it

We could achieve that, I think, in a much easier way.

RFC6603, I believe (need to re-read it), only allows 2) above.

Does it make sense to work in an updated version of RFC6603, probably using=
 as well some of the text in draft-palet-v6ops-p2p-links (which I'm going t=
o update anyway), instead of two different documents?

Regards,
Jordi
=20
=20

=EF=BB=BFEl 31/3/19 12:06, "v6ops en nombre de Fred Baker"  escribi=C3=B3:

   =20
   =20
    > On Mar 30, 2019, at 11:56 PM, Brian E Carpenter  wrote:
    >=20
    > By the way, there was this a few years ago: https://tools.ietf.org/ht=
ml/draft-jiang-v6ops-semantic-prefix I'm still worried by using bits in a G=
UA prefix for essentially semantic purposes. I fully realise we have a larg=
e supply of IPv6 prefixes. But mixing addresses and service semantics just =
seems very likely to cause problems sooner or later. I'm sorry, that reads =
like FUD, but that's my feeling.
   =20
    No hats
   =20
    That, BTW, was the reason I pushed back on Jiang's draft, and I have th=
e same fundamental question about Terastream's use case. I understand both =
concepts to essentially say something about what address one uses for an ap=
plication; putting it into the address has the characteristic of ensuring t=
hat the same set of bits is present in the packet end to end, which differs=
 from DiffServ. It basically allows DT to make an end to end service, and c=
hange the IPv6 head to support it, with actually having to change the IPv6 =
header. It affects, or can affect, routing, and as I understand it required=
 DT to allocate a truly large prefix. I find myself wondering - what if thi=
s were general? Everybody was allocating /24 or larger prefixes to get the =
equivalent of a DSCP to be usable end to end? The fact of asking the questi=
on seems crazy, but at some point, that seems to me to limit the availabili=
ty of IPv6 address space. Is that a rathole we want the network to go down?
   =20
    Just me worrying.
    -----------------------------------------------------------------------=
---------
    Victorious warriors win first and then go to war,
    Defeated warriors go to war first and then seek to win.
         Sun Tzu
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20



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

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Sun Mar 31 04:15: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 5342B1200D8 for ; Sun, 31 Mar 2019 04:15:48 -0700 (PDT)
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 BOiw-tQs_Y5f for ; Sun, 31 Mar 2019 04:15:46 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D1D1200C7 for ; Sun, 31 Mar 2019 04:15:46 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id B14E4B1; Sun, 31 Mar 2019 13:15:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554030943; bh=H+aP0LebQ7t5RMx2kApyWP+Dk2fWlkBvLIKLT+dkmvI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=h5dBRCWMzoldx38dIkY7SXoPuZaoLxmF5a+knkkeJ3388tYIOkqfcOvURwffynyWo 3DIn0JTDLhVgikKDaoZ3SF0w//RF2bv77gtyfYjXhd/gp76kEbYT3zox3iia3HkxxD 1flNsgLYJjdDhps3ifcusSOCBqYDw0QPEdme+OGA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AF1E7B0; Sun, 31 Mar 2019 13:15:43 +0200 (CEST)
Date: Sun, 31 Mar 2019 13:15:43 +0200 (CEST)
From: Mikael Abrahamsson 
To: Fred Baker 
cc: Brian E Carpenter ,  IPv6 Operations 
In-Reply-To: <09B9AD86-B21F-4A9E-A6A5-A06FB361BF17@gmail.com>
Message-ID: 
References:      <92e28c87-5c05-af81-8258-64c3bca9be78@gmail.com> <09B9AD86-B21F-4A9E-A6A5-A06FB361BF17@gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [v6ops] Operational Headache: Provisioning domains
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 11:15:48 -0000

On Sun, 31 Mar 2019, Fred Baker wrote:

> some point, that seems to me to limit the availability of IPv6 address 
> space. Is that a rathole we want the network to go down?

Can we start a new thread to discuss this PHB / addressing issue, 
separated from the PVD concept?

I don't want to lose the PVD discussion in a discussion of what good use 
of addresses is or not. They're orthogonal issues.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se