From nobody Fri Jan 3 15:52:01 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B231120110 for ; Fri, 3 Jan 2020 15:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDqJ9DRENoVz for ; Fri, 3 Jan 2020 15:51:57 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65B1120024 for ; Fri, 3 Jan 2020 15:51:56 -0800 (PST) Received: from [192.168.4.77] (unknown [190.179.40.144]) (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 2117486AA5; Sat, 4 Jan 2020 00:51:51 +0100 (CET) To: Ron Bonica , "v6ops@ietf.org" References: From: Fernando Gont 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: <8956e2c3-3f4d-9edd-ffc6-5ce5015b517c@si6networks.com> Date: Fri, 3 Jan 2020 18:40:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Jan 2020 23:52:00 -0000 Folks, I've read the document, and have the following comments: It would seem to me is that this document has resulted from an operators' concern that deployment of 464xlat might result in unnecessary heavyweight use of the stateful PLAT, leading to scalability problems or unnecessary money spendings. In that sense, I would like the issue to be documented (even if somehow we don't agree on a workaround). So I support the adoption of this document (or some version of it) -- i.e., there's value in documenting the issue itself. That said, I think that further work is required on the document. PLease find my review below: **** Some meta comments **** * Meta: I'd put more stress on why this "optimization" is important. You delve into many other (rather unnecessary) details, but don't elaborate much regarding why this "optimization" is important. * Meta: It'd be important to note that, according to the Abstract of RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In that sense, the behavior you describe is kind of "expected", and what you describe would seem to me more of a mechanism to *opt out of 464xlat* than an optimization to 464XLAT itself. * It would seem to me that the cases where this issue is more of a concern is essentially smartboxes (smart TVs) consuming media from large CDNs. If so, this should be spelled out, since this essentially sets the context for what options/approaches can be considered acceptable. *** Some specific comments: **** * Abstract: I'm curious if the term "NAT46" can be confusing, for multiple reasons (for instance, it's not specified in RFC7915). Just use "SIIT", and the context (i.e., describe what's on each side of the SIIT device, and what's the intent). * Introduction: It seems to me the intro contains too many unnecessary details. e.g., just talk about the CLAT as an abstract concept. Where/how (specifically) it is implemented is mostly irrelevant in the context of this document. * Section 4: Is the option where packets might get to the Cache with *private space* worth mentioning/describing/discussing? * Section 4.3: One more advantage of this solution is that the EAMT pairs doesn't need to match the "real" IPv4/IPv6 addresses available in the A/AAAA records, as shown in the next example. Please elaborate. * Section 5: If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it can be complemented to resolve this issue, by means of making sure that IPv6-only destinations have one A resource record (even an invalid one), despite they aren't actually connected to IPv4. Not sure what you mean. * Section 5: In fact, it may become an incentive for the IPv6 deployment in Internet services and provides the option to use an IPv4 address (maybe anycast) for the "non-valid" A resource record, that points to a "universal" web page (maybe hosted by IETF?) that displays a warning such as "Sorry, you don't IPv6 support in your operator, so this service is not available for you". Please *no*, for so many different reasons. -- including "the average user doesn't care about IPv6, and may not even be aware of what it is". * Section 6: Should we recommend having A records for IPv6-only services in Internet? The A record may point to a "reserved" or "special" IPv4 address. A web page IPv4-only hosted by IETF(?) showing "sorry this web page/service is only available from IPv6 enabled operators"?. Please no. This assumes (?) hosts prefer IPv6, but they don't need to. In which case they would get to such page and have a not so great WTH(!?) moment. * Section 6: NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right solution for optimizing the access to dual-stack services, whether they are located inside or outside the ISP. It would seem to me that, actually, Approach #3, when the ISP has no control on the CDN, or approach #1 (when it does), are the way to go. Approach #2 seems rather complex, with the consequent opportunities to screw up. * Section 6: SIIT already has a SHOULD for EAM support. Should 464XLAT be updated by this document so the CLAT has a MUST for EAM support?. 464xlat employs existing technologies. So I'm not sure you can do a MUST in 464xlat, when it relies on SIIT, and for SIIT the requirement is a SHOULD. Besides, the 464xlat spec does not even employ RFC2119 language. * Section 7: Any solution where you spoof DNS records would play bad with DNSsec. This should at least be discussed. Thanks! Cheers, Fernando On 11/12/19 14:24, Ron Bonica wrote: > Folks, > >   > > Each week between now and IETF 107, we will review and discuss one draft > with an eye towards progressing it. > >   > > This week, please review and comment on > draft-palet-v6ops-464xlat-opt-cdn-caches. > >   > > When reviewing this draft, please indicate whether you think that V6OPS > should adopt it a s a work item. > >   > >                                                       Fred and Ron > >   > > > Juniper Business Use Only > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 3 19:33:49 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1216120020 for ; Fri, 3 Jan 2020 19:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MMsAbaoavj0K for ; Fri, 3 Jan 2020 19:33:44 -0800 (PST) Received: from gw2mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (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 8CCE812006F for ; Fri, 3 Jan 2020 19:33:43 -0800 (PST) Received: from gw2mail.telecentro.local (localhost [127.0.0.1]) by gw2mail.telecentro.net.ar (Postfix) with ESMTP id 050C020590; Sat, 4 Jan 2020 00:33:27 -0300 (-03) Received: from mail.telecentro.net.ar (unknown [10.4.20.96]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gw2mail.telecentro.net.ar (Postfix) with ESMTPS; Sat, 4 Jan 2020 00:33:24 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 960CF3200BE2; Sat, 4 Jan 2020 00:33:37 -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 q7yZno0KYJDF; Sat, 4 Jan 2020 00:33:36 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id E46993200BE8; Sat, 4 Jan 2020 00:33:35 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar E46993200BE8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1578108815; bh=EEKYQJcbcRb3KbZCCJgT7QGCzHjPxe05wQnUdnoMV40=; h=Date:From:To:Message-ID:MIME-Version; b=RSQorIGwea/MhIVjBy5WOunHm8Z7dsGVZNTTRsq2IwjIo2n7lMJPcykv5spxUE53J sFVzLc4NJC3F6ME2dXn9Jetkj2i8w8klJytju8/sY3baz2j0bApOkEgUmtNamtjm4z DE7VYvGNDsJpPuX4IxaIkeyrYIiBn24ObQOOlvataez+4j+oq36GTx6jxuxj+alVGl Msgmw3+xgTtZL3xUT9f/bKp+mnHfRrH1bFD5u5SQXyQBX3fVNKxproqvHoDpG3ECdL hhDShWdGPKVY/5DwSgNNg06nj+Sc2kvYjcxItuMJemU6m05XY8HpEOimL1KJMLCfQi mwk682n6b8flg== 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 egrODurKxCK1; Sat, 4 Jan 2020 00:33:35 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 648823200BE2; Sat, 4 Jan 2020 00:33:35 -0300 (-03) Date: Sat, 4 Jan 2020 00:33:34 -0300 (ART) From: Alejandro D'Egidio To: Fernando Gont Cc: Ron Bonica , "v6ops@ietf.org list" Message-ID: <1309056255.329043111.1578108814207.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <8956e2c3-3f4d-9edd-ffc6-5ce5015b517c@si6networks.com> References: <8956e2c3-3f4d-9edd-ffc6-5ce5015b517c@si6networks.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.12_GA_3803 (ZimbraWebClient - GC79 (Win)/8.8.12_GA_3794) Thread-Topic: draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** Thread-Index: YrY1ShNa2N9/2dNbco5DXEkTt+fkww== X-KSMG-Rule-ID: 1 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 149507 [Jan 04 2020] X-KSMG-AntiSpam-Version: 5.8.14.0 X-KSMG-AntiSpam-Envelope-From: adegidio@telecentro.net.ar X-KSMG-AntiSpam-Auth: dkim=pass header.d=telecentro.net.ar X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Info: LuaCore: 336 336 9396dd2f401bf2feca9da187509bda34e224ee24, {Tracking_content_type, plain}, {Tracking_from_domain_doesnt_match_to}, telecentro.net.ar:7.1.1; www.ietf.org:7.1.1; mail.telecentro.net.ar:7.1.1; 127.0.0.199:7.1.2; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean, bases: 2020/01/04 02:31:00 X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.12, bases: 2020/01/03 23:02:00 #14960298 X-KSMG-AntiVirus-Status: Clean, skipped Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Jan 2020 03:33:48 -0000 Hello Fernando, First at all, thanks for your support to the work and the document and for = taking your time to read all the document. I will try to answer your comments below. Regards, Alejandro ----- Mensaje original ----- > De: "Fernando Gont" > Para: "Ron Bonica" , "v6ops@ietf.= org list" > Enviados: Viernes, 3 de Enero 2020 20:40:11 > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for A= doption** > Folks, >=20 > I've read the document, and have the following comments: >=20 > It would seem to me is that this document has resulted from an > operators' concern that deployment of 464xlat might result in > unnecessary heavyweight use of the stateful PLAT, leading to scalability > problems or unnecessary money spendings. In that sense, I would like the > issue to be documented (even if somehow we don't agree on a workaround). Yes, from one point of view it is correct what you said and in addition to = that we have an unnecessary second translation (NAT64) when customer traffi= c was translated to IPv6 (NAT46) and the destination (content) is available= in IPv6 also, so we could avoid both a bottleneck and a performance impair= ment. That's why we consider this as an optimization. >=20 > So I support the adoption of this document (or some version of it) -- > i.e., there's value in documenting the issue itself. >=20 > That said, I think that further work is required on the document. PLease > find my review below: >=20 >=20 > **** Some meta comments **** >=20 > * Meta: I'd put more stress on why this "optimization" is important. You > delve into many other (rather unnecessary) details, but don't elaborate > much regarding why this "optimization" is important. Yes, it is true, maybe the introduction could be simpler and more oriented = to show the concrete problem and why we believe this is important. I don't know if the info is wrong, maybe a specific initial summary that in= dicates it is missing. We can consider it. >=20 > * Meta: It'd be important to note that, according to the Abstract of > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In that > sense, the behavior you describe is kind of "expected", and what you > describe would seem to me more of a mechanism to *opt out of 464xlat* > than an optimization to 464XLAT itself. Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also. Yes, this is the expected behavior of 464XLAT (and MAP-T also) but from a p= ractical and performance point of view, maybe, it is not the most optimal p= ath for the end-to-end traffic flow. As you said if we avoid the NAT64, tec= hnically speaking, the traffic will not be going through a 464XLAT/MAP-T sc= enario. We are not saying that 464XLAT is wrong at all, we are trying to expose a r= eal problem for IPv6 only network deployments and trying to present some ap= proaches to solve it (or minimize it). >=20 > * It would seem to me that the cases where this issue is more of a > concern is essentially smartboxes (smart TVs) consuming media from large > CDNs. If so, this should be spelled out, since this essentially sets the > context for what options/approaches can be considered acceptable. Ok, yes, we can put more effort to explain that. =20 >=20 >=20 >=20 > *** Some specific comments: **** >=20 > * Abstract: I'm curious if the term "NAT46" can be confusing, for > multiple reasons (for instance, it's not specified in RFC7915). Just use > "SIIT", and the context (i.e., describe what's on each side of the SIIT > device, and what's the intent). We can review it if it is confusing. The idea on this point was to talk about the NAT46 of CPE (CLAT). Yes, RFC7915 talks about SIIT independently if it is NAT46 or not. Regarding "(IP/ICMP Translation Algorithm) as described by [RFC7915]" it re= fers just to SIIT. As we know, CLAT is a combination of NAT46 + SIIT because it's an stateless= translation from IPv4 to IPv6. =20 >=20 >=20 > * Introduction: > It seems to me the intro contains too many unnecessary details. e.g., > just talk about the CLAT as an abstract concept. Where/how > (specifically) it is implemented is mostly irrelevant in the context of > this document. Yes, I don't know, it could be, as I put above maybe in the introduction we= talk about many specific things and we could talk more about the problem i= tself. >=20 >=20 > * Section 4: > Is the option where packets might get to the Cache with *private space* > worth mentioning/describing/discussing? I'm sorry I didn't understand it very well. What *private space* are you talking about? IPv4 or IPv6? If you are talking about IPv6, CDNs normally have IPv6 GUA. If you are talking about customers with private IPv4 reaching public IPv4 d= estination CDNs, yes we could explain it because it is the main scenario we= actually some content providers offers to ISPs to deliver content from pub= lic IPv4 of CDN to customers with private IPv4 avoiding a CGN platform. Tha= t was the first reason to create this document. >=20 >=20 > * Section 4.3: > One more advantage of this solution is that the EAMT pairs doesn't > need to match the "real" IPv4/IPv6 addresses available in the A/AAAA > records, as shown in the next example. >=20 > Please elaborate. >=20 >=20 > * Section 5: > If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it can > be complemented to resolve this issue, by means of making sure that > IPv6-only destinations have one A resource record (even an invalid > one), despite they aren't actually connected to IPv4. >=20 > Not sure what you mean. It's an idea, we offer different ideas (approaches) to try optimize the tra= ffic flow. Here, the idea is that if the destination is IPv6-only, when we have an IPv= 4-only device, in a normal case you could never reach the destination but i= f you have this optimization your Proxy DNS could detect that it doesn't ha= ve an A record but it has an AAAA record, so you could be connected to the = IPv6 destination. Without this, your IPv4-only device would not be able to = get the IPv6-only content. >=20 >=20 > * Section 5: > In fact, it may become an incentive for the IPv6 deployment in > Internet services and provides the option to use an IPv4 address > (maybe anycast) for the "non-valid" A resource record, that points to > a "universal" web page (maybe hosted by IETF?) that displays a > warning such as "Sorry, you don't IPv6 support in your operator, so > this service is not available for you". >=20 > Please *no*, for so many different reasons. -- including "the average > user doesn't care about IPv6, and may not even be aware of what it is". Ok, it could be, but remember it is another proposal like the other approac= hes and the idea is to get these kind of inputs. >=20 >=20 >=20 > * Section 6: > Should we recommend having A records for IPv6-only services in > Internet? The A record may point to a "reserved" or "special" IPv4 > address. A web page IPv4-only hosted by IETF(?) showing "sorry this > web page/service is only available from IPv6 enabled operators"?. >=20 > Please no. This assumes (?) hosts prefer IPv6, but they don't need to. > In which case they would get to such page and have a not so great > WTH(!?) moment. >=20 >=20 >=20 > * Section 6: > NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right > solution for optimizing the access to dual-stack services, whether > they are located inside or outside the ISP. >=20 > It would seem to me that, actually, Approach #3, when the ISP has no > control on the CDN, or approach #1 (when it does), are the way to go. > Approach #2 seems rather complex, with the consequent opportunities to > screw up. Approach #1 is not easy to be implemented because content providers doesn't= want to be envolved on this process despite agreeing it can be an improvem= ent , so the don't want to do any change in configuration of their devices = / interfaces. It applies more in case where CDN is controlled by ISP (own C= DN), but we want to define a general solution, we need to consider the norm= al case of public / external CDNs. Approach #3, as you say, it is when ISP doesn't have control of the CDN. Th= is is could not be a very scalable solution because it's not dynamic and an= y change needs to be propagated to all CPEs. On the other hand it's a very = easy method to make a fast deploy where there are not often changes. I thin= k this is a way where that allow to the operator to deploy the solution qui= ckly without depending on complex mechanisms and where content provider doe= sn't change DNS records, this is the case of Netflix CDN where A and AAAA r= ecords always have the same IPs associated for the same FQDN (for CDN). Approach #2, yes, clearly it is more complex but it will depends on how muc= h complexity we want to give to the process and we need to define very well= which cases we want to consider. >=20 >=20 > * Section 6: > SIIT already has a SHOULD for EAM support. Should 464XLAT be updated > by this document so the CLAT has a MUST for EAM support?. >=20 > 464xlat employs existing technologies. So I'm not sure you can do a MUST > in 464xlat, when it relies on SIIT, and for SIIT the requirement is a > SHOULD. Yes, what you say is valid, these are questions to see exactly what the com= munity thinks. >=20 > Besides, the 464xlat spec does not even employ RFC2119 language. >=20 >=20 >=20 > * Section 7: >=20 > Any solution where you spoof DNS records would play bad with DNSsec. > This should at least be discussed. >=20 >=20 > Thanks! >=20 > Cheers, > Fernando >=20 >=20 >=20 >=20 > On 11/12/19 14:24, Ron Bonica wrote: >> Folks, >>=20 >> =C2=A0 >>=20 >> Each week between now and IETF 107, we will review and discuss one draft >> with an eye towards progressing it. >>=20 >> =C2=A0 >>=20 >> This week, please review and comment on >> draft-palet-v6ops-464xlat-opt-cdn-caches. >>=20 >> =C2=A0 >>=20 >> When reviewing this draft, please indicate whether you think that V6OPS >> should adopt it a s a work item. >>=20 >> =C2=A0 >>=20 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Fred and Ron >>=20 >> =C2=A0 >>=20 >>=20 >> Juniper Business Use Only >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Jan 4 14:56:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092C712009E for ; Sat, 4 Jan 2020 14:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=lHf80bl8; dkim=pass (1024-bit key) header.d=juniper.net header.b=FgLqvA7A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUR45rB44UIQ for ; Sat, 4 Jan 2020 14:56:48 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AFF12004A for ; Sat, 4 Jan 2020 14:56:48 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 004MrhVC002036 for ; Sat, 4 Jan 2020 14:56:47 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=jo6StmxdVTYs56xKvr8XRtJHTDmE0jXD/0dy7DGXT+Y=; b=lHf80bl8WN15dX//0CKOK1NwCR0TCe7bWI2X6OmbNI2TWsJHTcAtt+h+DgF/lguFvahO nG9oevVx9IQ/6nNBqCGILjz3fWggF+LInx2Gx165w2zcKdQLlrv7d5pjUNiC2ytzS5rP hSBtE06ycncZhZBsZD4w2aJOyHOLh9oDjlWOwbVcdYc9C8Nuf3iqny6+rAZajNEbDnDo fqEiUH8iy6siQj8vFCEvw4qADRz9RxF4WSP+ICuZ/FNq4CCgQx91y+77izmqnEMDhn96 AyXJ7YFq0VoPdvEk1c0yIVUTYn/caygpoIJEMhquS4BmB82SvmtalIrxA32aOiCu0QJn hg== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2102.outbound.protection.outlook.com [104.47.70.102]) by mx0a-00273201.pphosted.com with ESMTP id 2xatktghv7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 04 Jan 2020 14:56:47 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JUDOREipPPOZ7uFJkiN6NEomlyy+VCduS8xzlseRhTV+7aH9B21SNWY8Ww5dN0GQOWoicnLpPv/D+/v8MZinBO3/pvmRsznN26GXOLxgO0UO/246iY6OT9LtosQol56nIgDJUXD2lNE9uwK0/dEKaMq1hWnGhpwqxfh9mhalfeC1VS9k6+vm5QomOeIv5wHgS9djS62m81aoRfbBGy/ONKNFNStlSY4rqK97fiHHPj/G3L/iU18kBAlJZGZlUw6c1eCF2TmI8CEwmKgpf4IlzK0nEBHkphUCDcNi/88aAklzWaW1e+Cim+sEWL4AVtiV5cLNCsO1pyWWcyKLduQoVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jo6StmxdVTYs56xKvr8XRtJHTDmE0jXD/0dy7DGXT+Y=; b=NrZdTo4TLsYvvLnF3I5NLMmfWFCAZaF6w8lv3sEo4CEktfljs2lIZkpHKIkjBFkmaP5E8Bz7mIbnuUIG9t89rMWhs2MMsYR8KnlsAyrNA+70IIUZTjLJTonx/8cKssdfCOWByC52FY1mP/y8sUIj5qqGkX6IQqyaLSaII/SrB1FPzFmFPY/R1v1Nb6N0dTmZnPMNqLi7TVr/55BmpCKlvO5+csiJVcBj5zHMy34X510y9rPluv/UATX71psB1obgtTuRbarkw0BEzykM50HFwVBSmzXP5LvMnSnKhSnuBZbQ4mbi2AsgvixtLUjHxVLKeR41J9yT0x9Bx7VCTCrSbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jo6StmxdVTYs56xKvr8XRtJHTDmE0jXD/0dy7DGXT+Y=; b=FgLqvA7AqrUU/HZNwVzy5nktetb+IdSB+oy2kxuj48z4Dtgn3PfAzS0H1N42Ui/0T2zO4pYXDfpgyKb4veKZ1He2begHRh1qOlGc7Yjgk1n7Vko6uWZNZhqD6Q6Lp46Xzmz9DjVZNDg1pDnOMNAtyXaUvF7uRElrcjvyju3o18s= Received: from BN7PR05MB3938.namprd05.prod.outlook.com (52.132.216.30) by BN7PR05MB4147.namprd05.prod.outlook.com (52.132.6.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.7; Sat, 4 Jan 2020 22:56:45 +0000 Received: from BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864]) by BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864%5]) with mapi id 15.20.2623.007; Sat, 4 Jan 2020 22:56:45 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-gont-v6ops-slaac-renum **Call for adoption** Thread-Index: AdXDUjIhkP0DBO5aTlKDOPRowsUu3A== Content-Class: Date: Sat, 4 Jan 2020 22:56:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-01-04T22:56:42.9392888Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=a6773b9a-2f01-49dd-8fe5-b2c4cf9db71c; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.3.2.8 dlp-reaction: no-action x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 53c59518-f494-4f90-03a5-08d791695f53 x-ms-traffictypediagnostic: BN7PR05MB4147: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2887; x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(376002)(366004)(396003)(189003)(199004)(7696005)(2906002)(4744005)(86362001)(316002)(5660300002)(33656002)(76116006)(66946007)(66446008)(66476007)(66556008)(64756008)(6916009)(478600001)(55016002)(8936002)(186003)(26005)(71200400001)(8676002)(9686003)(81156014)(52536014)(81166006)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4147; H:BN7PR05MB3938.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Wnfkez6vdwgM7wMz85KGhUJmTbxVOCXvtThOjNLYT3KoxdeT86DjV1F352C+zAUbhLpZx3XRYSzIX4c80IpwdD7WUvhf+ONi51QhgLn366B8amRaGppXurO5RUlY8+ojWo4QZbfruGK38eHTlqRUHrsF6MGriTkTMZ2HcVHBLLarTJfXr4fse1nmeuvpaL8Jk2jSMGMs3W35qR2xfNgHiPyw+43QwlxyA3D9FSQHPoTOgP1kzgDNm1U/BZnnPpVLnc/mNtksWYlCVMYVlxi16dtwakBgnz/Rp/BgBhJEodpJrRuRFtuK0pbUSb2Gl+r6LlcuWovCfSYtEbr6Cj2e4bvtnicPl3Mcx1t6AvwCxCxmCOyFAnDPa4EoS46lnn3kJ81rSWYGkkMoeHsXD3iWhHbWjEu5w1hq3BtQzzdG1/eoNpd3lCed1Ds0ta5OK0dA x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR05MB3938763EA1271F13D1858ED9AE220BN7PR05MB3938namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 53c59518-f494-4f90-03a5-08d791695f53 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2020 22:56:44.8546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hMu7DK3KGFSKAjHB3rH63NYaS9HFF6nlFvmNlD+YS6bgPOyfutKqGOsvT/7A+U2rDUg02pxXcAlEckAmLq0pAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4147 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-04_06:2020-01-02,2020-01-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1015 phishscore=0 spamscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=652 adultscore=0 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001040217 Archived-At: Subject: [v6ops] draft-gont-v6ops-slaac-renum **Call for adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Jan 2020 22:56:50 -0000 --_000_BN7PR05MB3938763EA1271F13D1858ED9AE220BN7PR05MB3938namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Each week between now and IETF 107, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-gont-v6ops-slaac-renum. When reviewing this draft, please indicate whether you think that V6OPS sho= uld adopt it a s a work item. Fred and Ron Juniper Business Use Only --_000_BN7PR05MB3938763EA1271F13D1858ED9AE220BN7PR05MB3938namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Each week between now and IETF 107, we will revie= w and discuss one draft with an eye towards progressing it.

 

This week, please review and comment on draft-gont-v= 6ops-slaac-renum.

 

When reviewing this draft, please indicate whether y= ou think that V6OPS should adopt it a s a work item.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Fred and Ron

 


Juniper Business= Use Only

--_000_BN7PR05MB3938763EA1271F13D1858ED9AE220BN7PR05MB3938namp_-- From nobody Sun Jan 5 08:29:48 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FE01200B1 for ; Sun, 5 Jan 2020 08:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRniCS2E3L85 for ; Sun, 5 Jan 2020 08:29:45 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 CCC47120086 for ; Sun, 5 Jan 2020 08:29:44 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id a203so37972148qkc.3 for ; Sun, 05 Jan 2020 08:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=U2aisXVQmOf8SvmAwBW54FwRn1xbCZJd2gzTaklJhiM=; b=UNxlRjn6YU30apmF0xHZm96luTdY0GQ33XW4g+ddQjmTd/hKT9jrc1z/FKiGBAORWi DBLzibwTWRjfvgRvJMjoGcTporQR3Hz7EY6u8y0oPVjuCKGorEcif9wXrfu+1Jl7oBIm 6gM2Xo7BrkY3hLXLdbfL93goz+s7dYocmN5n5F8Mhcj95MWBVHMTs3xlJg5BV86eFXi3 y3G57NcIO4c0unZkZZ8QW+txIwavLjVWR5WNAWsxShiNbWMizVc81Ms+pj65fzNGkeTl qoQhq/btmSsWgvSRFrFe39FpVIq9mWwG7tNSPTk2uxJwI+nVj2C/8l4G5yq0GNJWynad vGVA== 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-transfer-encoding :content-language; bh=U2aisXVQmOf8SvmAwBW54FwRn1xbCZJd2gzTaklJhiM=; b=FShE4t6R4vd0bQqnCM7T98m87gghMJL/1zpjH1z/Y6a56mEMjCaz/UBjR/2MaroLtW eZoxfK15xed6BRXdOzrz9xloFiHDeT2kX3Ica8Kw2zvTa0C4mTAg/OVqMb98K8EpTRX4 rlha48t5vvqSUuUHrnobgqg4iSd7GlNcxCzdIGNbXuTDbdi6/wRDmSSAFWT8Hl9LrfR7 Np7KfGawGw3yXxhoIxTGvPyUWALXnj5UeWRivkgFW1RZ5RG3sqf9xiwWYPtn/chAZuDz Ak7Da7ji17o8xQvZcg+GEaKehOfXGcwfK/cvzaw7CXLGiwn/Lr7Kn3poVIXsw+uW8UqB IAJQ== X-Gm-Message-State: APjAAAXei+jB7/9QUjxwVHxXw7/TfpEcULpGgozKfw5lA0tRC4/A62J2 HtvkC4QZbH2F7fu/QkqM/9kCitPx X-Google-Smtp-Source: APXvYqzEv/Fq4wIB/L4hIjx/Q419Q7ExKBY+FDImwdFyGGFvxKvFfEoE/Vu/ey/WzDuwivZnIWeKxw== X-Received: by 2002:a37:e203:: with SMTP id g3mr79253534qki.479.1578241783589; Sun, 05 Jan 2020 08:29:43 -0800 (PST) Received: from [192.168.1.18] ([177.52.245.133]) by smtp.gmail.com with ESMTPSA id k22sm19605493qkg.80.2020.01.05.08.29.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Jan 2020 08:29:42 -0800 (PST) To: v6ops@ietf.org References: <8956e2c3-3f4d-9edd-ffc6-5ce5015b517c@si6networks.com> <1309056255.329043111.1578108814207.JavaMail.zimbra@telecentro.net.ar> From: Fernando Frediani Message-ID: <2b15c27b-a11d-896d-9414-3b3181855a41@gmail.com> Date: Sun, 5 Jan 2020 13:29:39 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <1309056255.329043111.1578108814207.JavaMail.zimbra@telecentro.net.ar> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Jan 2020 16:29:47 -0000 On 04/01/2020 00:33, Alejandro D'Egidio wrote: > >> Folks, >> >> I've read the document, and have the following comments: >> >> It would seem to me is that this document has resulted from an >> operators' concern that deployment of 464xlat might result in >> unnecessary heavyweight use of the stateful PLAT, leading to scalability >> problems or unnecessary money spendings. In that sense, I would like the >> issue to be documented (even if somehow we don't agree on a workaround). > Yes, from one point of view it is correct what you said and in addition to that we have an unnecessary second translation (NAT64) when customer traffic was translated to IPv6 (NAT46) and the destination (content) is available in IPv6 also, so we could avoid both a bottleneck and a performance impairment. That's why we consider this as an optimization. This is the biggest thing of this proposal, eliminate any unnecessary double translation where it's not needed and 'convert' any traffic that would originally happen in IPv4 (due to legacy devices behind the CPE) into IPv6 to external world. This has as result a even smaller need of IPv4 addresses in the PLAT to communicate to these destinations which have IPv6 support. 464XLAT is already great in saving IPv4 addresses and with this proposal it helps to reduce even more the dependency of IPv4 regardless the devices the user has at home. This is also an advantage over CGNAT + IPv6 scenarios where this IPv4 traffic originated from these legacy devices can't bypass the CGNAT device. So in this case it translates into even higher savings as it means even less traffic passing through the PLAT device. Regards Fernando From nobody Sun Jan 5 12:57:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDF112004F for ; Sun, 5 Jan 2020 12:56:59 -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, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zov7AwMbWS83 for ; Sun, 5 Jan 2020 12:56:56 -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 A92B1120020 for ; Sun, 5 Jan 2020 12:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1578257810; x=1578862610; 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=FI7GulRAz8phpj1OlhwQO 7ltA2Wa8q7wDzlrm9T0Bas=; b=G3JQNAkU1ihbItEYB85C2WolNRojCxY78hern U5/Vb4Bc1zU/7uzBNetTkr7D6gN9jJBqU2EYoUEg7CRe2PMnhAZprqfzfWfoH+zx RS7oZx4AUxfJVLMG/RNQgswbrSVYBY9ZVCKpFi8zQXILKx9ePoKXlR+9GPfQS6u2 SHKQ7E= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 05 Jan 2020 21:56:50 +0100 X-Spam-Processed: mail.consulintel.es, Sun, 05 Jan 2020 21:56:49 +0100 Received: from [10.192.0.137] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000017211.msg for ; Sun, 05 Jan 2020 21:56:49 +0100 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.192.0.137] X-MDArrival-Date: Sun, 05 Jan 2020 21:56:49 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1273874aaf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Sun, 05 Jan 2020 21:56:40 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Jan 2020 20:57:00 -0000 Hi Fernando, Adding some inputs, below, in-line (->). =20 =20 =EF=BB=BFEl 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" e= scribi=C3=B3: Hello Fernando, =20 First at all, thanks for your support to the work and the document and = for taking your time to read all the document. =20 I will try to answer your comments below. =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- > De: "Fernando Gont" > Para: "Ron Bonica" , "v6ops@i= etf.org list" > Enviados: Viernes, 3 de Enero 2020 20:40:11 > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call f= or Adoption** =20 > Folks, >=20 > I've read the document, and have the following comments: >=20 > It would seem to me is that this document has resulted from an > operators' concern that deployment of 464xlat might result in > unnecessary heavyweight use of the stateful PLAT, leading to scalabil= ity > problems or unnecessary money spendings. In that sense, I would like = the > issue to be documented (even if somehow we don't agree on a workaroun= d). Yes, from one point of view it is correct what you said and in addition= to that we have an unnecessary second translation (NAT64) when customer tr= affic was translated to IPv6 (NAT46) and the destination (content) is avail= able in IPv6 also, so we could avoid both a bottleneck and a performance im= pairment. That's why we consider this as an optimization. -> I think the document is doing the work of documenting the problem statem= ent and providing possible solutions, which the idea of choosing one. We un= derstand that 464XLAT was not designed having this scenario in mind, but if= we can find a good solution, is worth to solve it. Furthermore, if the WG = agree that this is the way to go, we could update with this document 464XLA= T (which is an informational one) and make it to the standards track. As I'= ve already expressed several times, it is pity that being the transition me= chanism that is more used in the world (versus all the others, in terms of = number of devices), it is not a standard. =20 =20 >=20 > So I support the adoption of this document (or some version of it) -- > i.e., there's value in documenting the issue itself. >=20 > That said, I think that further work is required on the document. PLe= ase > find my review below: >=20 >=20 > **** Some meta comments **** >=20 > * Meta: I'd put more stress on why this "optimization" is important. = You > delve into many other (rather unnecessary) details, but don't elabora= te > much regarding why this "optimization" is important. -> My reading is that the optimization and the need for it is well describe= d, but definitively will take a look into it and improve it if needed. Yes, it is true, maybe the introduction could be simpler and more orien= ted to show the concrete problem and why we believe this is important. =20 I don't know if the info is wrong, maybe a specific initial summary tha= t indicates it is missing. We can consider it. =20 =20 >=20 > * Meta: It'd be important to note that, according to the Abstract of > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In tha= t > sense, the behavior you describe is kind of "expected", and what you > describe would seem to me more of a mechanism to *opt out of 464xlat* > than an optimization to 464XLAT itself. -> Yes, I said that in my first comment. With this optimization, if we are = able to find consensus in a good solution, we improve something that was no= t initially expected to be done by 464XLAT. I don't see the "opt-out" point= that you mention. Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also. Yes, this is the expected behavior of 464XLAT (and MAP-T also) but from= a practical and performance point of view, maybe, it is not the most optim= al path for the end-to-end traffic flow. As you said if we avoid the NAT64,= technically speaking, the traffic will not be going through a 464XLAT/MAP-= T scenario. We are not saying that 464XLAT is wrong at all, we are trying to expose= a real problem for IPv6 only network deployments and trying to present som= e approaches to solve it (or minimize it). =20 >=20 > * It would seem to me that the cases where this issue is more of a > concern is essentially smartboxes (smart TVs) consuming media from la= rge > CDNs. If so, this should be spelled out, since this essentially sets = the > context for what options/approaches can be considered acceptable. Ok, yes, we can put more effort to explain that. =20 >=20 >=20 >=20 > *** Some specific comments: **** >=20 > * Abstract: I'm curious if the term "NAT46" can be confusing, for > multiple reasons (for instance, it's not specified in RFC7915). Just = use > "SIIT", and the context (i.e., describe what's on each side of the SI= IT > device, and what's the intent). -> Initially we were using the term CLAT, but then we realized that MAP-T h= as the same issue, and there it is not called CLAT, but NAT46. This is the = reason, quite simple, because the optimization will also work for MAP-T. We can review it if it is confusing. The idea on this point was to talk about the NAT46 of CPE (CLAT). Yes, RFC7915 talks about SIIT independently if it is NAT46 or not. Regarding "(IP/ICMP Translation Algorithm) as described by [RFC7915]" i= t refers just to SIIT. As we know, CLAT is a combination of NAT46 + SIIT because it's an state= less translation from IPv4 to IPv6. =20 >=20 >=20 > * Introduction: > It seems to me the intro contains too many unnecessary details. e.g., > just talk about the CLAT as an abstract concept. Where/how > (specifically) it is implemented is mostly irrelevant in the context = of > this document. Yes, I don't know, it could be, as I put above maybe in the introductio= n we talk about many specific things and we could talk more about the probl= em itself. =20 >=20 >=20 > * Section 4: > Is the option where packets might get to the Cache with *private spac= e* > worth mentioning/describing/discussing? -> When we talked with CDN/cache providers, they don't like to use non-GUA = (example the NAT64 WKP), so it is discussed as an option in approach 1. I'm sorry I didn't understand it very well. What *private space* are you talking about? IPv4 or IPv6? If you are talking about IPv6, CDNs normally have IPv6 GUA. If you are talking about customers with private IPv4 reaching public IP= v4 destination CDNs, yes we could explain it because it is the main scenari= o we actually some content providers offers to ISPs to deliver content from= public IPv4 of CDN to customers with private IPv4 avoiding a CGN platform.= That was the first reason to create this document. =20 >=20 >=20 > * Section 4.3: > One more advantage of this solution is that the EAMT pairs doesn't > need to match the "real" IPv4/IPv6 addresses available in the A/AAA= A > records, as shown in the next example. >=20 > Please elaborate. -> I think it is clear if you look at the example. >=20 >=20 > * Section 5: > If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it ca= n > be complemented to resolve this issue, by means of making sure that > IPv6-only destinations have one A resource record (even an invalid > one), despite they aren't actually connected to IPv4. >=20 > Not sure what you mean. -> I think it is clear if you read the paragraph before that one. Otherwise= we could expand the text to make it more obvious. It's an idea, we offer different ideas (approaches) to try optimize the= traffic flow. Here, the idea is that if the destination is IPv6-only, when we have an= IPv4-only device, in a normal case you could never reach the destination b= ut if you have this optimization your Proxy DNS could detect that it doesn'= t have an A record but it has an AAAA record, so you could be connected to = the IPv6 destination. Without this, your IPv4-only device would not be able= to get the IPv6-only content. =20 >=20 >=20 > * Section 5: > In fact, it may become an incentive for the IPv6 deployment in > Internet services and provides the option to use an IPv4 address > (maybe anycast) for the "non-valid" A resource record, that points = to > a "universal" web page (maybe hosted by IETF?) that displays a > warning such as "Sorry, you don't IPv6 support in your operator, so > this service is not available for you". >=20 > Please *no*, for so many different reasons. -- including "the average > user doesn't care about IPv6, and may not even be aware of what it is= ". -> It can be a different text not necessarily mention IPv6 but just "your I= nternet connection is not able to access this content, please ask your ISP = to upgrade it". Anyway, it is very contentious topic ... This probably will= get removed in a new version, or moved to an annex, etc. Ok, it could be, but remember it is another proposal like the other app= roaches and the idea is to get these kind of inputs. =20 >=20 >=20 >=20 > * Section 6: > Should we recommend having A records for IPv6-only services in > Internet? The A record may point to a "reserved" or "special" IPv4 > address. A web page IPv4-only hosted by IETF(?) showing "sorry thi= s > web page/service is only available from IPv6 enabled operators"?. >=20 > Please no. This assumes (?) hosts prefer IPv6, but they don't need to= . > In which case they would get to such page and have a not so great > WTH(!?) moment. >=20 >=20 >=20 > * Section 6: > NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right > solution for optimizing the access to dual-stack services, whether > they are located inside or outside the ISP. >=20 > It would seem to me that, actually, Approach #3, when the ISP has no > control on the CDN, or approach #1 (when it does), are the way to go. > Approach #2 seems rather complex, with the consequent opportunities t= o > screw up. Approach #1 is not easy to be implemented because content providers doe= sn't want to be envolved on this process despite agreeing it can be an impr= ovement , so the don't want to do any change in configuration of their devi= ces / interfaces. It applies more in case where CDN is controlled by ISP (o= wn CDN), but we want to define a general solution, we need to consider the = normal case of public / external CDNs. Approach #3, as you say, it is when ISP doesn't have control of the CDN= . This is could not be a very scalable solution because it's not dynamic an= d any change needs to be propagated to all CPEs. On the other hand it's a v= ery easy method to make a fast deploy where there are not often changes. I = think this is a way where that allow to the operator to deploy the solution= quickly without depending on complex mechanisms and where content provider= doesn't change DNS records, this is the case of Netflix CDN where A and AA= AA records always have the same IPs associated for the same FQDN (for CDN). Approach #2, yes, clearly it is more complex but it will depends on how= much complexity we want to give to the process and we need to define very = well which cases we want to consider. =20 =20 >=20 >=20 > * Section 6: > SIIT already has a SHOULD for EAM support. Should 464XLAT be updat= ed > by this document so the CLAT has a MUST for EAM support?. >=20 > 464xlat employs existing technologies. So I'm not sure you can do a M= UST > in 464xlat, when it relies on SIIT, and for SIIT the requirement is a > SHOULD. Yes, what you say is valid, these are questions to see exactly what the= community thinks. =20 >=20 > Besides, the 464xlat spec does not even employ RFC2119 language. >=20 >=20 >=20 > * Section 7: >=20 > Any solution where you spoof DNS records would play bad with DNSsec. > This should at least be discussed. >=20 >=20 > Thanks! >=20 > Cheers, > Fernando >=20 >=20 >=20 >=20 > On 11/12/19 14:24, Ron Bonica wrote: >> Folks, >>=20 >> =20 >>=20 >> Each week between now and IETF 107, we will review and discuss one d= raft >> with an eye towards progressing it. >>=20 >> =20 >>=20 >> This week, please review and comment on >> draft-palet-v6ops-464xlat-opt-cdn-caches. >>=20 >> =20 >>=20 >> When reviewing this draft, please indicate whether you think that V6= OPS >> should adopt it a s a work item. >>=20 >> =20 >>=20 >> Fred and Ron >>=20 >> =20 >>=20 >>=20 >> Juniper Business Use Only >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ 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 Jan 5 16:15:11 2020 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 8830E120013; Sun, 5 Jan 2020 16:15:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157826970951.4921.6213782432586208212.idtracker@ietfa.amsl.com> Date: Sun, 05 Jan 2020 16:15:09 -0800 Archived-At: Subject: [v6ops] v6ops - New Meeting Session Request for IETF 107 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, 06 Jan 2020 00:15:09 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: spring lsr 6man intarea idr Key Participant Conflict: rtgwg tsvarea panrg grow People who must be present: Fred Baker Ron Bonica Warren "Ace" Kumari Jen Linkova Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jan 5 16:31:14 2020 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 63DC21200B1; Sun, 5 Jan 2020 16:31:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157827067240.4843.15089006801138078006.idtracker@ietfa.amsl.com> Date: Sun, 05 Jan 2020 16:31:12 -0800 Archived-At: Subject: [v6ops] The V6OPS WG has placed draft-palet-v6ops-464xlat-opt-cdn-caches in state "Candidate for WG Adoption" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 00:31:12 -0000 The V6OPS WG has placed draft-palet-v6ops-464xlat-opt-cdn-caches in state Candidate for WG Adoption (entered by Fred Baker) The document is available at https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/ From nobody Mon Jan 6 00:36:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DA11200CC for ; Mon, 6 Jan 2020 00:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCNWkg0Q1TDj for ; Mon, 6 Jan 2020 00:36:02 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.226]) by ietfa.amsl.com (Postfix) with ESMTP id 069E2120098 for ; Mon, 6 Jan 2020 00:36:00 -0800 (PST) HMM_SOURCE_IP: 172.18.0.48:48416.1771451062 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-106.121.177.250?logid-C90854D225EA4EBBAEC993359A4BF84B (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id ED95D280099; Mon, 6 Jan 2020 16:35:55 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id C90854D225EA4EBBAEC993359A4BF84B for jordi.palet=40consulintel.es@dmarc.ietf.org; Mon Jan 6 16:35:57 2020 X-Transaction-ID: C90854D225EA4EBBAEC993359A4BF84B X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Date: Mon, 6 Jan 2020 16:35:49 +0800 From: "xiechf@chinatelecom.cn" To: "JORDI PALET MARTINEZ" , v6ops References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.14.409[cn] Mime-Version: 1.0 Message-ID: <2020010616354842655859@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart171272002641_=----" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jan 2020 08:36:08 -0000 This is a multi-part message in MIME format. ------=_001_NextPart171272002641_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQpIae+8jEpvcmRpLA0KSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMgYWZ0ZXIgcmVhZGlu ZyB0aGUgZHJhZnQsDQoxXFRoaXMgZHJhZnQgaXMgYWJvdXQgSVB2Ni1vbmx5IGZvciB0aGUgYWNj Y2VzcyBvZiBJUHY0LW9ubHkgY2xpZW50IHRvIGR1YWwtc3RhY2sgQ0ROL0NhY2hlcy4gRnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2Ygb3BlcmF0aW9uLCBldmVyeSBwb3NzaWJsZSBhcHByb2FjaCBwcm9w b3NlZCBzaG91bGQgbm90IHBvc2UgYWRkaXRpb25sIHJlcXVpcm1lbnRzIGZvciB0aGUgbmV0d29y ayBjb25maWd1cmF0aW9uLiANCjJcIEJhc2VkIG9uIG15IGV4cGVyaWVuY2UsIEkgdGhpbmsgdGhl IHBvc3NpYmlsaXR5IG9mIFhMQVQgdG8gYmUgdXNlZCBpbiB3aXJlbGluZSBuZXR3b3JrIGlzIHZl cnkgc21hbGwsIElzIHRoZXJlIGFueSBsYXJnZS1zY2FsZSBJU1Agd2hvIHBsYW4gdG8gdXNlIFhM QVQgZm9yIHdpcmVsaW5lIGJyb2FkYmFuZD8gTmVhcmx5IGV2ZXJ5IElQdjYtY2FwYWJsZSBDUEUg aXMgZHVhbCBzdGFjaywgaXQgaXMgdmVyeSBkaWZmaWN1bHQgdG8gY29udmluY2UgdGhlIENQRSBp bmR1c3RyeSB0byBzdXBwb3J0IFhMQVQgaW4gdGhlIGZvcnNlZW4gZnV0dXJlLiBBbm90aGVyIGZh Y3RvciB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBpcyB0aGF0IHRoZSBJUFRWIHNlcnZpY2Ugb2Yg c29tZSBJU1BzIGlzIGNhcnJpZWQgaW4gYSBzZXBlcmF0ZSBsYXllci10d28gY2hhbm5sZSwgd2hp Y2ggZG9lcyBub3QgbWl4IHdpdGggdGhlIGRlZmF1bHQgSW50ZXJuZXQgYWNjZXNzIHRyYWZmaWMu ICANCjNcSSBkb24ndCB0aGluayB0aGUgSVAgYWRkcmVzcyAxOTIuMC4yLjEgdXNlZCBpbiB0aGUg ZXhhbXBsZSBpcyBzdWl0YWJsZSwgZm9yIHRoZSBJUCBhZGRyZXNzIDE5Mi4wLjAuMC8xNiBoYXMg YmVlbiBkZWZpbmVkIHVzZWQgZm9yIHNwZWNpYWwgcHVycG9zZSwgbWF5YmUgdGhlIHB1YmxpYyBJ UCBhZGRyZXNzIGlzIGJldHRlciBmb3IgdGhlIGludGVyZmFjZSBvZiBDRE4gc2VydmVyLg0KIDRc SW4gYWRkaXRpb24sIHRoZSB0aXRsZSBvZiB0aGUgZHJhZnQgIjQ2NFhMQVQgT3B0aW1pemF0aW9u IiBpcyB0b28gZ2VuZXJhbCBhbmQgYW1iaWd1b3VzLCBJIHRoaW5rIGEgbW9yZSBzcGVjaWZpYyBv bmUgaXMgYmV0dGVyLg0KDQpCZXN0IHJlZ2FyZHMNCg0KQ2hvbmdmZW5nIA0KIA0KRnJvbTogSk9S REkgUEFMRVQgTUFSVElORVoNCkRhdGU6IDIwMjAtMDEtMDYgMDQ6NTYNClRvOiB2Nm9wc0BpZXRm Lm9yZyBsaXN0DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1wYWxldC12Nm9wcy00NjR4bGF0 LW9wdC1jZG4tY2FjaGVzICoqQ2FsbCBmb3IgQWRvcHRpb24qKg0KSGkgRmVybmFuZG8sDQogDQpB ZGRpbmcgc29tZSBpbnB1dHMsIGJlbG93LCBpbi1saW5lICgtPikuDQogDQrvu79FbCA0LzEvMjAg NDozNCwgInY2b3BzIGVuIG5vbWJyZSBkZSBBbGVqYW5kcm8gRCdFZ2lkaW8iIDx2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnIGVuIG5vbWJyZSBkZSBhZGVnaWRpbz00MHRlbGVjZW50cm8ubmV0LmFyQGRt YXJjLmlldGYub3JnPiBlc2NyaWJpw7M6DQogDQogICAgSGVsbG8gRmVybmFuZG8sDQogICAgDQog ICAgRmlyc3QgYXQgYWxsLCB0aGFua3MgZm9yIHlvdXIgc3VwcG9ydCB0byB0aGUgd29yayBhbmQg dGhlIGRvY3VtZW50IGFuZCBmb3IgdGFraW5nIHlvdXIgdGltZSB0byByZWFkIGFsbCB0aGUgZG9j dW1lbnQuDQogICAgDQogICAgSSB3aWxsIHRyeSB0byBhbnN3ZXIgeW91ciBjb21tZW50cyBiZWxv dy4NCiAgICANCiAgICANCiAgICBSZWdhcmRzLA0KICAgIEFsZWphbmRybw0KICAgIA0KICAgIC0t LS0tIE1lbnNhamUgb3JpZ2luYWwgLS0tLS0NCiAgICA+IERlOiAiRmVybmFuZG8gR29udCIgPGZn b250QHNpNm5ldHdvcmtzLmNvbT4NCiAgICA+IFBhcmE6ICJSb24gQm9uaWNhIiA8cmJvbmljYT00 MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiwgInY2b3BzQGlldGYub3JnIGxpc3QiIDx2Nm9w c0BpZXRmLm9yZz4NCiAgICA+IEVudmlhZG9zOiBWaWVybmVzLCAzIGRlIEVuZXJvIDIwMjAgMjA6 NDA6MTENCiAgICA+IEFzdW50bzogUmU6IFt2Nm9wc10gZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxh dC1vcHQtY2RuLWNhY2hlcyAqKkNhbGwgZm9yIEFkb3B0aW9uKioNCiAgICANCiAgICA+IEZvbGtz LA0KICAgID4gDQogICAgPiBJJ3ZlIHJlYWQgdGhlIGRvY3VtZW50LCBhbmQgaGF2ZSB0aGUgZm9s bG93aW5nIGNvbW1lbnRzOg0KICAgID4gDQogICAgPiBJdCB3b3VsZCBzZWVtIHRvIG1lIGlzIHRo YXQgdGhpcyBkb2N1bWVudCBoYXMgcmVzdWx0ZWQgZnJvbSBhbg0KICAgID4gb3BlcmF0b3JzJyBj b25jZXJuIHRoYXQgZGVwbG95bWVudCBvZiA0NjR4bGF0IG1pZ2h0IHJlc3VsdCBpbg0KICAgID4g dW5uZWNlc3NhcnkgaGVhdnl3ZWlnaHQgdXNlIG9mIHRoZSBzdGF0ZWZ1bCBQTEFULCBsZWFkaW5n IHRvIHNjYWxhYmlsaXR5DQogICAgPiBwcm9ibGVtcyBvciB1bm5lY2Vzc2FyeSBtb25leSBzcGVu ZGluZ3MuIEluIHRoYXQgc2Vuc2UsIEkgd291bGQgbGlrZSB0aGUNCiAgICA+IGlzc3VlIHRvIGJl IGRvY3VtZW50ZWQgKGV2ZW4gaWYgc29tZWhvdyB3ZSBkb24ndCBhZ3JlZSBvbiBhIHdvcmthcm91 bmQpLg0KICAgIFllcywgZnJvbSBvbmUgcG9pbnQgb2YgdmlldyBpdCBpcyBjb3JyZWN0IHdoYXQg eW91IHNhaWQgYW5kIGluIGFkZGl0aW9uIHRvIHRoYXQgd2UgaGF2ZSBhbiB1bm5lY2Vzc2FyeSBz ZWNvbmQgdHJhbnNsYXRpb24gKE5BVDY0KSB3aGVuIGN1c3RvbWVyIHRyYWZmaWMgd2FzIHRyYW5z bGF0ZWQgdG8gSVB2NiAoTkFUNDYpIGFuZCB0aGUgZGVzdGluYXRpb24gKGNvbnRlbnQpIGlzIGF2 YWlsYWJsZSBpbiBJUHY2IGFsc28sIHNvIHdlIGNvdWxkIGF2b2lkIGJvdGggYSBib3R0bGVuZWNr IGFuZCBhIHBlcmZvcm1hbmNlIGltcGFpcm1lbnQuIFRoYXQncyB3aHkgd2UgY29uc2lkZXIgdGhp cyBhcyBhbiBvcHRpbWl6YXRpb24uDQogDQotPiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBkb2lu ZyB0aGUgd29yayBvZiBkb2N1bWVudGluZyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHByb3Zp ZGluZyBwb3NzaWJsZSBzb2x1dGlvbnMsIHdoaWNoIHRoZSBpZGVhIG9mIGNob29zaW5nIG9uZS4g V2UgdW5kZXJzdGFuZCB0aGF0IDQ2NFhMQVQgd2FzIG5vdCBkZXNpZ25lZCBoYXZpbmcgdGhpcyBz Y2VuYXJpbyBpbiBtaW5kLCBidXQgaWYgd2UgY2FuIGZpbmQgYSBnb29kIHNvbHV0aW9uLCBpcyB3 b3J0aCB0byBzb2x2ZSBpdC4gRnVydGhlcm1vcmUsIGlmIHRoZSBXRyBhZ3JlZSB0aGF0IHRoaXMg aXMgdGhlIHdheSB0byBnbywgd2UgY291bGQgdXBkYXRlIHdpdGggdGhpcyBkb2N1bWVudCA0NjRY TEFUICh3aGljaCBpcyBhbiBpbmZvcm1hdGlvbmFsIG9uZSkgYW5kIG1ha2UgaXQgdG8gdGhlIHN0 YW5kYXJkcyB0cmFjay4gQXMgSSd2ZSBhbHJlYWR5IGV4cHJlc3NlZCBzZXZlcmFsIHRpbWVzLCBp dCBpcyBwaXR5IHRoYXQgYmVpbmcgdGhlIHRyYW5zaXRpb24gbWVjaGFuaXNtIHRoYXQgaXMgbW9y ZSB1c2VkIGluIHRoZSB3b3JsZCAodmVyc3VzIGFsbCB0aGUgb3RoZXJzLCBpbiB0ZXJtcyBvZiBu dW1iZXIgb2YgZGV2aWNlcyksIGl0IGlzIG5vdCBhIHN0YW5kYXJkLg0KICAgIA0KICAgIA0KICAg ID4gDQogICAgPiBTbyBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKG9y IHNvbWUgdmVyc2lvbiBvZiBpdCkgLS0NCiAgICA+IGkuZS4sIHRoZXJlJ3MgdmFsdWUgaW4gZG9j dW1lbnRpbmcgdGhlIGlzc3VlIGl0c2VsZi4NCiAgICA+IA0KICAgID4gVGhhdCBzYWlkLCBJIHRo aW5rIHRoYXQgZnVydGhlciB3b3JrIGlzIHJlcXVpcmVkIG9uIHRoZSBkb2N1bWVudC4gUExlYXNl DQogICAgPiBmaW5kIG15IHJldmlldyBiZWxvdzoNCiAgICA+IA0KICAgID4gDQogICAgPiAqKioq IFNvbWUgbWV0YSBjb21tZW50cyAqKioqDQogICAgPiANCiAgICA+ICogTWV0YTogSSdkIHB1dCBt b3JlIHN0cmVzcyBvbiB3aHkgdGhpcyAib3B0aW1pemF0aW9uIiBpcyBpbXBvcnRhbnQuIFlvdQ0K ICAgID4gZGVsdmUgaW50byBtYW55IG90aGVyIChyYXRoZXIgdW5uZWNlc3NhcnkpIGRldGFpbHMs IGJ1dCBkb24ndCBlbGFib3JhdGUNCiAgICA+IG11Y2ggcmVnYXJkaW5nIHdoeSB0aGlzICJvcHRp bWl6YXRpb24iIGlzIGltcG9ydGFudC4NCiANCi0+IE15IHJlYWRpbmcgaXMgdGhhdCB0aGUgb3B0 aW1pemF0aW9uIGFuZCB0aGUgbmVlZCBmb3IgaXQgaXMgd2VsbCBkZXNjcmliZWQsIGJ1dCBkZWZp bml0aXZlbHkgd2lsbCB0YWtlIGEgbG9vayBpbnRvIGl0IGFuZCBpbXByb3ZlIGl0IGlmIG5lZWRl ZC4NCiANCiAgICBZZXMsIGl0IGlzIHRydWUsIG1heWJlIHRoZSBpbnRyb2R1Y3Rpb24gY291bGQg YmUgc2ltcGxlciBhbmQgbW9yZSBvcmllbnRlZCB0byBzaG93IHRoZSBjb25jcmV0ZSBwcm9ibGVt IGFuZCB3aHkgd2UgYmVsaWV2ZSB0aGlzIGlzIGltcG9ydGFudC4NCiAgICANCiAgICBJIGRvbid0 IGtub3cgaWYgdGhlIGluZm8gaXMgd3JvbmcsIG1heWJlIGEgc3BlY2lmaWMgaW5pdGlhbCBzdW1t YXJ5IHRoYXQgaW5kaWNhdGVzIGl0IGlzIG1pc3NpbmcuIFdlIGNhbiBjb25zaWRlciBpdC4NCiAg ICANCiAgICANCiAgICA+IA0KICAgID4gKiBNZXRhOiBJdCdkIGJlIGltcG9ydGFudCB0byBub3Rl IHRoYXQsIGFjY29yZGluZyB0byB0aGUgQWJzdHJhY3Qgb2YNCiAgICA+IFJGQzY4NzcsIDQ2NFhM QVQgYXNzdW1lcyBJUHY0IHNlcnZpY2VzIG92ZXIgYW4gSVB2Ni1vbmx5IG5vZGUuIEluIHRoYXQN CiAgICA+IHNlbnNlLCB0aGUgYmVoYXZpb3IgeW91IGRlc2NyaWJlIGlzIGtpbmQgb2YgImV4cGVj dGVkIiwgYW5kIHdoYXQgeW91DQogICAgPiBkZXNjcmliZSB3b3VsZCBzZWVtIHRvIG1lIG1vcmUg b2YgYSBtZWNoYW5pc20gdG8gKm9wdCBvdXQgb2YgNDY0eGxhdCoNCiAgICA+IHRoYW4gYW4gb3B0 aW1pemF0aW9uIHRvIDQ2NFhMQVQgaXRzZWxmLg0KIA0KLT4gWWVzLCBJIHNhaWQgdGhhdCBpbiBt eSBmaXJzdCBjb21tZW50LiBXaXRoIHRoaXMgb3B0aW1pemF0aW9uLCBpZiB3ZSBhcmUgYWJsZSB0 byBmaW5kIGNvbnNlbnN1cyBpbiBhIGdvb2Qgc29sdXRpb24sIHdlIGltcHJvdmUgc29tZXRoaW5n IHRoYXQgd2FzIG5vdCBpbml0aWFsbHkgZXhwZWN0ZWQgdG8gYmUgZG9uZSBieSA0NjRYTEFULiBJ IGRvbid0IHNlZSB0aGUgIm9wdC1vdXQiIHBvaW50IHRoYXQgeW91IG1lbnRpb24uDQogDQogICAg WWVzLCA0NjRYTEFUIGFzdW1lcyBib3RoIElQdjQgc2VydmljZXMgYW5kIElQdjQtb25seSBkZXZp Y2VzIGFsc28uDQogICAgWWVzLCB0aGlzIGlzIHRoZSBleHBlY3RlZCBiZWhhdmlvciBvZiA0NjRY TEFUIChhbmQgTUFQLVQgYWxzbykgYnV0IGZyb20gYSBwcmFjdGljYWwgYW5kIHBlcmZvcm1hbmNl IHBvaW50IG9mIHZpZXcsIG1heWJlLCBpdCBpcyBub3QgdGhlIG1vc3Qgb3B0aW1hbCBwYXRoIGZv ciB0aGUgZW5kLXRvLWVuZCB0cmFmZmljIGZsb3cuIEFzIHlvdSBzYWlkIGlmIHdlIGF2b2lkIHRo ZSBOQVQ2NCwgdGVjaG5pY2FsbHkgc3BlYWtpbmcsIHRoZSB0cmFmZmljIHdpbGwgbm90IGJlIGdv aW5nIHRocm91Z2ggYSA0NjRYTEFUL01BUC1UIHNjZW5hcmlvLg0KICAgIFdlIGFyZSBub3Qgc2F5 aW5nIHRoYXQgNDY0WExBVCBpcyB3cm9uZyBhdCBhbGwsIHdlIGFyZSB0cnlpbmcgdG8gZXhwb3Nl IGEgcmVhbCBwcm9ibGVtIGZvciBJUHY2IG9ubHkgbmV0d29yayBkZXBsb3ltZW50cyBhbmQgdHJ5 aW5nIHRvIHByZXNlbnQgc29tZSBhcHByb2FjaGVzIHRvIHNvbHZlIGl0IChvciBtaW5pbWl6ZSBp dCkuDQogICAgDQogICAgPiANCiAgICA+ICogSXQgd291bGQgc2VlbSB0byBtZSB0aGF0IHRoZSBj YXNlcyB3aGVyZSB0aGlzIGlzc3VlIGlzIG1vcmUgb2YgYQ0KICAgID4gY29uY2VybiBpcyBlc3Nl bnRpYWxseSBzbWFydGJveGVzIChzbWFydCBUVnMpIGNvbnN1bWluZyBtZWRpYSBmcm9tIGxhcmdl DQogICAgPiBDRE5zLiBJZiBzbywgdGhpcyBzaG91bGQgYmUgc3BlbGxlZCBvdXQsIHNpbmNlIHRo aXMgZXNzZW50aWFsbHkgc2V0cyB0aGUNCiAgICA+IGNvbnRleHQgZm9yIHdoYXQgb3B0aW9ucy9h cHByb2FjaGVzIGNhbiBiZSBjb25zaWRlcmVkIGFjY2VwdGFibGUuDQogICAgT2ssIHllcywgd2Ug Y2FuIHB1dCBtb3JlIGVmZm9ydCB0byBleHBsYWluIHRoYXQuDQogICAgIA0KICAgID4gDQogICAg PiANCiAgICA+IA0KICAgID4gKioqIFNvbWUgc3BlY2lmaWMgY29tbWVudHM6ICoqKioNCiAgICA+ IA0KICAgID4gKiBBYnN0cmFjdDogSSdtIGN1cmlvdXMgaWYgdGhlIHRlcm0gIk5BVDQ2IiBjYW4g YmUgY29uZnVzaW5nLCBmb3INCiAgICA+IG11bHRpcGxlIHJlYXNvbnMgKGZvciBpbnN0YW5jZSwg aXQncyBub3Qgc3BlY2lmaWVkIGluIFJGQzc5MTUpLiBKdXN0IHVzZQ0KICAgID4gIlNJSVQiLCBh bmQgdGhlIGNvbnRleHQgKGkuZS4sIGRlc2NyaWJlIHdoYXQncyBvbiBlYWNoIHNpZGUgb2YgdGhl IFNJSVQNCiAgICA+IGRldmljZSwgYW5kIHdoYXQncyB0aGUgaW50ZW50KS4NCiANCi0+IEluaXRp YWxseSB3ZSB3ZXJlIHVzaW5nIHRoZSB0ZXJtIENMQVQsIGJ1dCB0aGVuIHdlIHJlYWxpemVkIHRo YXQgTUFQLVQgaGFzIHRoZSBzYW1lIGlzc3VlLCBhbmQgdGhlcmUgaXQgaXMgbm90IGNhbGxlZCBD TEFULCBidXQgTkFUNDYuIFRoaXMgaXMgdGhlIHJlYXNvbiwgcXVpdGUgc2ltcGxlLCBiZWNhdXNl IHRoZSBvcHRpbWl6YXRpb24gd2lsbCBhbHNvIHdvcmsgZm9yIE1BUC1ULg0KIA0KICAgIFdlIGNh biByZXZpZXcgaXQgaWYgaXQgaXMgY29uZnVzaW5nLg0KICAgIFRoZSBpZGVhIG9uIHRoaXMgcG9p bnQgd2FzIHRvIHRhbGsgYWJvdXQgdGhlIE5BVDQ2IG9mIENQRSAoQ0xBVCkuDQogICAgWWVzLCBS RkM3OTE1IHRhbGtzIGFib3V0IFNJSVQgaW5kZXBlbmRlbnRseSBpZiBpdCBpcyBOQVQ0NiBvciBu b3QuDQogICAgUmVnYXJkaW5nICIoSVAvSUNNUCBUcmFuc2xhdGlvbiBBbGdvcml0aG0pIGFzIGRl c2NyaWJlZCBieSBbUkZDNzkxNV0iIGl0IHJlZmVycyBqdXN0IHRvIFNJSVQuDQogICAgQXMgd2Ug a25vdywgQ0xBVCBpcyBhIGNvbWJpbmF0aW9uIG9mIE5BVDQ2ICsgU0lJVCBiZWNhdXNlIGl0J3Mg YW4gc3RhdGVsZXNzIHRyYW5zbGF0aW9uIGZyb20gSVB2NCB0byBJUHY2Lg0KICAgICANCiAgICA+ IA0KICAgID4gDQogICAgPiAqIEludHJvZHVjdGlvbjoNCiAgICA+IEl0IHNlZW1zIHRvIG1lIHRo ZSBpbnRybyBjb250YWlucyB0b28gbWFueSB1bm5lY2Vzc2FyeSBkZXRhaWxzLiBlLmcuLA0KICAg ID4ganVzdCB0YWxrIGFib3V0IHRoZSBDTEFUIGFzIGFuIGFic3RyYWN0IGNvbmNlcHQuIFdoZXJl L2hvdw0KICAgID4gKHNwZWNpZmljYWxseSkgaXQgaXMgaW1wbGVtZW50ZWQgaXMgbW9zdGx5IGly cmVsZXZhbnQgaW4gdGhlIGNvbnRleHQgb2YNCiAgICA+IHRoaXMgZG9jdW1lbnQuDQogICAgWWVz LCBJIGRvbid0IGtub3csIGl0IGNvdWxkIGJlLCBhcyBJIHB1dCBhYm92ZSBtYXliZSBpbiB0aGUg aW50cm9kdWN0aW9uIHdlIHRhbGsgYWJvdXQgbWFueSBzcGVjaWZpYyB0aGluZ3MgYW5kIHdlIGNv dWxkIHRhbGsgbW9yZSBhYm91dCB0aGUgcHJvYmxlbSBpdHNlbGYuDQogICAgDQogICAgPiANCiAg ICA+IA0KICAgID4gKiBTZWN0aW9uIDQ6DQogICAgPiBJcyB0aGUgb3B0aW9uIHdoZXJlIHBhY2tl dHMgbWlnaHQgZ2V0IHRvIHRoZSBDYWNoZSB3aXRoICpwcml2YXRlIHNwYWNlKg0KICAgID4gd29y dGggbWVudGlvbmluZy9kZXNjcmliaW5nL2Rpc2N1c3Npbmc/DQogDQotPiBXaGVuIHdlIHRhbGtl ZCB3aXRoIENETi9jYWNoZSBwcm92aWRlcnMsIHRoZXkgZG9uJ3QgbGlrZSB0byB1c2Ugbm9uLUdV QSAoZXhhbXBsZSB0aGUgTkFUNjQgV0tQKSwgc28gaXQgaXMgZGlzY3Vzc2VkIGFzIGFuIG9wdGlv biBpbiBhcHByb2FjaCAxLg0KIA0KICAgIEknbSBzb3JyeSBJIGRpZG4ndCB1bmRlcnN0YW5kIGl0 IHZlcnkgd2VsbC4NCiAgICBXaGF0ICpwcml2YXRlIHNwYWNlKiBhcmUgeW91IHRhbGtpbmcgYWJv dXQ/IElQdjQgb3IgSVB2Nj8NCiAgICBJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgSVB2NiwgQ0RO cyBub3JtYWxseSBoYXZlIElQdjYgR1VBLg0KICAgIElmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBj dXN0b21lcnMgd2l0aCBwcml2YXRlIElQdjQgcmVhY2hpbmcgcHVibGljIElQdjQgZGVzdGluYXRp b24gQ0ROcywgeWVzIHdlIGNvdWxkIGV4cGxhaW4gaXQgYmVjYXVzZSBpdCBpcyB0aGUgbWFpbiBz Y2VuYXJpbyB3ZSBhY3R1YWxseSBzb21lIGNvbnRlbnQgcHJvdmlkZXJzIG9mZmVycyB0byBJU1Bz IHRvIGRlbGl2ZXIgY29udGVudCBmcm9tIHB1YmxpYyBJUHY0IG9mIENETiB0byBjdXN0b21lcnMg d2l0aCBwcml2YXRlIElQdjQgYXZvaWRpbmcgYSBDR04gcGxhdGZvcm0uIFRoYXQgd2FzIHRoZSBm aXJzdCByZWFzb24gdG8gY3JlYXRlIHRoaXMgZG9jdW1lbnQuDQogICAgDQogICAgPiANCiAgICA+ IA0KICAgID4gKiBTZWN0aW9uIDQuMzoNCiAgICA+ICAgT25lIG1vcmUgYWR2YW50YWdlIG9mIHRo aXMgc29sdXRpb24gaXMgdGhhdCB0aGUgRUFNVCBwYWlycyBkb2Vzbid0DQogICAgPiAgIG5lZWQg dG8gbWF0Y2ggdGhlICJyZWFsIiBJUHY0L0lQdjYgYWRkcmVzc2VzIGF2YWlsYWJsZSBpbiB0aGUg QS9BQUFBDQogICAgPiAgIHJlY29yZHMsIGFzIHNob3duIGluIHRoZSBuZXh0IGV4YW1wbGUuDQog ICAgPiANCiAgICA+IFBsZWFzZSBlbGFib3JhdGUuDQogDQotPiBJIHRoaW5rIGl0IGlzIGNsZWFy IGlmIHlvdSBsb29rIGF0IHRoZSBleGFtcGxlLg0KIA0KICAgID4gDQogICAgPiANCiAgICA+ICog U2VjdGlvbiA1Og0KICAgID4gICBJZiBOQVQ0Ni9DTEFUL0ROUy1wcm94eS1FQU0gYXBwcm9hY2gg KFNlY3Rpb24gNC4yKSBpcyBjaG9zZW4sIGl0IGNhbg0KICAgID4gICBiZSBjb21wbGVtZW50ZWQg dG8gcmVzb2x2ZSB0aGlzIGlzc3VlLCBieSBtZWFucyBvZiBtYWtpbmcgc3VyZSB0aGF0DQogICAg PiAgIElQdjYtb25seSBkZXN0aW5hdGlvbnMgaGF2ZSBvbmUgQSByZXNvdXJjZSByZWNvcmQgKGV2 ZW4gYW4gaW52YWxpZA0KICAgID4gICBvbmUpLCBkZXNwaXRlIHRoZXkgYXJlbid0IGFjdHVhbGx5 IGNvbm5lY3RlZCB0byBJUHY0Lg0KICAgID4gDQogICAgPiBOb3Qgc3VyZSB3aGF0IHlvdSBtZWFu Lg0KIA0KLT4gSSB0aGluayBpdCBpcyBjbGVhciBpZiB5b3UgcmVhZCB0aGUgcGFyYWdyYXBoIGJl Zm9yZSB0aGF0IG9uZS4gT3RoZXJ3aXNlIHdlIGNvdWxkIGV4cGFuZCB0aGUgdGV4dCB0byBtYWtl IGl0IG1vcmUgb2J2aW91cy4NCiANCiAgICBJdCdzIGFuIGlkZWEsIHdlIG9mZmVyIGRpZmZlcmVu dCBpZGVhcyAoYXBwcm9hY2hlcykgdG8gdHJ5IG9wdGltaXplIHRoZSB0cmFmZmljIGZsb3cuDQog ICAgSGVyZSwgdGhlIGlkZWEgaXMgdGhhdCBpZiB0aGUgZGVzdGluYXRpb24gaXMgSVB2Ni1vbmx5 LCB3aGVuIHdlIGhhdmUgYW4gSVB2NC1vbmx5IGRldmljZSwgaW4gYSBub3JtYWwgY2FzZSB5b3Ug Y291bGQgbmV2ZXIgcmVhY2ggdGhlIGRlc3RpbmF0aW9uIGJ1dCBpZiB5b3UgaGF2ZSB0aGlzIG9w dGltaXphdGlvbiB5b3VyIFByb3h5IEROUyBjb3VsZCBkZXRlY3QgdGhhdCBpdCBkb2Vzbid0IGhh dmUgYW4gQSByZWNvcmQgYnV0IGl0IGhhcyBhbiBBQUFBIHJlY29yZCwgc28geW91IGNvdWxkIGJl IGNvbm5lY3RlZCB0byB0aGUgSVB2NiBkZXN0aW5hdGlvbi4gV2l0aG91dCB0aGlzLCB5b3VyIElQ djQtb25seSBkZXZpY2Ugd291bGQgbm90IGJlIGFibGUgdG8gZ2V0IHRoZSBJUHY2LW9ubHkgY29u dGVudC4NCiAgICANCiAgICA+IA0KICAgID4gDQogICAgPiAqIFNlY3Rpb24gNToNCiAgICA+ICAg SW4gZmFjdCwgaXQgbWF5IGJlY29tZSBhbiBpbmNlbnRpdmUgZm9yIHRoZSBJUHY2IGRlcGxveW1l bnQgaW4NCiAgICA+ICAgSW50ZXJuZXQgc2VydmljZXMgYW5kIHByb3ZpZGVzIHRoZSBvcHRpb24g dG8gdXNlIGFuIElQdjQgYWRkcmVzcw0KICAgID4gICAobWF5YmUgYW55Y2FzdCkgZm9yIHRoZSAi bm9uLXZhbGlkIiBBIHJlc291cmNlIHJlY29yZCwgdGhhdCBwb2ludHMgdG8NCiAgICA+ICAgYSAi dW5pdmVyc2FsIiB3ZWIgcGFnZSAobWF5YmUgaG9zdGVkIGJ5IElFVEY/KSB0aGF0IGRpc3BsYXlz IGENCiAgICA+ICAgd2FybmluZyBzdWNoIGFzICJTb3JyeSwgeW91IGRvbid0IElQdjYgc3VwcG9y dCBpbiB5b3VyIG9wZXJhdG9yLCBzbw0KICAgID4gICB0aGlzIHNlcnZpY2UgaXMgbm90IGF2YWls YWJsZSBmb3IgeW91Ii4NCiAgICA+IA0KICAgID4gUGxlYXNlICpubyosIGZvciBzbyBtYW55IGRp ZmZlcmVudCByZWFzb25zLiAtLSBpbmNsdWRpbmcgInRoZSBhdmVyYWdlDQogICAgPiB1c2VyIGRv ZXNuJ3QgY2FyZSBhYm91dCBJUHY2LCBhbmQgbWF5IG5vdCBldmVuIGJlIGF3YXJlIG9mIHdoYXQg aXQgaXMiLg0KIA0KLT4gSXQgY2FuIGJlIGEgZGlmZmVyZW50IHRleHQgbm90IG5lY2Vzc2FyaWx5 IG1lbnRpb24gSVB2NiBidXQganVzdCAieW91ciBJbnRlcm5ldCBjb25uZWN0aW9uIGlzIG5vdCBh YmxlIHRvIGFjY2VzcyB0aGlzIGNvbnRlbnQsIHBsZWFzZSBhc2sgeW91ciBJU1AgdG8gdXBncmFk ZSBpdCIuIEFueXdheSwgaXQgaXMgdmVyeSBjb250ZW50aW91cyB0b3BpYyAuLi4gVGhpcyBwcm9i YWJseSB3aWxsIGdldCByZW1vdmVkIGluIGEgbmV3IHZlcnNpb24sIG9yIG1vdmVkIHRvIGFuIGFu bmV4LCBldGMuDQogDQogICAgT2ssIGl0IGNvdWxkIGJlLCBidXQgcmVtZW1iZXIgaXQgaXMgYW5v dGhlciBwcm9wb3NhbCBsaWtlIHRoZSBvdGhlciBhcHByb2FjaGVzIGFuZCB0aGUgaWRlYSBpcyB0 byBnZXQgdGhlc2Uga2luZCBvZiBpbnB1dHMuDQogICAgDQogICAgPiANCiAgICA+IA0KICAgID4g DQogICAgPiAqIFNlY3Rpb24gNjoNCiAgICA+ICAgU2hvdWxkIHdlIHJlY29tbWVuZCBoYXZpbmcg QSByZWNvcmRzIGZvciBJUHY2LW9ubHkgc2VydmljZXMgaW4NCiAgICA+ICAgSW50ZXJuZXQ/ICBU aGUgQSByZWNvcmQgbWF5IHBvaW50IHRvIGEgInJlc2VydmVkIiBvciAic3BlY2lhbCIgSVB2NA0K ICAgID4gICBhZGRyZXNzLiAgQSB3ZWIgcGFnZSBJUHY0LW9ubHkgaG9zdGVkIGJ5IElFVEYoPykg c2hvd2luZyAic29ycnkgdGhpcw0KICAgID4gICB3ZWIgcGFnZS9zZXJ2aWNlIGlzIG9ubHkgYXZh aWxhYmxlIGZyb20gSVB2NiBlbmFibGVkIG9wZXJhdG9ycyI/Lg0KICAgID4gDQogICAgPiBQbGVh c2Ugbm8uIFRoaXMgYXNzdW1lcyAoPykgaG9zdHMgcHJlZmVyIElQdjYsIGJ1dCB0aGV5IGRvbid0 IG5lZWQgdG8uDQogICAgPiBJbiB3aGljaCBjYXNlIHRoZXkgd291bGQgZ2V0IHRvIHN1Y2ggcGFn ZSBhbmQgaGF2ZSBhIG5vdCBzbyBncmVhdA0KICAgID4gV1RIKCE/KSBtb21lbnQuDQogICAgPiAN CiAgICA+IA0KICAgID4gDQogICAgPiAqIFNlY3Rpb24gNjoNCiAgICA+ICAgTkFUNDYvQ0xBVC9E TlMtcHJveHktRUFNIGFwcHJvYWNoIChTZWN0aW9uIDQuMikgc2VlbXMgdGhlIHJpZ2h0DQogICAg PiAgIHNvbHV0aW9uIGZvciBvcHRpbWl6aW5nIHRoZSBhY2Nlc3MgdG8gZHVhbC1zdGFjayBzZXJ2 aWNlcywgd2hldGhlcg0KICAgID4gICB0aGV5IGFyZSBsb2NhdGVkIGluc2lkZSBvciBvdXRzaWRl IHRoZSBJU1AuDQogICAgPiANCiAgICA+IEl0IHdvdWxkIHNlZW0gdG8gbWUgdGhhdCwgYWN0dWFs bHksIEFwcHJvYWNoICMzLCB3aGVuIHRoZSBJU1AgaGFzIG5vDQogICAgPiBjb250cm9sIG9uIHRo ZSBDRE4sIG9yIGFwcHJvYWNoICMxICh3aGVuIGl0IGRvZXMpLCBhcmUgdGhlIHdheSB0byBnby4N CiAgICA+IEFwcHJvYWNoICMyIHNlZW1zIHJhdGhlciBjb21wbGV4LCB3aXRoIHRoZSBjb25zZXF1 ZW50IG9wcG9ydHVuaXRpZXMgdG8NCiAgICA+IHNjcmV3IHVwLg0KICAgIEFwcHJvYWNoICMxIGlz IG5vdCBlYXN5IHRvIGJlIGltcGxlbWVudGVkIGJlY2F1c2UgY29udGVudCBwcm92aWRlcnMgZG9l c24ndCB3YW50IHRvIGJlIGVudm9sdmVkIG9uIHRoaXMgcHJvY2VzcyBkZXNwaXRlIGFncmVlaW5n IGl0IGNhbiBiZSBhbiBpbXByb3ZlbWVudCAsIHNvIHRoZSBkb24ndCB3YW50IHRvIGRvIGFueSBj aGFuZ2UgaW4gY29uZmlndXJhdGlvbiBvZiB0aGVpciBkZXZpY2VzIC8gaW50ZXJmYWNlcy4gSXQg YXBwbGllcyBtb3JlIGluIGNhc2Ugd2hlcmUgQ0ROIGlzIGNvbnRyb2xsZWQgYnkgSVNQIChvd24g Q0ROKSwgYnV0IHdlIHdhbnQgdG8gZGVmaW5lIGEgZ2VuZXJhbCBzb2x1dGlvbiwgd2UgbmVlZCB0 byBjb25zaWRlciB0aGUgbm9ybWFsIGNhc2Ugb2YgcHVibGljIC8gZXh0ZXJuYWwgQ0ROcy4NCiAg ICBBcHByb2FjaCAjMywgYXMgeW91IHNheSwgaXQgaXMgd2hlbiBJU1AgZG9lc24ndCBoYXZlIGNv bnRyb2wgb2YgdGhlIENETi4gVGhpcyBpcyBjb3VsZCBub3QgYmUgYSB2ZXJ5IHNjYWxhYmxlIHNv bHV0aW9uIGJlY2F1c2UgaXQncyBub3QgZHluYW1pYyBhbmQgYW55IGNoYW5nZSBuZWVkcyB0byBi ZSBwcm9wYWdhdGVkIHRvIGFsbCBDUEVzLiBPbiB0aGUgb3RoZXIgaGFuZCBpdCdzIGEgdmVyeSBl YXN5IG1ldGhvZCB0byBtYWtlIGEgZmFzdCBkZXBsb3kgd2hlcmUgdGhlcmUgYXJlIG5vdCBvZnRl biBjaGFuZ2VzLiBJIHRoaW5rIHRoaXMgaXMgYSB3YXkgd2hlcmUgdGhhdCBhbGxvdyB0byB0aGUg b3BlcmF0b3IgdG8gZGVwbG95IHRoZSBzb2x1dGlvbiBxdWlja2x5IHdpdGhvdXQgZGVwZW5kaW5n IG9uIGNvbXBsZXggbWVjaGFuaXNtcyBhbmQgd2hlcmUgY29udGVudCBwcm92aWRlciBkb2Vzbid0 IGNoYW5nZSBETlMgcmVjb3JkcywgdGhpcyBpcyB0aGUgY2FzZSBvZiBOZXRmbGl4IENETiB3aGVy ZSBBIGFuZCBBQUFBIHJlY29yZHMgYWx3YXlzIGhhdmUgdGhlIHNhbWUgSVBzIGFzc29jaWF0ZWQg Zm9yIHRoZSBzYW1lIEZRRE4gKGZvciBDRE4pLg0KICAgIEFwcHJvYWNoICMyLCB5ZXMsIGNsZWFy bHkgaXQgaXMgbW9yZSBjb21wbGV4IGJ1dCBpdCB3aWxsIGRlcGVuZHMgb24gaG93IG11Y2ggY29t cGxleGl0eSB3ZSB3YW50IHRvIGdpdmUgdG8gdGhlIHByb2Nlc3MgYW5kIHdlIG5lZWQgdG8gZGVm aW5lIHZlcnkgd2VsbCB3aGljaCBjYXNlcyB3ZSB3YW50IHRvIGNvbnNpZGVyLg0KICAgIA0KICAg IA0KICAgID4gDQogICAgPiANCiAgICA+ICogU2VjdGlvbiA2Og0KICAgID4gICBTSUlUIGFscmVh ZHkgaGFzIGEgU0hPVUxEIGZvciBFQU0gc3VwcG9ydC4gIFNob3VsZCA0NjRYTEFUIGJlIHVwZGF0 ZWQNCiAgICA+ICAgYnkgdGhpcyBkb2N1bWVudCBzbyB0aGUgQ0xBVCBoYXMgYSBNVVNUIGZvciBF QU0gc3VwcG9ydD8uDQogICAgPiANCiAgICA+IDQ2NHhsYXQgZW1wbG95cyBleGlzdGluZyB0ZWNo bm9sb2dpZXMuIFNvIEknbSBub3Qgc3VyZSB5b3UgY2FuIGRvIGEgTVVTVA0KICAgID4gaW4gNDY0 eGxhdCwgd2hlbiBpdCByZWxpZXMgb24gU0lJVCwgYW5kIGZvciBTSUlUIHRoZSByZXF1aXJlbWVu dCBpcyBhDQogICAgPiBTSE9VTEQuDQogICAgWWVzLCB3aGF0IHlvdSBzYXkgaXMgdmFsaWQsIHRo ZXNlIGFyZSBxdWVzdGlvbnMgdG8gc2VlIGV4YWN0bHkgd2hhdCB0aGUgY29tbXVuaXR5IHRoaW5r cy4NCiAgICANCiAgICA+IA0KICAgID4gQmVzaWRlcywgdGhlIDQ2NHhsYXQgc3BlYyBkb2VzIG5v dCBldmVuIGVtcGxveSBSRkMyMTE5IGxhbmd1YWdlLg0KICAgID4gDQogICAgPiANCiAgICA+IA0K ICAgID4gKiBTZWN0aW9uIDc6DQogICAgPiANCiAgICA+IEFueSBzb2x1dGlvbiB3aGVyZSB5b3Ug c3Bvb2YgRE5TIHJlY29yZHMgd291bGQgcGxheSBiYWQgd2l0aCBETlNzZWMuDQogICAgPiBUaGlz IHNob3VsZCBhdCBsZWFzdCBiZSBkaXNjdXNzZWQuDQogICAgPiANCiAgICA+IA0KICAgID4gVGhh bmtzIQ0KICAgID4gDQogICAgPiBDaGVlcnMsDQogICAgPiBGZXJuYW5kbw0KICAgID4gDQogICAg PiANCiAgICA+IA0KICAgID4gDQogICAgPiBPbiAxMS8xMi8xOSAxNDoyNCwgUm9uIEJvbmljYSB3 cm90ZToNCiAgICA+PiBGb2xrcywNCiAgICA+PiANCiAgICA+PiAgDQogICAgPj4gDQogICAgPj4g RWFjaCB3ZWVrIGJldHdlZW4gbm93IGFuZCBJRVRGIDEwNywgd2Ugd2lsbCByZXZpZXcgYW5kIGRp c2N1c3Mgb25lIGRyYWZ0DQogICAgPj4gd2l0aCBhbiBleWUgdG93YXJkcyBwcm9ncmVzc2luZyBp dC4NCiAgICA+PiANCiAgICA+PiAgDQogICAgPj4gDQogICAgPj4gVGhpcyB3ZWVrLCBwbGVhc2Ug cmV2aWV3IGFuZCBjb21tZW50IG9uDQogICAgPj4gZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxhdC1v cHQtY2RuLWNhY2hlcy4NCiAgICA+PiANCiAgICA+PiAgDQogICAgPj4gDQogICAgPj4gV2hlbiBy ZXZpZXdpbmcgdGhpcyBkcmFmdCwgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IHRoaW5rIHRo YXQgVjZPUFMNCiAgICA+PiBzaG91bGQgYWRvcHQgaXQgYSBzIGEgd29yayBpdGVtLg0KICAgID4+ IA0KICAgID4+ICANCiAgICA+PiANCiAgICA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGcmVkIGFuZCBSb24NCiAgICA+PiANCiAgICA+PiAg DQogICAgPj4gDQogICAgPj4gDQogICAgPj4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KICAg ID4+IA0KICAgID4+IA0KICAgID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgPj4gdjZvcHMgbWFpbGluZyBsaXN0DQogICAgPj4gdjZvcHNAaWV0 Zi5vcmcNCiAgICA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQogICAgPj4gDQogICAgPiANCiAgICA+IA0KICAgID4gLS0NCiAgICA+IEZlcm5hbmRvIEdvbnQN CiAgICA+IFNJNiBOZXR3b3Jrcw0KICAgID4gZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb20N CiAgICA+IFBHUCBGaW5nZXJwcmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUy NSAwRDU1IDFENEUgNzQ5Mg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gdjZv cHMgbWFpbGluZyBsaXN0DQogICAgPiB2Nm9wc0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KICAgIA0KICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0 DQogICAgdjZvcHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzDQogICAgDQogDQogDQogDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQpJUHY0IGlzIG92ZXINCkFyZSB5b3UgcmVhZHkgZm9yIHRoZSBu ZXcgSW50ZXJuZXQgPw0KaHR0cDovL3d3dy50aGVpcHY2Y29tcGFueS5jb20NClRoZSBJUHY2IENv bXBhbnkNCiANClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdo aWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlz IGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChz KSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkIGRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmls ZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1p bmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdh cmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0 aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1 ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBiZSBjb25z aWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdp bmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUg aXQuDQogDQogDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K ------=_001_NextPart171272002641_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi，Jordi,
I have the following comments after reading the draft,
1\This draft is about IPv6-only for the acccess of IPv4-only client to dual-stack CDN/Caches. From the perspective of operation, every possible approach proposed should not pose additionl requirments for the network configuration. 
2\ Based on my experience, I think the possibility of XLAT to be used in wireline network is very small, Is there any large-scale ISP who plan to use XLAT for wireline broadband? Nearly every IPv6-capable CPE is dual stack, it is very difficult to convince the CPE industry to support XLAT in the forseen future. Another factor that we should consider is that the IPTV service of some ISPs is carried in a seperate layer-two channle, which does not mix with the default Internet access traffic.  
3\I don't think the IP address 192.0.2.1 used in the example is suitable, for the IP address 192.0.0.0/16 has been defined used for special purpose, maybe the public IP address is better for the interface of CDN server.

192.0.2.0/24 is reserved for documentation purposes, thus, IMHO, it is ideal for examples.


Address Block Name RFC Allocation Date Termination Date Source Destination Forwardable Globally Reachable Reserved-by-Protocol
[...]

192.0.2.0/24 Documentation (TEST-NET-1) [RFC5737] 2010-01 N/A False False False False False

Source: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

Best regards,

Gábor Lencse



 4\In addition, the title of the draft "464XLAT Optimization" is too general and ambiguous, I think a more specific one is better.

Best regards

Chongfeng 
 
Date: 2020-01-06 04:56
Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
Hi Fernando,
 
Adding some inputs, below, in-line (->).
 
El 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" <v6ops-bounces@ietf.org en nombre de adegidio=40telecentro.net.ar@dmarc.ietf.org> escribió:
 
    Hello Fernando,
   
    First at all, thanks for your support to the work and the document and for taking your time to read all the document.
   
    I will try to answer your comments below.
   
   
    Regards,
    Alejandro
   
    ----- Mensaje original -----
    > De: "Fernando Gont" <fgont@si6networks.com>
    > Enviados: Viernes, 3 de Enero 2020 20:40:11
    > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
   
    > Folks,
    >
    > I've read the document, and have the following comments:
    >
    > It would seem to me is that this document has resulted from an
    > operators' concern that deployment of 464xlat might result in
    > unnecessary heavyweight use of the stateful PLAT, leading to scalability
    > problems or unnecessary money spendings. In that sense, I would like the
    > issue to be documented (even if somehow we don't agree on a workaround).
    Yes, from one point of view it is correct what you said and in addition to that we have an unnecessary second translation (NAT64) when customer traffic was translated to IPv6 (NAT46) and the destination (content) is available in IPv6 also, so we could avoid both a bottleneck and a performance impairment. That's why we consider this as an optimization.
 
-> I think the document is doing the work of documenting the problem statement and providing possible solutions, which the idea of choosing one. We understand that 464XLAT was not designed having this scenario in mind, but if we can find a good solution, is worth to solve it. Furthermore, if the WG agree that this is the way to go, we could update with this document 464XLAT (which is an informational one) and make it to the standards track. As I've already expressed several times, it is pity that being the transition mechanism that is more used in the world (versus all the others, in terms of number of devices), it is not a standard.
   
   
    >
    > So I support the adoption of this document (or some version of it) --
    > i.e., there's value in documenting the issue itself.
    >
    > That said, I think that further work is required on the document. PLease
    > find my review below:
    >
    >
    > **** Some meta comments ****
    >
    > * Meta: I'd put more stress on why this "optimization" is important. You
    > delve into many other (rather unnecessary) details, but don't elaborate
    > much regarding why this "optimization" is important.
 
-> My reading is that the optimization and the need for it is well described, but definitively will take a look into it and improve it if needed.
 
    Yes, it is true, maybe the introduction could be simpler and more oriented to show the concrete problem and why we believe this is important.
   
    I don't know if the info is wrong, maybe a specific initial summary that indicates it is missing. We can consider it.
   
   
    >
    > * Meta: It'd be important to note that, according to the Abstract of
    > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In that
    > sense, the behavior you describe is kind of "expected", and what you
    > describe would seem to me more of a mechanism to *opt out of 464xlat*
    > than an optimization to 464XLAT itself.
 
-> Yes, I said that in my first comment. With this optimization, if we are able to find consensus in a good solution, we improve something that was not initially expected to be done by 464XLAT. I don't see the "opt-out" point that you mention.
 
    Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also.
    Yes, this is the expected behavior of 464XLAT (and MAP-T also) but from a practical and performance point of view, maybe, it is not the most optimal path for the end-to-end traffic flow. As you said if we avoid the NAT64, technically speaking, the traffic will not be going through a 464XLAT/MAP-T scenario.
    We are not saying that 464XLAT is wrong at all, we are trying to expose a real problem for IPv6 only network deployments and trying to present some approaches to solve it (or minimize it).
   
    >
    > * It would seem to me that the cases where this issue is more of a
    > concern is essentially smartboxes (smart TVs) consuming media from large
    > CDNs. If so, this should be spelled out, since this essentially sets the
    > context for what options/approaches can be considered acceptable.
    Ok, yes, we can put more effort to explain that.
    
    >
    >
    >
    > *** Some specific comments: ****
    >
    > * Abstract: I'm curious if the term "NAT46" can be confusing, for
    > multiple reasons (for instance, it's not specified in RFC7915). Just use
    > "SIIT", and the context (i.e., describe what's on each side of the SIIT
    > device, and what's the intent).
 
-> Initially we were using the term CLAT, but then we realized that MAP-T has the same issue, and there it is not called CLAT, but NAT46. This is the reason, quite simple, because the optimization will also work for MAP-T.
 
    We can review it if it is confusing.
    The idea on this point was to talk about the NAT46 of CPE (CLAT).
    Yes, RFC7915 talks about SIIT independently if it is NAT46 or not.
    Regarding "(IP/ICMP Translation Algorithm) as described by [RFC7915]" it refers just to SIIT.
    As we know, CLAT is a combination of NAT46 + SIIT because it's an stateless translation from IPv4 to IPv6.
    
    >
    >
    > * Introduction:
    > It seems to me the intro contains too many unnecessary details. e.g.,
    > just talk about the CLAT as an abstract concept. Where/how
    > (specifically) it is implemented is mostly irrelevant in the context of
    > this document.
    Yes, I don't know, it could be, as I put above maybe in the introduction we talk about many specific things and we could talk more about the problem itself.
   
    >
    >
    > * Section 4:
    > Is the option where packets might get to the Cache with *private space*
    > worth mentioning/describing/discussing?
 
-> When we talked with CDN/cache providers, they don't like to use non-GUA (example the NAT64 WKP), so it is discussed as an option in approach 1.
 
    I'm sorry I didn't understand it very well.
    What *private space* are you talking about? IPv4 or IPv6?
    If you are talking about IPv6, CDNs normally have IPv6 GUA.
    If you are talking about customers with private IPv4 reaching public IPv4 destination CDNs, yes we could explain it because it is the main scenario we actually some content providers offers to ISPs to deliver content from public IPv4 of CDN to customers with private IPv4 avoiding a CGN platform. That was the first reason to create this document.
   
    >
    >
    > * Section 4.3:
    >   One more advantage of this solution is that the EAMT pairs doesn't
    >   need to match the "real" IPv4/IPv6 addresses available in the A/AAAA
    >   records, as shown in the next example.
    >
    > Please elaborate.
 
-> I think it is clear if you look at the example.
 
    >
    >
    > * Section 5:
    >   If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it can
    >   be complemented to resolve this issue, by means of making sure that
    >   IPv6-only destinations have one A resource record (even an invalid
    >   one), despite they aren't actually connected to IPv4.
    >
    > Not sure what you mean.
 
-> I think it is clear if you read the paragraph before that one. Otherwise we could expand the text to make it more obvious.
 
    It's an idea, we offer different ideas (approaches) to try optimize the traffic flow.
    Here, the idea is that if the destination is IPv6-only, when we have an IPv4-only device, in a normal case you could never reach the destination but if you have this optimization your Proxy DNS could detect that it doesn't have an A record but it has an AAAA record, so you could be connected to the IPv6 destination. Without this, your IPv4-only device would not be able to get the IPv6-only content.
   
    >
    >
    > * Section 5:
    >   In fact, it may become an incentive for the IPv6 deployment in
    >   Internet services and provides the option to use an IPv4 address
    >   (maybe anycast) for the "non-valid" A resource record, that points to
    >   a "universal" web page (maybe hosted by IETF?) that displays a
    >   warning such as "Sorry, you don't IPv6 support in your operator, so
    >   this service is not available for you".
    >
    > Please *no*, for so many different reasons. -- including "the average
    > user doesn't care about IPv6, and may not even be aware of what it is".
 
-> It can be a different text not necessarily mention IPv6 but just "your Internet connection is not able to access this content, please ask your ISP to upgrade it". Anyway, it is very contentious topic ... This probably will get removed in a new version, or moved to an annex, etc.
 
    Ok, it could be, but remember it is another proposal like the other approaches and the idea is to get these kind of inputs.
   
    >
    >
    >
    > * Section 6:
    >   Should we recommend having A records for IPv6-only services in
    >   Internet?  The A record may point to a "reserved" or "special" IPv4
    >   address.  A web page IPv4-only hosted by IETF(?) showing "sorry this
    >   web page/service is only available from IPv6 enabled operators"?.
    >
    > Please no. This assumes (?) hosts prefer IPv6, but they don't need to.
    > In which case they would get to such page and have a not so great
    > WTH(!?) moment.
    >
    >
    >
    > * Section 6:
    >   NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right
    >   solution for optimizing the access to dual-stack services, whether
    >   they are located inside or outside the ISP.
    >
    > It would seem to me that, actually, Approach #3, when the ISP has no
    > control on the CDN, or approach #1 (when it does), are the way to go.
    > Approach #2 seems rather complex, with the consequent opportunities to
    > screw up.
    Approach #1 is not easy to be implemented because content providers doesn't want to be envolved on this process despite agreeing it can be an improvement , so the don't want to do any change in configuration of their devices / interfaces. It applies more in case where CDN is controlled by ISP (own CDN), but we want to define a general solution, we need to consider the normal case of public / external CDNs.
    Approach #3, as you say, it is when ISP doesn't have control of the CDN. This is could not be a very scalable solution because it's not dynamic and any change needs to be propagated to all CPEs. On the other hand it's a very easy method to make a fast deploy where there are not often changes. I think this is a way where that allow to the operator to deploy the solution quickly without depending on complex mechanisms and where content provider doesn't change DNS records, this is the case of Netflix CDN where A and AAAA records always have the same IPs associated for the same FQDN (for CDN).
    Approach #2, yes, clearly it is more complex but it will depends on how much complexity we want to give to the process and we need to define very well which cases we want to consider.
   
   
    >
    >
    > * Section 6:
    >   SIIT already has a SHOULD for EAM support.  Should 464XLAT be updated
    >   by this document so the CLAT has a MUST for EAM support?.
    >
    > 464xlat employs existing technologies. So I'm not sure you can do a MUST
    > in 464xlat, when it relies on SIIT, and for SIIT the requirement is a
    > SHOULD.
    Yes, what you say is valid, these are questions to see exactly what the community thinks.
   
    >
    > Besides, the 464xlat spec does not even employ RFC2119 language.
    >
    >
    >
    > * Section 7:
    >
    > Any solution where you spoof DNS records would play bad with DNSsec.
    > This should at least be discussed.
    >
    >
    > Thanks!
    >
    > Cheers,
    > Fernando
    >
    >
    >
    >
    > On 11/12/19 14:24, Ron Bonica wrote:
    >> Folks,
    >>
    >> 
    >>
    >> Each week between now and IETF 107, we will review and discuss one draft
    >> with an eye towards progressing it.
    >>
    >> 
    >>
    >> This week, please review and comment on
    >> draft-palet-v6ops-464xlat-opt-cdn-caches.
    >>
    >> 
    >>
    >> When reviewing this draft, please indicate whether you think that V6OPS
    >> should adopt it a s a work item.
    >>
    >> 
    >>
    >>                                                       Fred and Ron
    >>
    >> 
    >>
    >>
    >> Juniper Business Use Only
    >>
    >>
    >> _______________________________________________
    >> v6ops mailing list
    >> v6ops@ietf.org
    >>
    >
    >
    > --
    > Fernando Gont
    > SI6 Networks
    > e-mail: fgont@si6networks.com
    > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
    >
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
   
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
   
 
 
 
**********************************************
IPv4 is over
Are you ready for the new Internet ?
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 mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--------------67103B3F52D4A2B4E6B9602F-- From nobody Mon Jan 6 00:51:15 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C8E1200B3 for ; Mon, 6 Jan 2020 00:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6wgxBZI9isk for ; Mon, 6 Jan 2020 00:51:08 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.220]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3721200B4 for ; Mon, 6 Jan 2020 00:51:07 -0800 (PST) HMM_SOURCE_IP: 172.18.0.218:60907.509043774 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-106.121.177.250?logid-DF2BFE0146564E71847755C47D6822FE (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 602492800B5; Mon, 6 Jan 2020 16:51:01 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id DF2BFE0146564E71847755C47D6822FE for lencse@hit.bme.hu; Mon Jan 6 16:51:04 2020 X-Transaction-ID: DF2BFE0146564E71847755C47D6822FE X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Date: Mon, 6 Jan 2020 16:50:59 +0800 From: "xiechf@chinatelecom.cn" To: =?UTF-8?B?TGVuY3NlIEfDoWJvcg==?= , v6ops References: , <2020010616354842655859@chinatelecom.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.14.409[cn] Mime-Version: 1.0 Message-ID: <2020010616505735753161@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart441674543618_=----" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jan 2020 08:51:12 -0000 This is a multi-part message in MIME format. ------=_001_NextPart441674543618_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIEfDoWJvciwNCkkgc2VlLCB0aGFuayB5b3UhDQpDaG9uZ2ZlbmcNCiANCkZyb206IExlbmNz ZSBHw6Fib3INCkRhdGU6IDIwMjAtMDEtMDYgMTY6NDINClRvOiB2Nm9wcw0KU3ViamVjdDogUmU6 IFt2Nm9wc10gZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxhdC1vcHQtY2RuLWNhY2hlcyAqKkNhbGwg Zm9yIEFkb3B0aW9uKioNCg0KDQoxLzYvMjAyMCA5OjM1IEFNIGtlbHRlesOpc3NlbCwgeGllY2hm QGNoaW5hdGVsZWNvbS5jbiDDrXJ0YToNCg0KSGnvvIxKb3JkaSwNCkkgaGF2ZSB0aGUgZm9sbG93 aW5nIGNvbW1lbnRzIGFmdGVyIHJlYWRpbmcgdGhlIGRyYWZ0LA0KMVxUaGlzIGRyYWZ0IGlzIGFi b3V0IElQdjYtb25seSBmb3IgdGhlIGFjY2Nlc3Mgb2YgSVB2NC1vbmx5IGNsaWVudCB0byBkdWFs LXN0YWNrIENETi9DYWNoZXMuIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIG9wZXJhdGlvbiwgZXZl cnkgcG9zc2libGUgYXBwcm9hY2ggcHJvcG9zZWQgc2hvdWxkIG5vdCBwb3NlIGFkZGl0aW9ubCBy ZXF1aXJtZW50cyBmb3IgdGhlIG5ldHdvcmsgY29uZmlndXJhdGlvbi4gDQoyXCBCYXNlZCBvbiBt eSBleHBlcmllbmNlLCBJIHRoaW5rIHRoZSBwb3NzaWJpbGl0eSBvZiBYTEFUIHRvIGJlIHVzZWQg aW4gd2lyZWxpbmUgbmV0d29yayBpcyB2ZXJ5IHNtYWxsLCBJcyB0aGVyZSBhbnkgbGFyZ2Utc2Nh bGUgSVNQIHdobyBwbGFuIHRvIHVzZSBYTEFUIGZvciB3aXJlbGluZSBicm9hZGJhbmQ/IE5lYXJs eSBldmVyeSBJUHY2LWNhcGFibGUgQ1BFIGlzIGR1YWwgc3RhY2ssIGl0IGlzIHZlcnkgZGlmZmlj dWx0IHRvIGNvbnZpbmNlIHRoZSBDUEUgaW5kdXN0cnkgdG8gc3VwcG9ydCBYTEFUIGluIHRoZSBm b3JzZWVuIGZ1dHVyZS4gQW5vdGhlciBmYWN0b3IgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgaXMg dGhhdCB0aGUgSVBUViBzZXJ2aWNlIG9mIHNvbWUgSVNQcyBpcyBjYXJyaWVkIGluIGEgc2VwZXJh dGUgbGF5ZXItdHdvIGNoYW5ubGUsIHdoaWNoIGRvZXMgbm90IG1peCB3aXRoIHRoZSBkZWZhdWx0 IEludGVybmV0IGFjY2VzcyB0cmFmZmljLiAgDQozXEkgZG9uJ3QgdGhpbmsgdGhlIElQIGFkZHJl c3MgMTkyLjAuMi4xIHVzZWQgaW4gdGhlIGV4YW1wbGUgaXMgc3VpdGFibGUsIGZvciB0aGUgSVAg YWRkcmVzcyAxOTIuMC4wLjAvMTYgaGFzIGJlZW4gZGVmaW5lZCB1c2VkIGZvciBzcGVjaWFsIHB1 cnBvc2UsIG1heWJlIHRoZSBwdWJsaWMgSVAgYWRkcmVzcyBpcyBiZXR0ZXIgZm9yIHRoZSBpbnRl cmZhY2Ugb2YgQ0ROIHNlcnZlci4NCg0KMTkyLjAuMi4wLzI0IGlzIHJlc2VydmVkIGZvciBkb2N1 bWVudGF0aW9uIHB1cnBvc2VzLCB0aHVzLCBJTUhPLCBpdCBpcyBpZGVhbCBmb3IgZXhhbXBsZXMu DQoNCg0KQWRkcmVzcyBCbG9jayANCk5hbWUgDQpSRkMgDQpBbGxvY2F0aW9uIERhdGUgDQpUZXJt aW5hdGlvbiBEYXRlIA0KU291cmNlIA0KRGVzdGluYXRpb24gDQpGb3J3YXJkYWJsZSANCkdsb2Jh bGx5IFJlYWNoYWJsZSANClJlc2VydmVkLWJ5LVByb3RvY29sIA0KWy4uLl0NCg0KMTkyLjAuMi4w LzI0IERvY3VtZW50YXRpb24gKFRFU1QtTkVULTEpIFtSRkM1NzM3XSAyMDEwLTAxIE4vQSBGYWxz ZSBGYWxzZSBGYWxzZSBGYWxzZSBGYWxzZSANCg0KU291cmNlOiBodHRwczovL3d3dy5pYW5hLm9y Zy9hc3NpZ25tZW50cy9pYW5hLWlwdjQtc3BlY2lhbC1yZWdpc3RyeS9pYW5hLWlwdjQtc3BlY2lh bC1yZWdpc3RyeS54aHRtbA0KDQpCZXN0IHJlZ2FyZHMsDQoNCkfDoWJvciBMZW5jc2UNCg0KDQoN CiA0XEluIGFkZGl0aW9uLCB0aGUgdGl0bGUgb2YgdGhlIGRyYWZ0ICI0NjRYTEFUIE9wdGltaXph dGlvbiIgaXMgdG9vIGdlbmVyYWwgYW5kIGFtYmlndW91cywgSSB0aGluayBhIG1vcmUgc3BlY2lm aWMgb25lIGlzIGJldHRlci4NCg0KQmVzdCByZWdhcmRzDQoNCkNob25nZmVuZyANCiANCkZyb206 IEpPUkRJIFBBTEVUIE1BUlRJTkVaDQpEYXRlOiAyMDIwLTAxLTA2IDA0OjU2DQpUbzogdjZvcHNA aWV0Zi5vcmcgbGlzdA0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtcGFsZXQtdjZvcHMtNDY0 eGxhdC1vcHQtY2RuLWNhY2hlcyAqKkNhbGwgZm9yIEFkb3B0aW9uKioNCkhpIEZlcm5hbmRvLA0K IA0KQWRkaW5nIHNvbWUgaW5wdXRzLCBiZWxvdywgaW4tbGluZSAoLT4pLg0KIA0K77u/RWwgNC8x LzIwIDQ6MzQsICJ2Nm9wcyBlbiBub21icmUgZGUgQWxlamFuZHJvIEQnRWdpZGlvIiA8djZvcHMt Ym91bmNlc0BpZXRmLm9yZyBlbiBub21icmUgZGUgYWRlZ2lkaW89NDB0ZWxlY2VudHJvLm5ldC5h ckBkbWFyYy5pZXRmLm9yZz4gZXNjcmliacOzOg0KIA0KICAgIEhlbGxvIEZlcm5hbmRvLA0KICAg IA0KICAgIEZpcnN0IGF0IGFsbCwgdGhhbmtzIGZvciB5b3VyIHN1cHBvcnQgdG8gdGhlIHdvcmsg YW5kIHRoZSBkb2N1bWVudCBhbmQgZm9yIHRha2luZyB5b3VyIHRpbWUgdG8gcmVhZCBhbGwgdGhl IGRvY3VtZW50Lg0KICAgIA0KICAgIEkgd2lsbCB0cnkgdG8gYW5zd2VyIHlvdXIgY29tbWVudHMg YmVsb3cuDQogICAgDQogICAgDQogICAgUmVnYXJkcywNCiAgICBBbGVqYW5kcm8NCiAgICANCiAg ICAtLS0tLSBNZW5zYWplIG9yaWdpbmFsIC0tLS0tDQogICAgPiBEZTogIkZlcm5hbmRvIEdvbnQi IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+DQogICAgPiBQYXJhOiAiUm9uIEJvbmljYSIgPHJib25p Y2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4sICJ2Nm9wc0BpZXRmLm9yZyBsaXN0IiA8 djZvcHNAaWV0Zi5vcmc+DQogICAgPiBFbnZpYWRvczogVmllcm5lcywgMyBkZSBFbmVybyAyMDIw IDIwOjQwOjExDQogICAgPiBBc3VudG86IFJlOiBbdjZvcHNdIGRyYWZ0LXBhbGV0LXY2b3BzLTQ2 NHhsYXQtb3B0LWNkbi1jYWNoZXMgKipDYWxsIGZvciBBZG9wdGlvbioqDQogICAgDQogICAgPiBG b2xrcywNCiAgICA+IA0KICAgID4gSSd2ZSByZWFkIHRoZSBkb2N1bWVudCwgYW5kIGhhdmUgdGhl IGZvbGxvd2luZyBjb21tZW50czoNCiAgICA+IA0KICAgID4gSXQgd291bGQgc2VlbSB0byBtZSBp cyB0aGF0IHRoaXMgZG9jdW1lbnQgaGFzIHJlc3VsdGVkIGZyb20gYW4NCiAgICA+IG9wZXJhdG9y cycgY29uY2VybiB0aGF0IGRlcGxveW1lbnQgb2YgNDY0eGxhdCBtaWdodCByZXN1bHQgaW4NCiAg ICA+IHVubmVjZXNzYXJ5IGhlYXZ5d2VpZ2h0IHVzZSBvZiB0aGUgc3RhdGVmdWwgUExBVCwgbGVh ZGluZyB0byBzY2FsYWJpbGl0eQ0KICAgID4gcHJvYmxlbXMgb3IgdW5uZWNlc3NhcnkgbW9uZXkg c3BlbmRpbmdzLiBJbiB0aGF0IHNlbnNlLCBJIHdvdWxkIGxpa2UgdGhlDQogICAgPiBpc3N1ZSB0 byBiZSBkb2N1bWVudGVkIChldmVuIGlmIHNvbWVob3cgd2UgZG9uJ3QgYWdyZWUgb24gYSB3b3Jr YXJvdW5kKS4NCiAgICBZZXMsIGZyb20gb25lIHBvaW50IG9mIHZpZXcgaXQgaXMgY29ycmVjdCB3 aGF0IHlvdSBzYWlkIGFuZCBpbiBhZGRpdGlvbiB0byB0aGF0IHdlIGhhdmUgYW4gdW5uZWNlc3Nh cnkgc2Vjb25kIHRyYW5zbGF0aW9uIChOQVQ2NCkgd2hlbiBjdXN0b21lciB0cmFmZmljIHdhcyB0 cmFuc2xhdGVkIHRvIElQdjYgKE5BVDQ2KSBhbmQgdGhlIGRlc3RpbmF0aW9uIChjb250ZW50KSBp cyBhdmFpbGFibGUgaW4gSVB2NiBhbHNvLCBzbyB3ZSBjb3VsZCBhdm9pZCBib3RoIGEgYm90dGxl bmVjayBhbmQgYSBwZXJmb3JtYW5jZSBpbXBhaXJtZW50LiBUaGF0J3Mgd2h5IHdlIGNvbnNpZGVy IHRoaXMgYXMgYW4gb3B0aW1pemF0aW9uLg0KIA0KLT4gSSB0aGluayB0aGUgZG9jdW1lbnQgaXMg ZG9pbmcgdGhlIHdvcmsgb2YgZG9jdW1lbnRpbmcgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCBw cm92aWRpbmcgcG9zc2libGUgc29sdXRpb25zLCB3aGljaCB0aGUgaWRlYSBvZiBjaG9vc2luZyBv bmUuIFdlIHVuZGVyc3RhbmQgdGhhdCA0NjRYTEFUIHdhcyBub3QgZGVzaWduZWQgaGF2aW5nIHRo aXMgc2NlbmFyaW8gaW4gbWluZCwgYnV0IGlmIHdlIGNhbiBmaW5kIGEgZ29vZCBzb2x1dGlvbiwg aXMgd29ydGggdG8gc29sdmUgaXQuIEZ1cnRoZXJtb3JlLCBpZiB0aGUgV0cgYWdyZWUgdGhhdCB0 aGlzIGlzIHRoZSB3YXkgdG8gZ28sIHdlIGNvdWxkIHVwZGF0ZSB3aXRoIHRoaXMgZG9jdW1lbnQg NDY0WExBVCAod2hpY2ggaXMgYW4gaW5mb3JtYXRpb25hbCBvbmUpIGFuZCBtYWtlIGl0IHRvIHRo ZSBzdGFuZGFyZHMgdHJhY2suIEFzIEkndmUgYWxyZWFkeSBleHByZXNzZWQgc2V2ZXJhbCB0aW1l cywgaXQgaXMgcGl0eSB0aGF0IGJlaW5nIHRoZSB0cmFuc2l0aW9uIG1lY2hhbmlzbSB0aGF0IGlz IG1vcmUgdXNlZCBpbiB0aGUgd29ybGQgKHZlcnN1cyBhbGwgdGhlIG90aGVycywgaW4gdGVybXMg b2YgbnVtYmVyIG9mIGRldmljZXMpLCBpdCBpcyBub3QgYSBzdGFuZGFyZC4NCiAgICANCiAgICAN CiAgICA+IA0KICAgID4gU28gSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50 IChvciBzb21lIHZlcnNpb24gb2YgaXQpIC0tDQogICAgPiBpLmUuLCB0aGVyZSdzIHZhbHVlIGlu IGRvY3VtZW50aW5nIHRoZSBpc3N1ZSBpdHNlbGYuDQogICAgPiANCiAgICA+IFRoYXQgc2FpZCwg SSB0aGluayB0aGF0IGZ1cnRoZXIgd29yayBpcyByZXF1aXJlZCBvbiB0aGUgZG9jdW1lbnQuIFBM ZWFzZQ0KICAgID4gZmluZCBteSByZXZpZXcgYmVsb3c6DQogICAgPiANCiAgICA+IA0KICAgID4g KioqKiBTb21lIG1ldGEgY29tbWVudHMgKioqKg0KICAgID4gDQogICAgPiAqIE1ldGE6IEknZCBw dXQgbW9yZSBzdHJlc3Mgb24gd2h5IHRoaXMgIm9wdGltaXphdGlvbiIgaXMgaW1wb3J0YW50LiBZ b3UNCiAgICA+IGRlbHZlIGludG8gbWFueSBvdGhlciAocmF0aGVyIHVubmVjZXNzYXJ5KSBkZXRh aWxzLCBidXQgZG9uJ3QgZWxhYm9yYXRlDQogICAgPiBtdWNoIHJlZ2FyZGluZyB3aHkgdGhpcyAi b3B0aW1pemF0aW9uIiBpcyBpbXBvcnRhbnQuDQogDQotPiBNeSByZWFkaW5nIGlzIHRoYXQgdGhl IG9wdGltaXphdGlvbiBhbmQgdGhlIG5lZWQgZm9yIGl0IGlzIHdlbGwgZGVzY3JpYmVkLCBidXQg ZGVmaW5pdGl2ZWx5IHdpbGwgdGFrZSBhIGxvb2sgaW50byBpdCBhbmQgaW1wcm92ZSBpdCBpZiBu ZWVkZWQuDQogDQogICAgWWVzLCBpdCBpcyB0cnVlLCBtYXliZSB0aGUgaW50cm9kdWN0aW9uIGNv dWxkIGJlIHNpbXBsZXIgYW5kIG1vcmUgb3JpZW50ZWQgdG8gc2hvdyB0aGUgY29uY3JldGUgcHJv YmxlbSBhbmQgd2h5IHdlIGJlbGlldmUgdGhpcyBpcyBpbXBvcnRhbnQuDQogICAgDQogICAgSSBk b24ndCBrbm93IGlmIHRoZSBpbmZvIGlzIHdyb25nLCBtYXliZSBhIHNwZWNpZmljIGluaXRpYWwg c3VtbWFyeSB0aGF0IGluZGljYXRlcyBpdCBpcyBtaXNzaW5nLiBXZSBjYW4gY29uc2lkZXIgaXQu DQogICAgDQogICAgDQogICAgPiANCiAgICA+ICogTWV0YTogSXQnZCBiZSBpbXBvcnRhbnQgdG8g bm90ZSB0aGF0LCBhY2NvcmRpbmcgdG8gdGhlIEFic3RyYWN0IG9mDQogICAgPiBSRkM2ODc3LCA0 NjRYTEFUIGFzc3VtZXMgSVB2NCBzZXJ2aWNlcyBvdmVyIGFuIElQdjYtb25seSBub2RlLiBJbiB0 aGF0DQogICAgPiBzZW5zZSwgdGhlIGJlaGF2aW9yIHlvdSBkZXNjcmliZSBpcyBraW5kIG9mICJl eHBlY3RlZCIsIGFuZCB3aGF0IHlvdQ0KICAgID4gZGVzY3JpYmUgd291bGQgc2VlbSB0byBtZSBt b3JlIG9mIGEgbWVjaGFuaXNtIHRvICpvcHQgb3V0IG9mIDQ2NHhsYXQqDQogICAgPiB0aGFuIGFu IG9wdGltaXphdGlvbiB0byA0NjRYTEFUIGl0c2VsZi4NCiANCi0+IFllcywgSSBzYWlkIHRoYXQg aW4gbXkgZmlyc3QgY29tbWVudC4gV2l0aCB0aGlzIG9wdGltaXphdGlvbiwgaWYgd2UgYXJlIGFi bGUgdG8gZmluZCBjb25zZW5zdXMgaW4gYSBnb29kIHNvbHV0aW9uLCB3ZSBpbXByb3ZlIHNvbWV0 aGluZyB0aGF0IHdhcyBub3QgaW5pdGlhbGx5IGV4cGVjdGVkIHRvIGJlIGRvbmUgYnkgNDY0WExB VC4gSSBkb24ndCBzZWUgdGhlICJvcHQtb3V0IiBwb2ludCB0aGF0IHlvdSBtZW50aW9uLg0KIA0K ICAgIFllcywgNDY0WExBVCBhc3VtZXMgYm90aCBJUHY0IHNlcnZpY2VzIGFuZCBJUHY0LW9ubHkg ZGV2aWNlcyBhbHNvLg0KICAgIFllcywgdGhpcyBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3Igb2Yg NDY0WExBVCAoYW5kIE1BUC1UIGFsc28pIGJ1dCBmcm9tIGEgcHJhY3RpY2FsIGFuZCBwZXJmb3Jt YW5jZSBwb2ludCBvZiB2aWV3LCBtYXliZSwgaXQgaXMgbm90IHRoZSBtb3N0IG9wdGltYWwgcGF0 aCBmb3IgdGhlIGVuZC10by1lbmQgdHJhZmZpYyBmbG93LiBBcyB5b3Ugc2FpZCBpZiB3ZSBhdm9p ZCB0aGUgTkFUNjQsIHRlY2huaWNhbGx5IHNwZWFraW5nLCB0aGUgdHJhZmZpYyB3aWxsIG5vdCBi ZSBnb2luZyB0aHJvdWdoIGEgNDY0WExBVC9NQVAtVCBzY2VuYXJpby4NCiAgICBXZSBhcmUgbm90 IHNheWluZyB0aGF0IDQ2NFhMQVQgaXMgd3JvbmcgYXQgYWxsLCB3ZSBhcmUgdHJ5aW5nIHRvIGV4 cG9zZSBhIHJlYWwgcHJvYmxlbSBmb3IgSVB2NiBvbmx5IG5ldHdvcmsgZGVwbG95bWVudHMgYW5k IHRyeWluZyB0byBwcmVzZW50IHNvbWUgYXBwcm9hY2hlcyB0byBzb2x2ZSBpdCAob3IgbWluaW1p emUgaXQpLg0KICAgIA0KICAgID4gDQogICAgPiAqIEl0IHdvdWxkIHNlZW0gdG8gbWUgdGhhdCB0 aGUgY2FzZXMgd2hlcmUgdGhpcyBpc3N1ZSBpcyBtb3JlIG9mIGENCiAgICA+IGNvbmNlcm4gaXMg ZXNzZW50aWFsbHkgc21hcnRib3hlcyAoc21hcnQgVFZzKSBjb25zdW1pbmcgbWVkaWEgZnJvbSBs YXJnZQ0KICAgID4gQ0ROcy4gSWYgc28sIHRoaXMgc2hvdWxkIGJlIHNwZWxsZWQgb3V0LCBzaW5j ZSB0aGlzIGVzc2VudGlhbGx5IHNldHMgdGhlDQogICAgPiBjb250ZXh0IGZvciB3aGF0IG9wdGlv bnMvYXBwcm9hY2hlcyBjYW4gYmUgY29uc2lkZXJlZCBhY2NlcHRhYmxlLg0KICAgIE9rLCB5ZXMs IHdlIGNhbiBwdXQgbW9yZSBlZmZvcnQgdG8gZXhwbGFpbiB0aGF0Lg0KICAgICANCiAgICA+IA0K ICAgID4gDQogICAgPiANCiAgICA+ICoqKiBTb21lIHNwZWNpZmljIGNvbW1lbnRzOiAqKioqDQog ICAgPiANCiAgICA+ICogQWJzdHJhY3Q6IEknbSBjdXJpb3VzIGlmIHRoZSB0ZXJtICJOQVQ0NiIg Y2FuIGJlIGNvbmZ1c2luZywgZm9yDQogICAgPiBtdWx0aXBsZSByZWFzb25zIChmb3IgaW5zdGFu Y2UsIGl0J3Mgbm90IHNwZWNpZmllZCBpbiBSRkM3OTE1KS4gSnVzdCB1c2UNCiAgICA+ICJTSUlU IiwgYW5kIHRoZSBjb250ZXh0IChpLmUuLCBkZXNjcmliZSB3aGF0J3Mgb24gZWFjaCBzaWRlIG9m IHRoZSBTSUlUDQogICAgPiBkZXZpY2UsIGFuZCB3aGF0J3MgdGhlIGludGVudCkuDQogDQotPiBJ bml0aWFsbHkgd2Ugd2VyZSB1c2luZyB0aGUgdGVybSBDTEFULCBidXQgdGhlbiB3ZSByZWFsaXpl ZCB0aGF0IE1BUC1UIGhhcyB0aGUgc2FtZSBpc3N1ZSwgYW5kIHRoZXJlIGl0IGlzIG5vdCBjYWxs ZWQgQ0xBVCwgYnV0IE5BVDQ2LiBUaGlzIGlzIHRoZSByZWFzb24sIHF1aXRlIHNpbXBsZSwgYmVj YXVzZSB0aGUgb3B0aW1pemF0aW9uIHdpbGwgYWxzbyB3b3JrIGZvciBNQVAtVC4NCiANCiAgICBX ZSBjYW4gcmV2aWV3IGl0IGlmIGl0IGlzIGNvbmZ1c2luZy4NCiAgICBUaGUgaWRlYSBvbiB0aGlz IHBvaW50IHdhcyB0byB0YWxrIGFib3V0IHRoZSBOQVQ0NiBvZiBDUEUgKENMQVQpLg0KICAgIFll cywgUkZDNzkxNSB0YWxrcyBhYm91dCBTSUlUIGluZGVwZW5kZW50bHkgaWYgaXQgaXMgTkFUNDYg b3Igbm90Lg0KICAgIFJlZ2FyZGluZyAiKElQL0lDTVAgVHJhbnNsYXRpb24gQWxnb3JpdGhtKSBh cyBkZXNjcmliZWQgYnkgW1JGQzc5MTVdIiBpdCByZWZlcnMganVzdCB0byBTSUlULg0KICAgIEFz IHdlIGtub3csIENMQVQgaXMgYSBjb21iaW5hdGlvbiBvZiBOQVQ0NiArIFNJSVQgYmVjYXVzZSBp dCdzIGFuIHN0YXRlbGVzcyB0cmFuc2xhdGlvbiBmcm9tIElQdjQgdG8gSVB2Ni4NCiAgICAgDQog ICAgPiANCiAgICA+IA0KICAgID4gKiBJbnRyb2R1Y3Rpb246DQogICAgPiBJdCBzZWVtcyB0byBt ZSB0aGUgaW50cm8gY29udGFpbnMgdG9vIG1hbnkgdW5uZWNlc3NhcnkgZGV0YWlscy4gZS5nLiwN CiAgICA+IGp1c3QgdGFsayBhYm91dCB0aGUgQ0xBVCBhcyBhbiBhYnN0cmFjdCBjb25jZXB0LiBX aGVyZS9ob3cNCiAgICA+IChzcGVjaWZpY2FsbHkpIGl0IGlzIGltcGxlbWVudGVkIGlzIG1vc3Rs eSBpcnJlbGV2YW50IGluIHRoZSBjb250ZXh0IG9mDQogICAgPiB0aGlzIGRvY3VtZW50Lg0KICAg IFllcywgSSBkb24ndCBrbm93LCBpdCBjb3VsZCBiZSwgYXMgSSBwdXQgYWJvdmUgbWF5YmUgaW4g dGhlIGludHJvZHVjdGlvbiB3ZSB0YWxrIGFib3V0IG1hbnkgc3BlY2lmaWMgdGhpbmdzIGFuZCB3 ZSBjb3VsZCB0YWxrIG1vcmUgYWJvdXQgdGhlIHByb2JsZW0gaXRzZWxmLg0KICAgIA0KICAgID4g DQogICAgPiANCiAgICA+ICogU2VjdGlvbiA0Og0KICAgID4gSXMgdGhlIG9wdGlvbiB3aGVyZSBw YWNrZXRzIG1pZ2h0IGdldCB0byB0aGUgQ2FjaGUgd2l0aCAqcHJpdmF0ZSBzcGFjZSoNCiAgICA+ IHdvcnRoIG1lbnRpb25pbmcvZGVzY3JpYmluZy9kaXNjdXNzaW5nPw0KIA0KLT4gV2hlbiB3ZSB0 YWxrZWQgd2l0aCBDRE4vY2FjaGUgcHJvdmlkZXJzLCB0aGV5IGRvbid0IGxpa2UgdG8gdXNlIG5v bi1HVUEgKGV4YW1wbGUgdGhlIE5BVDY0IFdLUCksIHNvIGl0IGlzIGRpc2N1c3NlZCBhcyBhbiBv cHRpb24gaW4gYXBwcm9hY2ggMS4NCiANCiAgICBJJ20gc29ycnkgSSBkaWRuJ3QgdW5kZXJzdGFu ZCBpdCB2ZXJ5IHdlbGwuDQogICAgV2hhdCAqcHJpdmF0ZSBzcGFjZSogYXJlIHlvdSB0YWxraW5n IGFib3V0PyBJUHY0IG9yIElQdjY/DQogICAgSWYgeW91IGFyZSB0YWxraW5nIGFib3V0IElQdjYs IENETnMgbm9ybWFsbHkgaGF2ZSBJUHY2IEdVQS4NCiAgICBJZiB5b3UgYXJlIHRhbGtpbmcgYWJv dXQgY3VzdG9tZXJzIHdpdGggcHJpdmF0ZSBJUHY0IHJlYWNoaW5nIHB1YmxpYyBJUHY0IGRlc3Rp bmF0aW9uIENETnMsIHllcyB3ZSBjb3VsZCBleHBsYWluIGl0IGJlY2F1c2UgaXQgaXMgdGhlIG1h aW4gc2NlbmFyaW8gd2UgYWN0dWFsbHkgc29tZSBjb250ZW50IHByb3ZpZGVycyBvZmZlcnMgdG8g SVNQcyB0byBkZWxpdmVyIGNvbnRlbnQgZnJvbSBwdWJsaWMgSVB2NCBvZiBDRE4gdG8gY3VzdG9t ZXJzIHdpdGggcHJpdmF0ZSBJUHY0IGF2b2lkaW5nIGEgQ0dOIHBsYXRmb3JtLiBUaGF0IHdhcyB0 aGUgZmlyc3QgcmVhc29uIHRvIGNyZWF0ZSB0aGlzIGRvY3VtZW50Lg0KICAgIA0KICAgID4gDQog ICAgPiANCiAgICA+ICogU2VjdGlvbiA0LjM6DQogICAgPiAgIE9uZSBtb3JlIGFkdmFudGFnZSBv ZiB0aGlzIHNvbHV0aW9uIGlzIHRoYXQgdGhlIEVBTVQgcGFpcnMgZG9lc24ndA0KICAgID4gICBu ZWVkIHRvIG1hdGNoIHRoZSAicmVhbCIgSVB2NC9JUHY2IGFkZHJlc3NlcyBhdmFpbGFibGUgaW4g dGhlIEEvQUFBQQ0KICAgID4gICByZWNvcmRzLCBhcyBzaG93biBpbiB0aGUgbmV4dCBleGFtcGxl Lg0KICAgID4gDQogICAgPiBQbGVhc2UgZWxhYm9yYXRlLg0KIA0KLT4gSSB0aGluayBpdCBpcyBj bGVhciBpZiB5b3UgbG9vayBhdCB0aGUgZXhhbXBsZS4NCiANCiAgICA+IA0KICAgID4gDQogICAg PiAqIFNlY3Rpb24gNToNCiAgICA+ICAgSWYgTkFUNDYvQ0xBVC9ETlMtcHJveHktRUFNIGFwcHJv YWNoIChTZWN0aW9uIDQuMikgaXMgY2hvc2VuLCBpdCBjYW4NCiAgICA+ICAgYmUgY29tcGxlbWVu dGVkIHRvIHJlc29sdmUgdGhpcyBpc3N1ZSwgYnkgbWVhbnMgb2YgbWFraW5nIHN1cmUgdGhhdA0K ICAgID4gICBJUHY2LW9ubHkgZGVzdGluYXRpb25zIGhhdmUgb25lIEEgcmVzb3VyY2UgcmVjb3Jk IChldmVuIGFuIGludmFsaWQNCiAgICA+ICAgb25lKSwgZGVzcGl0ZSB0aGV5IGFyZW4ndCBhY3R1 YWxseSBjb25uZWN0ZWQgdG8gSVB2NC4NCiAgICA+IA0KICAgID4gTm90IHN1cmUgd2hhdCB5b3Ug bWVhbi4NCiANCi0+IEkgdGhpbmsgaXQgaXMgY2xlYXIgaWYgeW91IHJlYWQgdGhlIHBhcmFncmFw aCBiZWZvcmUgdGhhdCBvbmUuIE90aGVyd2lzZSB3ZSBjb3VsZCBleHBhbmQgdGhlIHRleHQgdG8g bWFrZSBpdCBtb3JlIG9idmlvdXMuDQogDQogICAgSXQncyBhbiBpZGVhLCB3ZSBvZmZlciBkaWZm ZXJlbnQgaWRlYXMgKGFwcHJvYWNoZXMpIHRvIHRyeSBvcHRpbWl6ZSB0aGUgdHJhZmZpYyBmbG93 Lg0KICAgIEhlcmUsIHRoZSBpZGVhIGlzIHRoYXQgaWYgdGhlIGRlc3RpbmF0aW9uIGlzIElQdjYt b25seSwgd2hlbiB3ZSBoYXZlIGFuIElQdjQtb25seSBkZXZpY2UsIGluIGEgbm9ybWFsIGNhc2Ug eW91IGNvdWxkIG5ldmVyIHJlYWNoIHRoZSBkZXN0aW5hdGlvbiBidXQgaWYgeW91IGhhdmUgdGhp cyBvcHRpbWl6YXRpb24geW91ciBQcm94eSBETlMgY291bGQgZGV0ZWN0IHRoYXQgaXQgZG9lc24n dCBoYXZlIGFuIEEgcmVjb3JkIGJ1dCBpdCBoYXMgYW4gQUFBQSByZWNvcmQsIHNvIHlvdSBjb3Vs ZCBiZSBjb25uZWN0ZWQgdG8gdGhlIElQdjYgZGVzdGluYXRpb24uIFdpdGhvdXQgdGhpcywgeW91 ciBJUHY0LW9ubHkgZGV2aWNlIHdvdWxkIG5vdCBiZSBhYmxlIHRvIGdldCB0aGUgSVB2Ni1vbmx5 IGNvbnRlbnQuDQogICAgDQogICAgPiANCiAgICA+IA0KICAgID4gKiBTZWN0aW9uIDU6DQogICAg PiAgIEluIGZhY3QsIGl0IG1heSBiZWNvbWUgYW4gaW5jZW50aXZlIGZvciB0aGUgSVB2NiBkZXBs b3ltZW50IGluDQogICAgPiAgIEludGVybmV0IHNlcnZpY2VzIGFuZCBwcm92aWRlcyB0aGUgb3B0 aW9uIHRvIHVzZSBhbiBJUHY0IGFkZHJlc3MNCiAgICA+ICAgKG1heWJlIGFueWNhc3QpIGZvciB0 aGUgIm5vbi12YWxpZCIgQSByZXNvdXJjZSByZWNvcmQsIHRoYXQgcG9pbnRzIHRvDQogICAgPiAg IGEgInVuaXZlcnNhbCIgd2ViIHBhZ2UgKG1heWJlIGhvc3RlZCBieSBJRVRGPykgdGhhdCBkaXNw bGF5cyBhDQogICAgPiAgIHdhcm5pbmcgc3VjaCBhcyAiU29ycnksIHlvdSBkb24ndCBJUHY2IHN1 cHBvcnQgaW4geW91ciBvcGVyYXRvciwgc28NCiAgICA+ICAgdGhpcyBzZXJ2aWNlIGlzIG5vdCBh dmFpbGFibGUgZm9yIHlvdSIuDQogICAgPiANCiAgICA+IFBsZWFzZSAqbm8qLCBmb3Igc28gbWFu eSBkaWZmZXJlbnQgcmVhc29ucy4gLS0gaW5jbHVkaW5nICJ0aGUgYXZlcmFnZQ0KICAgID4gdXNl ciBkb2Vzbid0IGNhcmUgYWJvdXQgSVB2NiwgYW5kIG1heSBub3QgZXZlbiBiZSBhd2FyZSBvZiB3 aGF0IGl0IGlzIi4NCiANCi0+IEl0IGNhbiBiZSBhIGRpZmZlcmVudCB0ZXh0IG5vdCBuZWNlc3Nh cmlseSBtZW50aW9uIElQdjYgYnV0IGp1c3QgInlvdXIgSW50ZXJuZXQgY29ubmVjdGlvbiBpcyBu b3QgYWJsZSB0byBhY2Nlc3MgdGhpcyBjb250ZW50LCBwbGVhc2UgYXNrIHlvdXIgSVNQIHRvIHVw Z3JhZGUgaXQiLiBBbnl3YXksIGl0IGlzIHZlcnkgY29udGVudGlvdXMgdG9waWMgLi4uIFRoaXMg cHJvYmFibHkgd2lsbCBnZXQgcmVtb3ZlZCBpbiBhIG5ldyB2ZXJzaW9uLCBvciBtb3ZlZCB0byBh biBhbm5leCwgZXRjLg0KIA0KICAgIE9rLCBpdCBjb3VsZCBiZSwgYnV0IHJlbWVtYmVyIGl0IGlz IGFub3RoZXIgcHJvcG9zYWwgbGlrZSB0aGUgb3RoZXIgYXBwcm9hY2hlcyBhbmQgdGhlIGlkZWEg aXMgdG8gZ2V0IHRoZXNlIGtpbmQgb2YgaW5wdXRzLg0KICAgIA0KICAgID4gDQogICAgPiANCiAg ICA+IA0KICAgID4gKiBTZWN0aW9uIDY6DQogICAgPiAgIFNob3VsZCB3ZSByZWNvbW1lbmQgaGF2 aW5nIEEgcmVjb3JkcyBmb3IgSVB2Ni1vbmx5IHNlcnZpY2VzIGluDQogICAgPiAgIEludGVybmV0 PyAgVGhlIEEgcmVjb3JkIG1heSBwb2ludCB0byBhICJyZXNlcnZlZCIgb3IgInNwZWNpYWwiIElQ djQNCiAgICA+ICAgYWRkcmVzcy4gIEEgd2ViIHBhZ2UgSVB2NC1vbmx5IGhvc3RlZCBieSBJRVRG KD8pIHNob3dpbmcgInNvcnJ5IHRoaXMNCiAgICA+ICAgd2ViIHBhZ2Uvc2VydmljZSBpcyBvbmx5 IGF2YWlsYWJsZSBmcm9tIElQdjYgZW5hYmxlZCBvcGVyYXRvcnMiPy4NCiAgICA+IA0KICAgID4g UGxlYXNlIG5vLiBUaGlzIGFzc3VtZXMgKD8pIGhvc3RzIHByZWZlciBJUHY2LCBidXQgdGhleSBk b24ndCBuZWVkIHRvLg0KICAgID4gSW4gd2hpY2ggY2FzZSB0aGV5IHdvdWxkIGdldCB0byBzdWNo IHBhZ2UgYW5kIGhhdmUgYSBub3Qgc28gZ3JlYXQNCiAgICA+IFdUSCghPykgbW9tZW50Lg0KICAg ID4gDQogICAgPiANCiAgICA+IA0KICAgID4gKiBTZWN0aW9uIDY6DQogICAgPiAgIE5BVDQ2L0NM QVQvRE5TLXByb3h5LUVBTSBhcHByb2FjaCAoU2VjdGlvbiA0LjIpIHNlZW1zIHRoZSByaWdodA0K ICAgID4gICBzb2x1dGlvbiBmb3Igb3B0aW1pemluZyB0aGUgYWNjZXNzIHRvIGR1YWwtc3RhY2sg c2VydmljZXMsIHdoZXRoZXINCiAgICA+ICAgdGhleSBhcmUgbG9jYXRlZCBpbnNpZGUgb3Igb3V0 c2lkZSB0aGUgSVNQLg0KICAgID4gDQogICAgPiBJdCB3b3VsZCBzZWVtIHRvIG1lIHRoYXQsIGFj dHVhbGx5LCBBcHByb2FjaCAjMywgd2hlbiB0aGUgSVNQIGhhcyBubw0KICAgID4gY29udHJvbCBv biB0aGUgQ0ROLCBvciBhcHByb2FjaCAjMSAod2hlbiBpdCBkb2VzKSwgYXJlIHRoZSB3YXkgdG8g Z28uDQogICAgPiBBcHByb2FjaCAjMiBzZWVtcyByYXRoZXIgY29tcGxleCwgd2l0aCB0aGUgY29u c2VxdWVudCBvcHBvcnR1bml0aWVzIHRvDQogICAgPiBzY3JldyB1cC4NCiAgICBBcHByb2FjaCAj MSBpcyBub3QgZWFzeSB0byBiZSBpbXBsZW1lbnRlZCBiZWNhdXNlIGNvbnRlbnQgcHJvdmlkZXJz IGRvZXNuJ3Qgd2FudCB0byBiZSBlbnZvbHZlZCBvbiB0aGlzIHByb2Nlc3MgZGVzcGl0ZSBhZ3Jl ZWluZyBpdCBjYW4gYmUgYW4gaW1wcm92ZW1lbnQgLCBzbyB0aGUgZG9uJ3Qgd2FudCB0byBkbyBh bnkgY2hhbmdlIGluIGNvbmZpZ3VyYXRpb24gb2YgdGhlaXIgZGV2aWNlcyAvIGludGVyZmFjZXMu IEl0IGFwcGxpZXMgbW9yZSBpbiBjYXNlIHdoZXJlIENETiBpcyBjb250cm9sbGVkIGJ5IElTUCAo b3duIENETiksIGJ1dCB3ZSB3YW50IHRvIGRlZmluZSBhIGdlbmVyYWwgc29sdXRpb24sIHdlIG5l ZWQgdG8gY29uc2lkZXIgdGhlIG5vcm1hbCBjYXNlIG9mIHB1YmxpYyAvIGV4dGVybmFsIENETnMu DQogICAgQXBwcm9hY2ggIzMsIGFzIHlvdSBzYXksIGl0IGlzIHdoZW4gSVNQIGRvZXNuJ3QgaGF2 ZSBjb250cm9sIG9mIHRoZSBDRE4uIFRoaXMgaXMgY291bGQgbm90IGJlIGEgdmVyeSBzY2FsYWJs ZSBzb2x1dGlvbiBiZWNhdXNlIGl0J3Mgbm90IGR5bmFtaWMgYW5kIGFueSBjaGFuZ2UgbmVlZHMg dG8gYmUgcHJvcGFnYXRlZCB0byBhbGwgQ1BFcy4gT24gdGhlIG90aGVyIGhhbmQgaXQncyBhIHZl cnkgZWFzeSBtZXRob2QgdG8gbWFrZSBhIGZhc3QgZGVwbG95IHdoZXJlIHRoZXJlIGFyZSBub3Qg b2Z0ZW4gY2hhbmdlcy4gSSB0aGluayB0aGlzIGlzIGEgd2F5IHdoZXJlIHRoYXQgYWxsb3cgdG8g dGhlIG9wZXJhdG9yIHRvIGRlcGxveSB0aGUgc29sdXRpb24gcXVpY2tseSB3aXRob3V0IGRlcGVu ZGluZyBvbiBjb21wbGV4IG1lY2hhbmlzbXMgYW5kIHdoZXJlIGNvbnRlbnQgcHJvdmlkZXIgZG9l c24ndCBjaGFuZ2UgRE5TIHJlY29yZHMsIHRoaXMgaXMgdGhlIGNhc2Ugb2YgTmV0ZmxpeCBDRE4g d2hlcmUgQSBhbmQgQUFBQSByZWNvcmRzIGFsd2F5cyBoYXZlIHRoZSBzYW1lIElQcyBhc3NvY2lh dGVkIGZvciB0aGUgc2FtZSBGUUROIChmb3IgQ0ROKS4NCiAgICBBcHByb2FjaCAjMiwgeWVzLCBj bGVhcmx5IGl0IGlzIG1vcmUgY29tcGxleCBidXQgaXQgd2lsbCBkZXBlbmRzIG9uIGhvdyBtdWNo IGNvbXBsZXhpdHkgd2Ugd2FudCB0byBnaXZlIHRvIHRoZSBwcm9jZXNzIGFuZCB3ZSBuZWVkIHRv IGRlZmluZSB2ZXJ5IHdlbGwgd2hpY2ggY2FzZXMgd2Ugd2FudCB0byBjb25zaWRlci4NCiAgICAN CiAgICANCiAgICA+IA0KICAgID4gDQogICAgPiAqIFNlY3Rpb24gNjoNCiAgICA+ICAgU0lJVCBh bHJlYWR5IGhhcyBhIFNIT1VMRCBmb3IgRUFNIHN1cHBvcnQuICBTaG91bGQgNDY0WExBVCBiZSB1 cGRhdGVkDQogICAgPiAgIGJ5IHRoaXMgZG9jdW1lbnQgc28gdGhlIENMQVQgaGFzIGEgTVVTVCBm b3IgRUFNIHN1cHBvcnQ/Lg0KICAgID4gDQogICAgPiA0NjR4bGF0IGVtcGxveXMgZXhpc3Rpbmcg dGVjaG5vbG9naWVzLiBTbyBJJ20gbm90IHN1cmUgeW91IGNhbiBkbyBhIE1VU1QNCiAgICA+IGlu IDQ2NHhsYXQsIHdoZW4gaXQgcmVsaWVzIG9uIFNJSVQsIGFuZCBmb3IgU0lJVCB0aGUgcmVxdWly ZW1lbnQgaXMgYQ0KICAgID4gU0hPVUxELg0KICAgIFllcywgd2hhdCB5b3Ugc2F5IGlzIHZhbGlk LCB0aGVzZSBhcmUgcXVlc3Rpb25zIHRvIHNlZSBleGFjdGx5IHdoYXQgdGhlIGNvbW11bml0eSB0 aGlua3MuDQogICAgDQogICAgPiANCiAgICA+IEJlc2lkZXMsIHRoZSA0NjR4bGF0IHNwZWMgZG9l cyBub3QgZXZlbiBlbXBsb3kgUkZDMjExOSBsYW5ndWFnZS4NCiAgICA+IA0KICAgID4gDQogICAg PiANCiAgICA+ICogU2VjdGlvbiA3Og0KICAgID4gDQogICAgPiBBbnkgc29sdXRpb24gd2hlcmUg eW91IHNwb29mIEROUyByZWNvcmRzIHdvdWxkIHBsYXkgYmFkIHdpdGggRE5Tc2VjLg0KICAgID4g VGhpcyBzaG91bGQgYXQgbGVhc3QgYmUgZGlzY3Vzc2VkLg0KICAgID4gDQogICAgPiANCiAgICA+ IFRoYW5rcyENCiAgICA+IA0KICAgID4gQ2hlZXJzLA0KICAgID4gRmVybmFuZG8NCiAgICA+IA0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gT24gMTEvMTIvMTkgMTQ6MjQsIFJvbiBCb25p Y2Egd3JvdGU6DQogICAgPj4gRm9sa3MsDQogICAgPj4gDQogICAgPj4gIA0KICAgID4+IA0KICAg ID4+IEVhY2ggd2VlayBiZXR3ZWVuIG5vdyBhbmQgSUVURiAxMDcsIHdlIHdpbGwgcmV2aWV3IGFu ZCBkaXNjdXNzIG9uZSBkcmFmdA0KICAgID4+IHdpdGggYW4gZXllIHRvd2FyZHMgcHJvZ3Jlc3Np bmcgaXQuDQogICAgPj4gDQogICAgPj4gIA0KICAgID4+IA0KICAgID4+IFRoaXMgd2VlaywgcGxl YXNlIHJldmlldyBhbmQgY29tbWVudCBvbg0KICAgID4+IGRyYWZ0LXBhbGV0LXY2b3BzLTQ2NHhs YXQtb3B0LWNkbi1jYWNoZXMuDQogICAgPj4gDQogICAgPj4gIA0KICAgID4+IA0KICAgID4+IFdo ZW4gcmV2aWV3aW5nIHRoaXMgZHJhZnQsIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSB0aGlu ayB0aGF0IFY2T1BTDQogICAgPj4gc2hvdWxkIGFkb3B0IGl0IGEgcyBhIHdvcmsgaXRlbS4NCiAg ICA+PiANCiAgICA+PiAgDQogICAgPj4gDQogICAgPj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJlZCBhbmQgUm9uDQogICAgPj4gDQogICAg Pj4gIA0KICAgID4+IA0KICAgID4+IA0KICAgID4+IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkN CiAgICA+PiANCiAgICA+PiANCiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgID4+IHY2b3BzIG1haWxpbmcgbGlzdA0KICAgID4+IHY2b3Bz QGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KICAgID4+IA0KICAgID4gDQogICAgPiANCiAgICA+IC0tDQogICAgPiBGZXJuYW5kbyBH b250DQogICAgPiBTSTYgTmV0d29ya3MNCiAgICA+IGUtbWFpbDogZmdvbnRAc2k2bmV0d29ya3Mu Y29tDQogICAgPiBQR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZCMSBFM0M0 IEFFMjUgMEQ1NSAxRDRFIDc0OTINCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAg ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ IHY2b3BzIG1haWxpbmcgbGlzdA0KICAgID4gdjZvcHNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCiAgICANCiAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHY2b3BzIG1haWxpbmcg bGlzdA0KICAgIHY2b3BzQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcw0KICAgIA0KIA0KIA0KIA0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KSVB2NCBpcyBvdmVyDQpBcmUgeW91IHJlYWR5IGZvciB0 aGUgbmV3IEludGVybmV0ID8NCmh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tDQpUaGUgSVB2 NiBDb21wYW55DQogDQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlv biB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlv biBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBk aXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBv ZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVk IGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBj cmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJl IGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ug b2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBp bmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUg Y29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBv cmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVs ZXRlIGl0Lg0KIA0KIA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KdjZvcHMgbWFpbGluZyBsaXN0CnY2b3BzQGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMKDQo= ------=_001_NextPart441674543618_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0A =0A
Hi, G=C3=A1bor,
I see, thank you!
Ch= ongfeng
=0A
 
Date: 2020-01-06 16:42
To: v6ops
= Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **C= all for Adoption**
=0A =0A =0A =0A =0A
=0A
=0A
1/6/2020 9:35 AM keltez=C3=A9ssel,=0A xiechf@chin= atelecom.cn =C3=ADrta:
=0A
=0A
=0A =0A =0A =

=0A
=0A
=0A
Hi=EF=BC=8CJordi,
=0A
I have the = following comments after reading the draft,
=0A
1\This dr= aft is about IPv6-only for the acccess of=0A IPv4-only client to = dual-stack CDN/Caches. From the=0A perspective of operation, ever= y possible approach proposed=0A should not pose additionl requirm= ents for the network=0A configuration. 
=0A 2\ Based on my experience, I think the possibility of XLAT=0A to= be used in wireline network is very small, Is there any=0A large= -scale ISP who plan to use XLAT for wireline broadband?=0A Nearly= every IPv6-capable CPE is dual stack, it is very=0A difficult to= convince the CPE industry to support XLAT in the=0A forseen futu= re. Another factor that we should consider is that=0A the IPTV se= rvice of some ISPs is carried in a seperate=0A layer-two channle,= which does not mix with the default=0A Internet access traffic. =  
=0A
3\I don't think the IP address 192.0.2.1 used = in the=0A example is suitable, for the IP address 192.0.0.0/16 ha= s been=0A defined used for special purpose, maybe the public IP a= ddress=0A is better for the interface of CDN server.
=0A =
=0A
=0A
=0A 192.0.2.0/24 is reserved for= documentation purposes, thus, IMHO, it=0A is ideal for examples.
= =0A
=0A
=0A =0A =0A =0A =0A =0A = =0A =0A =0A =0A =0A = =0A =0A =0A =0A
Address Block = Name RFC Allocation Date = Termination Date Source <= img style=3D"vertical-align:middle" src=3D"https://www.iana.org/assignment= s/_support/sort_none.gif">Destination Forwardable = Globally Reachable Reserved-by-Protocol
=0A [...]
=0A
=0A =0A =0A =0A =0A =0A =0A =0A =0A = =0A =0A =0A =0A = =0A =0A
192.0.2.0/24Documentation (TEST-N= ET-1)[RF= C5737]2010-01N/AFalseFalseFalse=0A FalseFalse
=0A
=0A Source:=0Ahttps://www.iana.org/assi= gnments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml=0A
=0A Best regards,
=0A
=0A G=C3=A1bor Lencse=0A
=0A
=0A
=0A
=0A
=0A
 = 4\In addition, the title of the draft "464XLAT=0A Optimization" i= s too general and ambiguous, I think a more=0A specific one is be= tter.
=0A

=0A
=0A
Best regar= ds
=0A

=0A
=0A
Chongfeng&nbs= p;
=0A
=0A
=0A
 
= =0A
=0A
=0A =0A
Date: 2020-01-06&= nbsp;04:56
=0A =0A =
Subject: Re: [v6ops]=0A draft-palet-v= 6ops-464xlat-opt-cdn-caches **Call for=0A Adoption**
=0A=
=0A
=0A
=0A
Hi Fern= ando,
=0A
 
=0A
Adding some inp= uts, below, in-line (->).
=0A
=0A
=0A
 
=0A =0A
 
=0A
&n= bsp;   Hello Fernando,
=0A
   =
=0A
    First at all, thanks for your = support to the work and=0A the document and for taking your tim= e to read all the=0A document.
=0A
 &nb= sp; 
=0A
    I will try to answer = your comments below.
=0A
   
=0A =
   
=0A
   = Regards,
=0A
    Alejandro
=0A =
   
=0A
    -= ---- Mensaje original -----
=0A = =0A =0A
&= nbsp;   > Enviados: Viernes, 3 de Enero 2020 20:40:11
= =0A
    > Asunto: Re: [v6ops]=0A = draft-palet-v6ops-464xlat-opt-cdn-caches **Call for=0A Adopti= on**
=0A
   
=0A
&nb= sp;   > Folks,
=0A
    >=
=0A
    > I've read the document, a= nd have the following=0A comments:
=0A
 = ;   >
=0A
    > It woul= d seem to me is that this document has=0A resulted from an=0A
    > operators' concern that deploym= ent of 464xlat=0A might result in
=0A
 =    > unnecessary heavyweight use of the stateful=0A = PLAT, leading to scalability
=0A
    &= gt; problems or unnecessary money spendings. In that=0A sense, = I would like the
=0A
    > issue to b= e documented (even if somehow we don't=0A agree on a workaround= ).
=0A
    Yes, from one point of view i= t is correct what you=0A said and in addition to that we have a= n unnecessary second=0A translation (NAT64) when customer traff= ic was translated to=0A IPv6 (NAT46) and the destination (conte= nt) is available in=0A IPv6 also, so we could avoid both a bott= leneck and a=0A performance impairment. That's why we consider = this as an=0A optimization.
=0A
 
= =0A
-> I think the document is doing the work of=0A = documenting the problem statement and providing possible=0A = solutions, which the idea of choosing one. We understand=0A = that 464XLAT was not designed having this scenario in mind,=0A = but if we can find a good solution, is worth to solve it.=0A Fu= rthermore, if the WG agree that this is the way to go, we=0A co= uld update with this document 464XLAT (which is an=0A informati= onal one) and make it to the standards track. As=0A I've alread= y expressed several times, it is pity that being=0A the transit= ion mechanism that is more used in the world=0A (versus all the= others, in terms of number of devices), it=0A is not a standar= d.
=0A
   
=0A
 = ;  
=0A
    >
=0A =
    > So I support the adoption of this docu= ment (or=0A some version of it) --
=0A
 = ;   > i.e., there's value in documenting the issue=0A = itself.
=0A
    >
=0A =
    > That said, I think that further work is r= equired=0A on the document. PLease
=0A
 = ;   > find my review below:
=0A
 &nbs= p;  >
=0A
    >
=0A =
    > **** Some meta comments ****
=0A =
    >
=0A
  =   > * Meta: I'd put more stress on why this=0A "optimiz= ation" is important. You
=0A
    > de= lve into many other (rather unnecessary)=0A details, but don't = elaborate
=0A
    > much regarding wh= y this "optimization" is=0A important.
=0A
&= nbsp;
=0A
-> My reading is that the optimization and= the need=0A for it is well described, but definitively will ta= ke a look=0A into it and improve it if needed.
=0A =
 
=0A
    Yes, it is true, m= aybe the introduction could be=0A simpler and more oriented to = show the concrete problem and=0A why we believe this is importa= nt.
=0A
   
=0A
&nbs= p;   I don't know if the info is wrong, maybe a specific=0A = initial summary that indicates it is missing. We can=0A = consider it.
=0A
   
=0A =
   
=0A
    > =0A
    > * Meta: It'd be important to= note that,=0A according to the Abstract of
=0A <= div>    > RFC6877, 464XLAT assumes IPv4 services over an= =0A IPv6-only node. In that
=0A
  =   > sense, the behavior you describe is kind of=0A "exp= ected", and what you
=0A
    > descri= be would seem to me more of a mechanism to=0A *opt out of 464xl= at*
=0A
    > than an optimization to= 464XLAT itself.
=0A
 
=0A
->= ; Yes, I said that in my first comment. With this=0A optimizati= on, if we are able to find consensus in a good=0A solution, we = improve something that was not initially=0A expected to be done= by 464XLAT. I don't see the "opt-out"=0A point that you mentio= n.
=0A
 
=0A
   = Yes, 464XLAT asumes both IPv4 services and IPv4-only=0A device= s also.
=0A
    Yes, this is the expecte= d behavior of 464XLAT (and=0A MAP-T also) but from a practical = and performance point of=0A view, maybe, it is not the most opt= imal path for the=0A end-to-end traffic flow. As you said if we= avoid the NAT64,=0A technically speaking, the traffic will not= be going through=0A a 464XLAT/MAP-T scenario.
=0A =
    We are not saying that 464XLAT is wrong at all, = we=0A are trying to expose a real problem for IPv6 only network= =0A deployments and trying to present some approaches to solve= =0A it (or minimize it).
=0A
  &nb= sp;
=0A
    >
=0A     > * It would seem to me that the cases where this= =0A issue is more of a
=0A
   = ; > concern is essentially smartboxes (smart TVs)=0A consumi= ng media from large
=0A
    > CDNs. I= f so, this should be spelled out, since=0A this essentially set= s the
=0A
    > context for what opti= ons/approaches can be=0A considered acceptable.
=0A =
    Ok, yes, we can put more effort to explain that= .
=0A
    
=0A
=     >
=0A
    > =0A
    >
=0A
&nbs= p;   > *** Some specific comments: ****
=0A     >
=0A
    > = * Abstract: I'm curious if the term "NAT46" can=0A be confusing= , for
=0A
    > multiple reasons (for= instance, it's not=0A specified in RFC7915). Just use
=0A=
    > "SIIT", and the context (i.e., desc= ribe what's=0A on each side of the SIIT
=0A
=     > device, and what's the intent).
=0A =
 
=0A
-> Initially we were using the term = CLAT, but then we=0A realized that MAP-T has the same issue, an= d there it is not=0A called CLAT, but NAT46. This is the reason= , quite simple,=0A because the optimization will also work for = MAP-T.
=0A
 
=0A
  &n= bsp; We can review it if it is confusing.
=0A
 &nb= sp;  The idea on this point was to talk about the NAT46 of=0A = CPE (CLAT).
=0A
    Yes, RFC7915 tal= ks about SIIT independently if it is=0A NAT46 or not.
=0A =
    Regarding "(IP/ICMP Translation Algorithm= ) as=0A described by [RFC7915]" it refers just to SIIT.
= =0A
    As we know, CLAT is a combination of = NAT46 + SIIT=0A because it's an stateless translation from IPv4= to IPv6.
=0A
    
=0A =
    >
=0A
   = >
=0A
    > * Introduction:=0A
    > It seems to me the intro contai= ns too many=0A unnecessary details. e.g.,
=0A     > just talk about the CLAT as an abstract concept.= =0A Where/how
=0A
    > (s= pecifically) it is implemented is mostly=0A irrelevant in the c= ontext of
=0A
    > this document.=0A
    Yes, I don't know, it could be, as= I put above maybe=0A in the introduction we talk about many sp= ecific things and=0A we could talk more about the problem itsel= f.
=0A
   
=0A
 = ;   >
=0A
    >
= =0A
    > * Section 4:
=0A <= div>    > Is the option where packets might get to the= =0A Cache with *private space*
=0A
 &nb= sp;  > worth mentioning/describing/discussing?
=0A <= div> =0A
-> When we talked with CDN/cache prov= iders, they don't=0A like to use non-GUA (example the NAT64 WKP= ), so it is=0A discussed as an option in approach 1.
=0A =
 
=0A
    I'm sorry I = didn't understand it very well.
=0A
    = What *private space* are you talking about? IPv4 or=0A IPv6?=0A
    If you are talking about IPv6, CDN= s normally have=0A IPv6 GUA.
=0A
  = ;  If you are talking about customers with private IPv4=0A = reaching public IPv4 destination CDNs, yes we could explain=0A = it because it is the main scenario we actually some content=0A = providers offers to ISPs to deliver content from public IPv4=0A = of CDN to customers with private IPv4 avoiding a CGN=0A platf= orm. That was the first reason to create this document.
=0A =
   
=0A
    > =0A
    >
=0A
&nbs= p;   > * Section 4.3:
=0A
  &nbs= p; >   One more advantage of this solution is that=0A = the EAMT pairs doesn't
=0A
    >&= nbsp;  need to match the "real" IPv4/IPv6 addresses=0A ava= ilable in the A/AAAA
=0A
    > &= nbsp; records, as shown in the next example.
=0A
 =    >
=0A
    > Please e= laborate.
=0A
 
=0A
-> I thi= nk it is clear if you look at the example.
=0A
 =0A
    >
=0A
&nbs= p;   >
=0A
    > * Sect= ion 5:
=0A
    >   If NAT46= /CLAT/DNS-proxy-EAM approach (Section=0A 4.2) is chosen, it can=
=0A
    >   be complemente= d to resolve this issue, by=0A means of making sure that
= =0A
    >   IPv6-only destinatio= ns have one A resource=0A record (even an invalid
=0A =
    >   one), despite they aren't ac= tually connected=0A to IPv4.
=0A
  = ;  >
=0A
    > Not sure what= you mean.
=0A
 
=0A
-> I th= ink it is clear if you read the paragraph=0A before that one. O= therwise we could expand the text to make=0A it more obvious.=0A
 
=0A
    It'= s an idea, we offer different ideas (approaches)=0A to try opti= mize the traffic flow.
=0A
    Here, the= idea is that if the destination is=0A IPv6-only, when we have = an IPv4-only device, in a normal=0A case you could never reach = the destination but if you have=0A this optimization your Proxy= DNS could detect that it=0A doesn't have an A record but it ha= s an AAAA record, so you=0A could be connected to the IPv6 dest= ination. Without this,=0A your IPv4-only device would not be ab= le to get the IPv6-only=0A content.
=0A
&nbs= p;  
=0A
    >
=0A =
    >
=0A
  &= nbsp; > * Section 5:
=0A
    >&nbs= p;  In fact, it may become an incentive for the=0A IPv6 de= ployment in
=0A
    >   Int= ernet services and provides the option to=0A use an IPv4 addres= s
=0A
    >   (maybe anycas= t) for the "non-valid" A resource=0A record, that points to=0A
    >   a "universal" web = page (maybe hosted by IETF?)=0A that displays a
=0A =
    >   warning such as "Sorry, you do= n't IPv6 support=0A in your operator, so
=0A     >   this service is not available for you= ".
=0A
    >
=0A
=     > Please *no*, for so many different reasons. --=0A = including "the average
=0A
   = ; > user doesn't care about IPv6, and may not even=0A be awa= re of what it is".
=0A
 
=0A
-&= gt; It can be a different text not necessarily mention=0A IPv6 = but just "your Internet connection is not able to=0A access thi= s content, please ask your ISP to upgrade it".=0A Anyway, it is= very contentious topic ... This probably will=0A get removed i= n a new version, or moved to an annex, etc.
=0A
 <= /div>=0A
    Ok, it could be, but remember it= is another proposal=0A like the other approaches and the idea = is to get these kind=0A of inputs.
=0A
 = ;  
=0A
    >
=0A =
    >
=0A
  &n= bsp; >
=0A
    > * Section 6:=0A
    >   Should we recommen= d having A records for=0A IPv6-only services in
=0A =
    >   Internet?  The A record m= ay point to a=0A "reserved" or "special" IPv4
=0A =
    >   address.  A web page IPv4-o= nly hosted by=0A IETF(?) showing "sorry this
=0A =
    >   web page/service is only availabl= e from IPv6=0A enabled operators"?.
=0A
&nbs= p;   >
=0A
    > Please= no. This assumes (?) hosts prefer IPv6,=0A but they don't need= to.
=0A
    > In which case they wou= ld get to such page and=0A have a not so great
=0A =
    > WTH(!?) moment.
=0A
&nbs= p;   >
=0A
    >
= =0A
    >
=0A
 &n= bsp;  > * Section 6:
=0A
    >= ;   NAT46/CLAT/DNS-proxy-EAM approach (Section=0A 4.2= ) seems the right
=0A
    > &nbs= p; solution for optimizing the access to=0A dual-stack services= , whether
=0A
    >   they = are located inside or outside the ISP.
=0A
  =   >
=0A
    > It would seem = to me that, actually, Approach #3,=0A when the ISP has no
= =0A
    > control on the CDN, or approach = #1 (when it=0A does), are the way to go.
=0A     > Approach #2 seems rather complex, with the=0A = consequent opportunities to
=0A
  &nb= sp; > screw up.
=0A
    Approach #1 i= s not easy to be implemented because=0A content providers doesn= 't want to be envolved on this=0A process despite agreeing it c= an be an improvement , so the=0A don't want to do any change in= configuration of their=0A devices / interfaces. It applies mor= e in case where CDN is=0A controlled by ISP (own CDN), but we w= ant to define a general=0A solution, we need to consider the no= rmal case of public /=0A external CDNs.
=0A
=     Approach #3, as you say, it is when ISP doesn't have=0A= control of the CDN. This is could not be a very scalable=0A = solution because it's not dynamic and any change needs to be=0A = propagated to all CPEs. On the other hand it's a very easy=0A = method to make a fast deploy where there are not often=0A = changes. I think this is a way where that allow to the=0A o= perator to deploy the solution quickly without depending on=0A = complex mechanisms and where content provider doesn't change=0A = DNS records, this is the case of Netflix CDN where A and=0A AA= AA records always have the same IPs associated for the=0A same = FQDN (for CDN).
=0A
    Approach #2, yes= , clearly it is more complex but it=0A will depends on how much= complexity we want to give to the=0A process and we need to de= fine very well which cases we want=0A to consider.
=0A =
   
=0A
    <= /div>=0A
    >
=0A
&nb= sp;   >
=0A
    > * Sec= tion 6:
=0A
    >   SIIT al= ready has a SHOULD for EAM support. =0A Should 464XLAT be = updated
=0A
    >   by this= document so the CLAT has a MUST for=0A EAM support?.
=0A =
    >
=0A
  =   > 464xlat employs existing technologies. So I'm=0A no= t sure you can do a MUST
=0A
    > in= 464xlat, when it relies on SIIT, and for SIIT=0A the requireme= nt is a
=0A
    > SHOULD.
=0A =
    Yes, what you say is valid, these are quest= ions to=0A see exactly what the community thinks.
=0A =
   
=0A
    &g= t;
=0A
    > Besides, the 464xlat sp= ec does not even employ=0A RFC2119 language.
=0A =
    >
=0A
    &g= t;
=0A
    >
=0A     > * Section 7:
=0A
  &= nbsp; >
=0A
    > Any solution wh= ere you spoof DNS records would=0A play bad with DNSsec.
= =0A
    > This should at least be discusse= d.
=0A
    >
=0A
=     >
=0A
    > Th= anks!
=0A
    >
=0A     > Cheers,
=0A
  &nbs= p; > Fernando
=0A
    >
=0A =
    >
=0A
  =   >
=0A
    >
=0A =
    > On 11/12/19 14:24, Ron Bonica wrote:=0A
    >> Folks,
=0A <= div>    >>
=0A
   = >> 
=0A
    >>
= =0A
    >> Each week between now and IE= TF 107, we will=0A review and discuss one draft
=0A =
    >> with an eye towards progressing it.=0A
    >>
=0A
&= nbsp;   >> 
=0A
   = ; >>
=0A
    >> This week, = please review and comment on
=0A
    >= ;> draft-palet-v6ops-464xlat-opt-cdn-caches.
=0A
&nb= sp;   >>
=0A
    >&g= t; 
=0A
    >>
=0A =
    >> When reviewing this draft, please i= ndicate=0A whether you think that V6OPS
=0A
=     >> should adopt it a s a work item.
=0A =
    >>
=0A
  =   >> 
=0A
    >> =
=0A
   =0A >> &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;   =0A Fred and Ron
=0A
&nbs= p;   >>
=0A
    >>= ; 
=0A
    >>
=0A =
    >>
=0A
  =   >> Juniper Business Use Only
=0A
 &nb= sp;  >>
=0A
    >> =0A
    >>=0A ___________= ____________________________________
=0A
  &n= bsp; >> v6ops mailing list
=0A
   = >> v6ops@ietf.org
=0A =0A =
    >>
=0A
 &nbs= p;  >
=0A
    >
=0A =
    > --
=0A
  =   > Fernando Gont
=0A
    > S= I6 Networks
=0A
    > e-mail: fgont= @si6networks.com
=0A
    > PGP Fi= ngerprint: 6666 31C6 D484 63B2 8FB1 E3C4=0A AE25 0D55 1D4E 7492=
=0A
    >
=0A
&n= bsp;   >
=0A
    > =0A
    >
=0A
 =    > _______________________________________________
=0A=
    > v6ops mailing list
=0A = =0A =0A
   
=0A
&= nbsp;   _______________________________________________
=0A=
    v6ops mailing list
=0A     v6ops@ietf.org
=0A =0A =
   
=0A
 
=0A =
 
=0A
 
=0A
*= *********************************************
=0A
IPv4 = is over
=0A
Are you ready for the new Internet ?
= =0A =0A The IPv6 Company
=0A
 
=0A
Thi= s electronic message contains information which may be=0A privi= leged or confidential. The information is intended to=0A be for= the exclusive use of the individual(s) named above=0A and furt= her non-explicilty authorized disclosure, copying,=0A distribut= ion or use of the contents of this information,=0A even if part= ially, including attached files, is strictly=0A prohibited and = will be considered a criminal offense. If you=0A are not the in= tended recipient be aware that any disclosure,=0A copying, dist= ribution or use of the contents of this=0A information, even if= partially, including attached files, is=0A strictly prohibited= , will be considered a criminal offense,=0A so you must reply t= o the original sender to inform about=0A this communication and= delete it.
=0A
 
=0A
 =0A
 
=0A
_______________________= ________________________
=0A
v6ops mailing list
= =0A =0A =0A
=0A =
=0A
=0A
=0A 
_____________=
__________________________________=0Av6ops mailing list=0Av6ops@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/v6ops=0A
=0A =
=0A
=0A =0A=0A ------=_001_NextPart441674543618_=------ From nobody Mon Jan 6 00:54:36 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE1C120073 for ; Mon, 6 Jan 2020 00:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 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, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tSe7bVgHbXSn for ; Mon, 6 Jan 2020 00:54:31 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD70120099 for ; Mon, 6 Jan 2020 00:54:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1578300866; x=1578905666; 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=1o2uW7500ymzPV6BP3M9tAIU4r2Xfah5SE Qe5izBd1w=; b=wl16PGdZkY9NOw01/m6jPXcSLUDN79weaY5BAGmlddMYVVtwwg +iTxKeNTLbt3vra4bv5aPP953TByf4qrYRENPVLJGTFLPVHUHpI/gG461HzrUBKB HKg4Qu/07PGN5usfWLO8bzZaH6j2Gb83lqva0tTj7cNT0zKEOoU8+NdTQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 06 Jan 2020 09:54:26 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 06 Jan 2020 09:54:23 +0100 Received: from [192.168.1.102] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000017575.msg for ; Mon, 06 Jan 2020 09:54:21 +0100 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [192.168.1.102] X-MDArrival-Date: Mon, 06 Jan 2020 09:54:21 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1274b5e573=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Mon, 06 Jan 2020 09:54:18 +0100 From: JORDI PALET MARTINEZ To: v6ops Message-ID: <1488150F-9DBD-4A10-80D8-24E4BB888BA2@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** References: <2020010616354842655859@chinatelecom.cn> In-Reply-To: <2020010616354842655859@chinatelecom.cn> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3661149260_1850782479" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jan 2020 08:54:35 -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_3661149260_1850782479 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Chongfeng, =20 Thanks for your inputs, comments below, in-line. =20 Regards, Jordi @jordipalet =20 =20 =20 El 6/1/20 9:36, "v6ops en nombre de xiechf@chinatelecom.cn" escribi=C3=B3: =20 =20 Hi=EF=BC=8CJordi, I have the following comments after reading the draft, 1\This draft is about IPv6-only for the acccess of IPv4-only client to dual= -stack CDN/Caches. From the perspective of operation, every possible approa= ch proposed should not pose additionl requirments for the network configura= tion.=20 =20 The document is looking for an optimization to 464XLAT in order to avoid do= uble translation when IPv4-only clients, access any IPv6 available content.= Precisely, our approach is trying to choose the option that avoids additio= nal network configuration. =20 2\ Based on my experience, I think the possibility of XLAT to be used in wi= reline network is very small, Is there any large-scale ISP who plan to use = XLAT for wireline broadband? Nearly every IPv6-capable CPE is dual stack, i= t is very difficult to convince the CPE industry to support XLAT in the for= seen future. Another factor that we should consider is that the IPTV servic= e of some ISPs is carried in a seperate layer-two channle, which does not m= ix with the default Internet access traffic. =20 =20 I don=E2=80=99t really agree on that. It makes a lot of sense, especially f= or operators that use 464XLAT in cellular, to have a single transition mech= anism if they also have broadband networks. This also simplify the use of = =E2=80=9Chybrid=E2=80=9D CPEs, where you have, for example, a GPON link, an= d a backup link via 3G/4G/5G. =20 My co-author is an example of that, but I=E2=80=99m also working with sever= al customers in other deployments. I=E2=80=99m not authorized to mention th= e specific ISP names right now, but I can tell you that *as I=E2=80=99m wri= ting these lines* I=E2=80=99m working in one customer which has 25 million = customers and the plan is to use 464XLAT in both the cellular and the broad= band networks. =20 3\I don't think the IP address 192.0.2.1 used in the example is suitable, f= or the IP address 192.0.0.0/16 has been defined used for special purpose, m= aybe the public IP address is better for the interface of CDN server. =20 I=E2=80=99ve used this prefix because it is reserved for documentation purp= oses (RFC5737), so it look to me the best choice. =20 4\In addition, the title of the draft "464XLAT Optimization" is too genera= l and ambiguous, I think a more specific one is better. =20 We can find a better title, this is not an issue. Any suggestions? =20 Best regards =20 Chongfeng=20 =20 From: JORDI PALET MARTINEZ Date: 2020-01-06 04:56 To: v6ops@ietf.org list Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Ad= option** Hi Fernando, =20 Adding some inputs, below, in-line (->). =20 =EF=BB=BFEl 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" e= scribi=C3=B3: =20 Hello Fernando, =20 First at all, thanks for your support to the work and the document and = for taking your time to read all the document. =20 I will try to answer your comments below. =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- > De: "Fernando Gont" > Para: "Ron Bonica" , "v6ops@i= etf.org list" > Enviados: Viernes, 3 de Enero 2020 20:40:11 > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call f= or Adoption** =20 > Folks, >=20 > I've read the document, and have the following comments: >=20 > It would seem to me is that this document has resulted from an > operators' concern that deployment of 464xlat might result in > unnecessary heavyweight use of the stateful PLAT, leading to scalabil= ity > problems or unnecessary money spendings. In that sense, I would like = the > issue to be documented (even if somehow we don't agree on a workaroun= d). Yes, from one point of view it is correct what you said and in addition= to that we have an unnecessary second translation (NAT64) when customer tr= affic was translated to IPv6 (NAT46) and the destination (content) is avail= able in IPv6 also, so we could avoid both a bottleneck and a performance im= pairment. That's why we consider this as an optimization. =20 -> I think the document is doing the work of documenting the problem statem= ent and providing possible solutions, which the idea of choosing one. We un= derstand that 464XLAT was not designed having this scenario in mind, but if= we can find a good solution, is worth to solve it. Furthermore, if the WG = agree that this is the way to go, we could update with this document 464XLA= T (which is an informational one) and make it to the standards track. As I'= ve already expressed several times, it is pity that being the transition me= chanism that is more used in the world (versus all the others, in terms of = number of devices), it is not a standard. =20 =20 >=20 > So I support the adoption of this document (or some version of it) -- > i.e., there's value in documenting the issue itself. >=20 > That said, I think that further work is required on the document. PLe= ase > find my review below: >=20 >=20 > **** Some meta comments **** >=20 > * Meta: I'd put more stress on why this "optimization" is important. = You > delve into many other (rather unnecessary) details, but don't elabora= te > much regarding why this "optimization" is important. =20 -> My reading is that the optimization and the need for it is well describe= d, but definitively will take a look into it and improve it if needed. =20 Yes, it is true, maybe the introduction could be simpler and more orien= ted to show the concrete problem and why we believe this is important. =20 I don't know if the info is wrong, maybe a specific initial summary tha= t indicates it is missing. We can consider it. =20 =20 >=20 > * Meta: It'd be important to note that, according to the Abstract of > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In tha= t > sense, the behavior you describe is kind of "expected", and what you > describe would seem to me more of a mechanism to *opt out of 464xlat* > than an optimization to 464XLAT itself. =20 -> Yes, I said that in my first comment. With this optimization, if we are = able to find consensus in a good solution, we improve something that was no= t initially expected to be done by 464XLAT. I don't see the "opt-out" point= that you mention. =20 Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also. Yes, this is the expected behavior of 464XLAT (and MAP-T also) but from= a practical and performance point of view, maybe, it is not the most optim= al path for the end-to-end traffic flow. As you said if we avoid the NAT64,= technically speaking, the traffic will not be going through a 464XLAT/MAP-= T scenario. We are not saying that 464XLAT is wrong at all, we are trying to expose= a real problem for IPv6 only network deployments and trying to present som= e approaches to solve it (or minimize it). =20 >=20 > * It would seem to me that the cases where this issue is more of a > concern is essentially smartboxes (smart TVs) consuming media from la= rge > CDNs. If so, this should be spelled out, since this essentially sets = the > context for what options/approaches can be considered acceptable. Ok, yes, we can put more effort to explain that. =20 >=20 >=20 >=20 > *** Some specific comments: **** >=20 > * Abstract: I'm curious if the term "NAT46" can be confusing, for > multiple reasons (for instance, it's not specified in RFC7915). Just = use > "SIIT", and the context (i.e., describe what's on each side of the SI= IT > device, and what's the intent). =20 -> Initially we were using the term CLAT, but then we realized that MAP-T h= as the same issue, and there it is not called CLAT, but NAT46. This is the = reason, quite simple, because the optimization will also work for MAP-T. =20 We can review it if it is confusing. The idea on this point was to talk about the NAT46 of CPE (CLAT). Yes, RFC7915 talks about SIIT independently if it is NAT46 or not. Regarding "(IP/ICMP Translation Algorithm) as described by [RFC7915]" i= t refers just to SIIT. As we know, CLAT is a combination of NAT46 + SIIT because it's an state= less translation from IPv4 to IPv6. =20 >=20 >=20 > * Introduction: > It seems to me the intro contains too many unnecessary details. e.g., > just talk about the CLAT as an abstract concept. Where/how > (specifically) it is implemented is mostly irrelevant in the context = of > this document. Yes, I don't know, it could be, as I put above maybe in the introductio= n we talk about many specific things and we could talk more about the probl= em itself. =20 >=20 >=20 > * Section 4: > Is the option where packets might get to the Cache with *private spac= e* > worth mentioning/describing/discussing? =20 -> When we talked with CDN/cache providers, they don't like to use non-GUA = (example the NAT64 WKP), so it is discussed as an option in approach 1. =20 I'm sorry I didn't understand it very well. What *private space* are you talking about? IPv4 or IPv6? If you are talking about IPv6, CDNs normally have IPv6 GUA. If you are talking about customers with private IPv4 reaching public IP= v4 destination CDNs, yes we could explain it because it is the main scenari= o we actually some content providers offers to ISPs to deliver content from= public IPv4 of CDN to customers with private IPv4 avoiding a CGN platform.= That was the first reason to create this document. =20 >=20 >=20 > * Section 4.3: > One more advantage of this solution is that the EAMT pairs doesn't > need to match the "real" IPv4/IPv6 addresses available in the A/AAA= A > records, as shown in the next example. >=20 > Please elaborate. =20 -> I think it is clear if you look at the example. =20 >=20 >=20 > * Section 5: > If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it ca= n > be complemented to resolve this issue, by means of making sure that > IPv6-only destinations have one A resource record (even an invalid > one), despite they aren't actually connected to IPv4. >=20 > Not sure what you mean. =20 -> I think it is clear if you read the paragraph before that one. Otherwise= we could expand the text to make it more obvious. =20 It's an idea, we offer different ideas (approaches) to try optimize the= traffic flow. Here, the idea is that if the destination is IPv6-only, when we have an= IPv4-only device, in a normal case you could never reach the destination b= ut if you have this optimization your Proxy DNS could detect that it doesn'= t have an A record but it has an AAAA record, so you could be connected to = the IPv6 destination. Without this, your IPv4-only device would not be able= to get the IPv6-only content. =20 >=20 >=20 > * Section 5: > In fact, it may become an incentive for the IPv6 deployment in > Internet services and provides the option to use an IPv4 address > (maybe anycast) for the "non-valid" A resource record, that points = to > a "universal" web page (maybe hosted by IETF?) that displays a > warning such as "Sorry, you don't IPv6 support in your operator, so > this service is not available for you". >=20 > Please *no*, for so many different reasons. -- including "the average > user doesn't care about IPv6, and may not even be aware of what it is= ". =20 -> It can be a different text not necessarily mention IPv6 but just "your I= nternet connection is not able to access this content, please ask your ISP = to upgrade it". Anyway, it is very contentious topic ... This probably will= get removed in a new version, or moved to an annex, etc. =20 Ok, it could be, but remember it is another proposal like the other app= roaches and the idea is to get these kind of inputs. =20 >=20 >=20 >=20 > * Section 6: > Should we recommend having A records for IPv6-only services in > Internet? The A record may point to a "reserved" or "special" IPv4 > address. A web page IPv4-only hosted by IETF(?) showing "sorry thi= s > web page/service is only available from IPv6 enabled operators"?. >=20 > Please no. This assumes (?) hosts prefer IPv6, but they don't need to= . > In which case they would get to such page and have a not so great > WTH(!?) moment. >=20 >=20 >=20 > * Section 6: > NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right > solution for optimizing the access to dual-stack services, whether > they are located inside or outside the ISP. >=20 > It would seem to me that, actually, Approach #3, when the ISP has no > control on the CDN, or approach #1 (when it does), are the way to go. > Approach #2 seems rather complex, with the consequent opportunities t= o > screw up. Approach #1 is not easy to be implemented because content providers doe= sn't want to be envolved on this process despite agreeing it can be an impr= ovement , so the don't want to do any change in configuration of their devi= ces / interfaces. It applies more in case where CDN is controlled by ISP (o= wn CDN), but we want to define a general solution, we need to consider the = normal case of public / external CDNs. Approach #3, as you say, it is when ISP doesn't have control of the CDN= . This is could not be a very scalable solution because it's not dynamic an= d any change needs to be propagated to all CPEs. On the other hand it's a v= ery easy method to make a fast deploy where there are not often changes. I = think this is a way where that allow to the operator to deploy the solution= quickly without depending on complex mechanisms and where content provider= doesn't change DNS records, this is the case of Netflix CDN where A and AA= AA records always have the same IPs associated for the same FQDN (for CDN). Approach #2, yes, clearly it is more complex but it will depends on how= much complexity we want to give to the process and we need to define very = well which cases we want to consider. =20 =20 >=20 >=20 > * Section 6: > SIIT already has a SHOULD for EAM support. Should 464XLAT be updat= ed > by this document so the CLAT has a MUST for EAM support?. >=20 > 464xlat employs existing technologies. So I'm not sure you can do a M= UST > in 464xlat, when it relies on SIIT, and for SIIT the requirement is a > SHOULD. Yes, what you say is valid, these are questions to see exactly what the= community thinks. =20 >=20 > Besides, the 464xlat spec does not even employ RFC2119 language. >=20 >=20 >=20 > * Section 7: >=20 > Any solution where you spoof DNS records would play bad with DNSsec. > This should at least be discussed. >=20 >=20 > Thanks! >=20 > Cheers, > Fernando >=20 >=20 >=20 >=20 > On 11/12/19 14:24, Ron Bonica wrote: >> Folks, >>=20 >> =20 >>=20 >> Each week between now and IETF 107, we will review and discuss one d= raft >> with an eye towards progressing it. >>=20 >> =20 >>=20 >> This week, please review and comment on >> draft-palet-v6ops-464xlat-opt-cdn-caches. >>=20 >> =20 >>=20 >> When reviewing this draft, please indicate whether you think that V6= OPS >> should adopt it a s a work item. >>=20 >> =20 >>=20 >> Fred and Ron >>=20 >> =20 >>=20 >>=20 >> Juniper Business Use Only >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3661149260_1850782479 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Chongfeng,

 

Thanks for your inputs, com= ments below, in-line.

 

Regards,

Jordi

@jordipalet

 

 

 

El 6/1/20 9:36, "v6ops en nombre de xiechf@chinatelecom.cn" <v6ops-bounces@ietf.org en nombre de xiechf@chinatelecom.cn> escrib= i=C3=B3:

 

 

Hi= =EF=BC=8CJordi,

I have the f= ollowing comments after reading the draft,

1\This draft is about IPv6-only = for the acccess of IPv4-only client to dual-stack CDN/Caches. From the pers= pective of operation, every possible approach proposed should not pose addi= tionl requirments for the network configuration. 

 

The doc= ument is looking for an optimization to 464XLAT in order to avoid double tr= anslation when IPv4-only clients, access any IPv6 available content. Precis= ely, our approach is trying to choose the option that avoids additional net= work configuration.

 

2\ Based on my experience, I= think the possibility of XLAT to be used in wireline network is very small= , Is there any large-scale ISP who plan to use XLAT for wireline broadband?= Nearly every IPv6-capable CPE is dual stack, it is very difficult to convi= nce the CPE industry to support XLAT in the forseen future. Another factor = that we should consider is that the IPTV service of some ISPs is carried in= a seperate layer-two channle, which does not mix with the default Internet= access traffic.  

 

I don=E2=80=99t really agree on that. = It makes a lot of sense, especially for operators that use 464XLAT in cellu= lar, to have a single transition mechanism if they also have broadband netw= orks. This also simplify the use of =E2=80=9Chybrid=E2=80=9D CPEs, where yo= u have, for example, a GPON link, and a backup link via 3G/4G/5G.

 

My co-author is an example of that, but= I=E2=80=99m also working with several customers in other deployments. I=E2= =80=99m not authorized to mention the specific ISP names right now, but I c= an tell you that *as I=E2=80=99m writing these lines* I=E2=80=99m wo= rking in one customer which has 25 million customers and the plan is to use= 464XLAT in both the cellular and the broadband networks.=

 

3\I don't think the IP address 192.0.2.1 used in the example is s= uitable, for the IP address 192.0.0.0/16 has been defined used for special = purpose, maybe the public IP address is better for the interface of CDN ser= ver.

 

I=E2=80=99ve used this prefix because it is reserved for = documentation purposes (RFC5737), so it look to me the best choice.

 

 4\In addition, the titl= e of the draft "464XLAT Optimization" is too general and ambiguou= s, I think a more specific one is better.

 

We can find a better= title, this is not an issue. Any suggestions?

<= div>

 

Best regards

 

Chongfeng 

<= blockquote style=3D'margin-left:6.0pt'>

 

Date:<= span style=3D'font-size:9.0pt;font-family:"Tahoma",sans-serif;color:black'>=  2020-01-06 04:56

Subject: Re: [v6ops] draft-palet-v6ops-46= 4xlat-opt-cdn-caches **Call for Adoption**

Hi Ferna= ndo,

 

Adding some inputs, below, in-line (->).

 

=EF=BB=BFEl 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" = <v6ops-bounces@ietf.org en nombre de adegidio=3D40telecentro.net.ar@dmar= c.ietf.org> escribi=C3=B3:

 

    Hello Fernando,

&nb= sp;  

    First at all, thanks for your support t= o the work and the document and for taking your time to read all the docume= nt.

   

    I will try to answer your commen= ts below.

   

   

=

    Regard= s,

    Alejandro

   

    ----= - Mensaje original -----

    > De: "Fernando Gont&qu= ot; <fgont@si6networks.com>

    > Para: "Ron B= onica" <rbonica=3D40juniper.net@dmarc.ietf.org>, "v6ops@iet= f.org list" <v6ops@ietf.org>

    > Enviados:= Viernes, 3 de Enero 2020 20:40:11

    > Asunto: Re: [v6o= ps] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

 &n= bsp; 

    > Folks,

    >

 &= nbsp;  > I've read the document, and have the following comments:

&= nbsp;   >

    > It would seem to me is that= this document has resulted from an

    > operators' conc= ern that deployment of 464xlat might result in

    > unne= cessary heavyweight use of the stateful PLAT, leading to scalability

 =    > problems or unnecessary money spendings. In that sense, I= would like the

    > issue to be documented (even if som= ehow we don't agree on a workaround).

    Yes, from one poin= t of view it is correct what you said and in addition to that we have an un= necessary second translation (NAT64) when customer traffic was translated t= o IPv6 (NAT46) and the destination (content) is available in IPv6 also, so = we could avoid both a bottleneck and a performance impairment. That's why w= e consider this as an optimization.

 

-> I think the document is doing the work of documen= ting the problem statement and providing possible solutions, which the idea= of choosing one. We understand that 464XLAT was not designed having this s= cenario in mind, but if we can find a good solution, is worth to solve it. = Furthermore, if the WG agree that this is the way to go, we could update wi= th this document 464XLAT (which is an informational one) and make it to the= standards track. As I've already expressed several times, it is pity that = being the transition mechanism that is more used in the world (versus all t= he others, in terms of number of devices), it is not a standard.=

 &nbs= p; 

   

    >

=

    &= gt; So I support the adoption of this document (or some version of it) --

&= nbsp;   > i.e., there's value in documenting the issue itself.=

    >

    > That said, I think that f= urther work is required on the document. PLease

    > fin= d my review below:

    >

    >

 =    > **** Some meta comments ****

    >

&nb= sp;   > * Meta: I'd put more stress on why this "optimiza= tion" is important. You

    > delve into many other = (rather unnecessary) details, but don't elaborate

=

    > m= uch regarding why this "optimization" is important.

 

-> = My reading is that the optimization and the need for it is well described, = but definitively will take a look into it and improve it if needed.

 <= o:p>

=     Yes, it is true, maybe the introduction could be simpler= and more oriented to show the concrete problem and why we believe this is = important.

   

    I don't know if the info = is wrong, maybe a specific initial summary that indicates it is missing. We= can consider it.

   

   

   = ; >

    > * Meta: It'd be important to note that, acc= ording to the Abstract of

    > RFC6877, 464XLAT assumes = IPv4 services over an IPv6-only node. In that

    > = sense, the behavior you describe is kind of "expected", and what = you

    > describe would seem to me more of a mechanism t= o *opt out of 464xlat*

    > than an optimization to 464= XLAT itself.

 

-> Yes, I said that in my first comment. With this o= ptimization, if we are able to find consensus in a good solution, we improv= e something that was not initially expected to be done by 464XLAT. I don't = see the "opt-out" point that you mention.

 

  &nbs= p; Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also.<= /o:p>

 = ;   Yes, this is the expected behavior of 464XLAT (and MAP-T also= ) but from a practical and performance point of view, maybe, it is not the = most optimal path for the end-to-end traffic flow. As you said if we avoid = the NAT64, technically speaking, the traffic will not be going through a 46= 4XLAT/MAP-T scenario.

    We are not saying that 464XLAT i= s wrong at all, we are trying to expose a real problem for IPv6 only networ= k deployments and trying to present some approaches to solve it (or minimiz= e it).

   

    >

    >= * It would seem to me that the cases where this issue is more of a

 &= nbsp;  > concern is essentially smartboxes (smart TVs) consuming me= dia from large

    > CDNs. If so, this should be spelled = out, since this essentially sets the

    > context for wh= at options/approaches can be considered acceptable.

    Ok, = yes, we can put more effort to explain that.

     =

&nbs= p;   >

    >

    > =

&nbs= p;   > *** Some specific comments: ****

    >= ;

    > * Abstract: I'm curious if the term "NAT46&= quot; can be confusing, for

    > multiple reasons (for i= nstance, it's not specified in RFC7915). Just use

=

    > &= quot;SIIT", and the context (i.e., describe what's on each side of the= SIIT

    > device, and what's the intent).

 

-> In= itially we were using the term CLAT, but then we realized that MAP-T has th= e same issue, and there it is not called CLAT, but NAT46. This is the reaso= n, quite simple, because the optimization will also work for MAP-T.

 <= o:p>

=     We can review it if it is confusing.

    = The idea on this point was to talk about the NAT46 of CPE (CLAT).

 &nb= sp;  Yes, RFC7915 talks about SIIT independently if it is NAT46 or not= .

    Regarding "(IP/ICMP Translation Algorithm) as des= cribed by [RFC7915]" it refers just to SIIT.

=

    As we = know, CLAT is a combination of NAT46 + SIIT because it's an stateless trans= lation from IPv4 to IPv6.

    

    >=

    >

    > * Introduction:

 &n= bsp;  > It seems to me the intro contains too many unnecessary deta= ils. e.g.,

    > just talk about the CLAT as an abstract = concept. Where/how

    > (specifically) it is implemented= is mostly irrelevant in the context of

    > this docu= ment.

    Yes, I don't know, it could be, as I put above may= be in the introduction we talk about many specific things and we could talk= more about the problem itself.

   

    >=

    >

    > * Section 4:<= /p>

  = ;  > Is the option where packets might get to the Cache with *priva= te space*

    > worth mentioning/describing/discussing?

&= nbsp;

-> When we talked with CDN/cache providers, they don't like to use= non-GUA (example the NAT64 WKP), so it is discussed as an option in approa= ch 1.

 

    I'm sorry I didn't understand it very well.=

    What *private space* are you talking about? IPv4 or IPv= 6?

    If you are talking about IPv6, CDNs normally have IPv= 6 GUA.

    If you are talking about customers with private I= Pv4 reaching public IPv4 destination CDNs, yes we could explain it because it is the= main scenario we actually some content providers offers to ISPs to deliver= content from public IPv4 of CDN to customers with private IPv4 avoiding a = CGN platform. That was the first reason to create this document.=

 &nbs= p; 

    >

    >

<= /div>

  &nb= sp; > * Section 4.3:

    >   One more advant= age of this solution is that the EAMT pairs doesn't

    >=    need to match the "real" IPv4/IPv6 addresses availab= le in the A/AAAA

    >   records, as shown in t= he next example.

    >

    > Please el= aborate.

 

-> I think it is clear if you look at the example.<= /o:p>

 = ;

    >

    >

    >= * Section 5:

    >   If NAT46/CLAT/DNS-proxy-E= AM approach (Section 4.2) is chosen, it can

    > &n= bsp; be complemented to resolve this issue, by means of making sure that

&n= bsp;   >   IPv6-only destinations have one A resourc= e record (even an invalid

    >   one), despite= they aren't actually connected to IPv4.

    >

 &n= bsp;  > Not sure what you mean.

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>-> I think it is clear = if you read the paragraph before that one. Otherwise we could expand the te= xt to make it more obvious.

 

    It's an idea, we offe= r different ideas (approaches) to try optimize the traffic flow.=

 &nbs= p;  Here, the idea is that if the destination is IPv6-only, when we ha= ve an IPv4-only device, in a normal case you could never reach the destinat= ion but if you have this optimization your Proxy DNS could detect that it d= oesn't have an A record but it has an AAAA record, so you could be connecte= d to the IPv6 destination. Without this, your IPv4-only device would not be= able to get the IPv6-only content.

   

    = >

=     >

    > * Section 5:

  &= nbsp; >   In fact, it may become an incentive for the IPv6 dep= loyment in

    >   Internet services and provid= es the option to use an IPv4 address

    >   (m= aybe anycast) for the "non-valid" A resource record, that points = to

    >   a "universal" web page (ma= ybe hosted by IETF?) that displays a

    >   wa= rning such as "Sorry, you don't IPv6 support in your operator, so=

&nbs= p;   >   this service is not available for you"= .

    >

    > Please *no*, for so many= different reasons. -- including "the average

    > = user doesn't care about IPv6, and may not even be aware of what it is"= .

 

-> It can be a different text not necessarily mention IPv6 but = just "your Internet connection is not able to access this content, ple= ase ask your ISP to upgrade it". Anyway, it is very contentious topic = ... This probably will get removed in a new version, or moved to an annex, = etc.

 

    Ok, it could be, but remember it is another = proposal like the other approaches and the idea is to get these kind of inp= uts.

   

    >

=

    > <= o:p>

=     >

    > * Section 6:

  &= nbsp; >   Should we recommend having A records for IPv6-only s= ervices in

    >   Internet?  The A record= may point to a "reserved" or "special" IPv4=

 &nbs= p;  >   address.  A web page IPv4-only hosted by IET= F(?) showing "sorry this

    >   web page/= service is only available from IPv6 enabled operators"?.

  &= nbsp; >

    > Please no. This assumes (?) hosts prefe= r IPv6, but they don't need to.

    > In which case they = would get to such page and have a not so great

    > WTH= (!?) moment.

    >

    >

  =   >

    > * Section 6:

=

    >&n= bsp;  NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right<= o:p>

=     >   solution for optimizing the access to d= ual-stack services, whether

    >   they are lo= cated inside or outside the ISP.

    >

   = ; > It would seem to me that, actually, Approach #3, when the ISP has no=

    > control on the CDN, or approach #1 (when it does),= are the way to go.

    > Approach #2 seems rather comple= x, with the consequent opportunities to

    > screw up.=

    Approach #1 is not easy to be implemented because conte= nt providers doesn't want to be envolved on this process despite agreeing i= t can be an improvement , so the don't want to do any change in configurati= on of their devices / interfaces. It applies more in case where CDN is cont= rolled by ISP (own CDN), but we want to define a general solution, we need = to consider the normal case of public / external CDNs.

=

    A= pproach #3, as you say, it is when ISP doesn't have control of the CDN. Thi= s is could not be a very scalable solution because it's not dynamic and any= change needs to be propagated to all CPEs. On the other hand it's a very e= asy method to make a fast deploy where there are not often changes. I think= this is a way where that allow to the operator to deploy the solution quic= kly without depending on complex mechanisms and where content provider does= n't change DNS records, this is the case of Netflix CDN where A and AAAA re= cords always have the same IPs associated for the same FQDN (for CDN).=

&nbs= p;   Approach #2, yes, clearly it is more complex but it will dep= ends on how much complexity we want to give to the process and we need to d= efine very well which cases we want to consider.

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

 =   

    >

    > <= /p>

  = ;  > * Section 6:

    >   SIIT already = has a SHOULD for EAM support.  Should 464XLAT be updated

  &= nbsp; >   by this document so the CLAT has a MUST for EAM supp= ort?.

    >

    > 464xlat e= mploys existing technologies. So I'm not sure you can do a MUST<= /p>

  = ;  > in 464xlat, when it relies on SIIT, and for SIIT the requireme= nt is a

    > SHOULD.

    Yes, what you = say is valid, these are questions to see exactly what the community thinks.=

   

    >

    > Besid= es, the 464xlat spec does not even employ RFC2119 language.

<= /div>

  &nb= sp; >

    >

    >

<= /div>

  &nb= sp; > * Section 7:

    >

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    > An= y solution where you spoof DNS records would play bad with DNSsec.

 &n= bsp;  > This should at least be discussed.

    > =

    >

    > Thanks!

   = ; >

    > Cheers,

    > Fernando<= o:p>

=     >

    >

=

    > <= o:p>

=     >

    > On 11/12/19 14:24, Ron Bon= ica wrote:

    >> Folks,

    >> <= o:p>

=     >> 

    >> <= /p>

  = ;  >> Each week between now and IETF 107, we will review and dis= cuss one draft

    >> with an eye towards progressing = it.

    >>

    >> 

 &= nbsp;  >>

    >> This week, please revie= w and comment on

    >> draft-palet-v6ops-464xlat-opt-cdn-caches.

    >>

&n= bsp;   >> 

    >>

  &= nbsp; >> When reviewing this draft, please indicate whether you think= that V6OPS

    >> should adopt it a s a work item.

&n= bsp;   >>

    >> 

  &= nbsp; >>

    >>     &n= bsp;            = ;            &n= bsp;            = ;            Fred an= d Ron

    >>

    >>  <= /o:p>

 = ;   >>

    >>

    >= ;> Juniper Business Use Only

    >>

=

  &n= bsp; >>

    >> ________________________________= _______________

    >> v6ops mailing list

  =   >> v6ops@ietf.org

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

    >>

   = >

    >

    > --

  &nbs= p; > Fernando Gont

    > SI6 Networks

=

  &n= bsp; > e-mail: fgont@si6networks.com

    > PGP Finge= rprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

   = ; >

    >

    >

   = ; >

    > ___________________________________________= ____

    >= ; v6ops mailing list

    > v6ops@ietf.org

<= /div>

  &nb= sp; > https://www.ietf.org/mailman/listinfo/v6ops

   

&n= bsp;   _______________________________________________=

 &nbs= p;  v6ops mailing list

    v6ops@ietf.org

  &= nbsp; https://www.ietf.org/mailman/listinfo/v6ops

=

    <= /o:p>

 = ;

 

 

**********************************************

IPv4 is over=

Are you ready for the new Internet ?

http://www.theipv6company.com

The IPv= 6 Company

 

This electronic message contains information which may be = privileged or confidential. The information is intended to be for the exclu= sive use of the individual(s) named above and further non-explicilty author= ized disclosure, copying, distribution or use of the contents of this infor= mation, even if partially, including attached files, is strictly prohibited= and will be considered a criminal offense. If you are not the intended rec= ipient be aware that any disclosure, copying, distribution or use of the co= ntents of this information, even if partially, including attached files, is= strictly prohibited, will be considered a criminal offense, so you must re= ply to the original sender to inform about this communication and delete it= .

 

 

 

_______________________________________________

v6o= ps mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops<= o:p>

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


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

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

--B_3661149260_1850782479-- From nobody Mon Jan 6 08:00:46 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE15F120845 for ; Mon, 6 Jan 2020 08:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTqv2vpcMSmN for ; Mon, 6 Jan 2020 08:00:39 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 3F9671202DD for ; Mon, 6 Jan 2020 08:00:39 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id n15so42830207qtp.5 for ; Mon, 06 Jan 2020 08:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=3cSXbsdRV1GMBtEmTa6mwbsH2fctHwW0wIRDusO+/4c=; b=IWtUjh3VWKqP2t2g2tOkvleICRxeCjGuhCuO1rARM8aBlNDH3088RDPA5kr1pNef6o 4T4sBMxa5k4l4hoRVSvlxYDYDkE9NcwwCAmofzHic68VGTyluAlwv3Hq0qeOvFQKe4FD p32Z0EyRnhkCRxomf/9fhwit8MX8gQiuXjQIEZCbSzy0LeV33btQF6Lhx+a/dJDiPnlM YZs3N+SaKkovXWldZAs6YFFmiGyl7V7IZ5PN/OKLOJPND5Msch8wTvz1BjJc0PFGBcGI ugRC2hkjlwWFKMNpBCy9wYwJMxeRvpLUyg0L1zcGt6YiWgKJrJSUUzWa19JdOMZZ1ZNd 7tJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=3cSXbsdRV1GMBtEmTa6mwbsH2fctHwW0wIRDusO+/4c=; b=XeRB13j+xAUvltlzCeJc/chqw0DWOE46JrXCi0L95rXgF1J+ktttT1md1W18UWDQrl IWqcsUJuRuPKhVlkWYlASnjjkKBLjb2D19GH2CS37noZ4G+FVjlYBEXjeoEs1LS7uTXD aM/dy2U0EMoT9Sw5tqtnmJGtNg05WAAs4oSUBWO3bGcPyqmT+UQ7BvzCS0o0RojPOHtx ZkUnNIHKbhcYmjZKQh1Mt0AGjhCwJvOFNwIWaMfLSO0zyVdsGqyuyX09TuZ7y2strfgI ikTJZZns+qI8HCc5MbgyFkIeJui/SfVaM2VSdyYQkXfSJDkegkwXheV/t8XApF7ZGjKV Q/1Q== X-Gm-Message-State: APjAAAU2UfKNIG+zgtKHCwfvrdKuvfRl+TPY2nP1JrSGJtjANWUjS4f3 rpZ53tTj4cO+Cx+R+XKD334TxuZ2 X-Google-Smtp-Source: APXvYqwgMtH1puTYTwnCffCMWry039zWPHt12IWfdELMsA5qf4qdNk1TVEVYDEsOCKxyQn3M6xDV5Q== X-Received: by 2002:ac8:410f:: with SMTP id q15mr75322783qtl.192.1578326437751; Mon, 06 Jan 2020 08:00:37 -0800 (PST) Received: from [192.168.1.18] ([177.52.245.133]) by smtp.gmail.com with ESMTPSA id k14sm20840030qki.66.2020.01.06.08.00.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2020 08:00:37 -0800 (PST) To: v6ops@ietf.org References: <2020010616354842655859@chinatelecom.cn> From: Fernando Frediani Message-ID: <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> Date: Mon, 6 Jan 2020 13:00:33 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <2020010616354842655859@chinatelecom.cn> Content-Type: multipart/alternative; boundary="------------0F30D992975CD06BD826AA04" Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jan 2020 16:00:44 -0000 This is a multi-part message in MIME format. --------------0F30D992975CD06BD826AA04 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 06/01/2020 05:35, xiechf@chinatelecom.cn wrote: > > 2\ Based on my experience, I think the possibility of XLAT to be used > in wireline network is very small, Is there any large-scale ISP who > plan to use XLAT for wireline broadband? Nearly every IPv6-capable CPE > is dual stack, it is very difficult to convince the CPE industry to > support XLAT in the forseen future. Another factor that we should > consider is that the IPTV service of some ISPs is carried in a > seperate layer-two channle, which does not mix with the default > Internet access traffic. Although the biggest challenge for 464XLAT adoption in fixed broadband ISPs is the lack of CLAT client on most CPEs I don't think that would be a major issue to convince CPE industry to have it because technically speaking is a minor component of the firmware and quiet easy to add de daemon. Sure it takes some time to happen, but it's not a major thing really. With this happening I bet in the future there is a potential of ISPs replacing CGNAT + IPv6 scenarios for 464XLAT for its advantages specially in being able to save more Public IPv4 addresses. With regards the IPTV service of some ISPs it occurs inside the ISP backbone and in most cases wouldn't require any kind of translation on the ISP side. Regards Fernando Frediani > > *From:* JORDI PALET MARTINEZ > > *Date:* 2020-01-06 04:56 > *To:* v6ops@ietf.org list > *Subject:* Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches > **Call for Adoption** > Hi Fernando, > Adding some inputs, below, in-line (->). > El 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" > adegidio=40telecentro.net.ar@dmarc.ietf.org> escribió: >     Hello Fernando, >     First at all, thanks for your support to the work and the > document and for taking your time to read all the document. >     I will try to answer your comments below. >     Regards, >     Alejandro >     ----- Mensaje original ----- >     > De: "Fernando Gont" >     > Para: "Ron Bonica" , > "v6ops@ietf.org list" >     > Enviados: Viernes, 3 de Enero 2020 20:40:11 >     > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches > **Call for Adoption** >     > Folks, >     > >     > I've read the document, and have the following comments: >     > >     > It would seem to me is that this document has resulted from an >     > operators' concern that deployment of 464xlat might result in >     > unnecessary heavyweight use of the stateful PLAT, leading to > scalability >     > problems or unnecessary money spendings. In that sense, I > would like the >     > issue to be documented (even if somehow we don't agree on a > workaround). >     Yes, from one point of view it is correct what you said and in > addition to that we have an unnecessary second translation (NAT64) > when customer traffic was translated to IPv6 (NAT46) and the > destination (content) is available in IPv6 also, so we could avoid > both a bottleneck and a performance impairment. That's why we > consider this as an optimization. > -> I think the document is doing the work of documenting the > problem statement and providing possible solutions, which the idea > of choosing one. We understand that 464XLAT was not designed > having this scenario in mind, but if we can find a good solution, > is worth to solve it. Furthermore, if the WG agree that this is > the way to go, we could update with this document 464XLAT (which > is an informational one) and make it to the standards track. As > I've already expressed several times, it is pity that being the > transition mechanism that is more used in the world (versus all > the others, in terms of number of devices), it is not a standard. >     > >     > So I support the adoption of this document (or some version > of it) -- >     > i.e., there's value in documenting the issue itself. >     > >     > That said, I think that further work is required on the > document. PLease >     > find my review below: >     > >     > >     > **** Some meta comments **** >     > >     > * Meta: I'd put more stress on why this "optimization" is > important. You >     > delve into many other (rather unnecessary) details, but > don't elaborate >     > much regarding why this "optimization" is important. > -> My reading is that the optimization and the need for it is well > described, but definitively will take a look into it and improve > it if needed. >     Yes, it is true, maybe the introduction could be simpler and > more oriented to show the concrete problem and why we believe this > is important. >     I don't know if the info is wrong, maybe a specific initial > summary that indicates it is missing. We can consider it. >     > >     > * Meta: It'd be important to note that, according to the > Abstract of >     > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only > node. In that >     > sense, the behavior you describe is kind of "expected", and > what you >     > describe would seem to me more of a mechanism to *opt out of > 464xlat* >     > than an optimization to 464XLAT itself. > -> Yes, I said that in my first comment. With this optimization, > if we are able to find consensus in a good solution, we improve > something that was not initially expected to be done by 464XLAT. I > don't see the "opt-out" point that you mention. >     Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also. >     Yes, this is the expected behavior of 464XLAT (and MAP-T also) > but from a practical and performance point of view, maybe, it is > not the most optimal path for the end-to-end traffic flow. As you > said if we avoid the NAT64, technically speaking, the traffic will > not be going through a 464XLAT/MAP-T scenario. >     We are not saying that 464XLAT is wrong at all, we are trying > to expose a real problem for IPv6 only network deployments and > trying to present some approaches to solve it (or minimize it). >     > >     > * It would seem to me that the cases where this issue is > more of a >     > concern is essentially smartboxes (smart TVs) consuming > media from large >     > CDNs. If so, this should be spelled out, since this > essentially sets the >     > context for what options/approaches can be considered > acceptable. >     Ok, yes, we can put more effort to explain that. >     > >     > >     > >     > *** Some specific comments: **** >     > >     > * Abstract: I'm curious if the term "NAT46" can be > confusing, for >     > multiple reasons (for instance, it's not specified in > RFC7915). Just use >     > "SIIT", and the context (i.e., describe what's on each side > of the SIIT >     > device, and what's the intent). > -> Initially we were using the term CLAT, but then we realized > that MAP-T has the same issue, and there it is not called CLAT, > but NAT46. This is the reason, quite simple, because the > optimization will also work for MAP-T. >     We can review it if it is confusing. >     The idea on this point was to talk about the NAT46 of CPE (CLAT). >     Yes, RFC7915 talks about SIIT independently if it is NAT46 or not. >     Regarding "(IP/ICMP Translation Algorithm) as described by > [RFC7915]" it refers just to SIIT. >     As we know, CLAT is a combination of NAT46 + SIIT because it's > an stateless translation from IPv4 to IPv6. >     > >     > >     > * Introduction: >     > It seems to me the intro contains too many unnecessary > details. e.g., >     > just talk about the CLAT as an abstract concept. Where/how >     > (specifically) it is implemented is mostly irrelevant in the > context of >     > this document. >     Yes, I don't know, it could be, as I put above maybe in the > introduction we talk about many specific things and we could talk > more about the problem itself. >     > >     > >     > * Section 4: >     > Is the option where packets might get to the Cache with > *private space* >     > worth mentioning/describing/discussing? > -> When we talked with CDN/cache providers, they don't like to use > non-GUA (example the NAT64 WKP), so it is discussed as an option > in approach 1. >     I'm sorry I didn't understand it very well. >     What *private space* are you talking about? IPv4 or IPv6? >     If you are talking about IPv6, CDNs normally have IPv6 GUA. >     If you are talking about customers with private IPv4 reaching > public IPv4 destination CDNs, yes we could explain it because it > is the main scenario we actually some content providers offers to > ISPs to deliver content from public IPv4 of CDN to customers with > private IPv4 avoiding a CGN platform. That was the first reason to > create this document. >     > >     > >     > * Section 4.3: >     >   One more advantage of this solution is that the EAMT pairs > doesn't >     >   need to match the "real" IPv4/IPv6 addresses available in > the A/AAAA >     >   records, as shown in the next example. >     > >     > Please elaborate. > -> I think it is clear if you look at the example. >     > >     > >     > * Section 5: >     >   If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is > chosen, it can >     >   be complemented to resolve this issue, by means of making > sure that >     >   IPv6-only destinations have one A resource record (even an > invalid >     >   one), despite they aren't actually connected to IPv4. >     > >     > Not sure what you mean. > -> I think it is clear if you read the paragraph before that one. > Otherwise we could expand the text to make it more obvious. >     It's an idea, we offer different ideas (approaches) to try > optimize the traffic flow. >     Here, the idea is that if the destination is IPv6-only, when > we have an IPv4-only device, in a normal case you could never > reach the destination but if you have this optimization your Proxy > DNS could detect that it doesn't have an A record but it has an > AAAA record, so you could be connected to the IPv6 destination. > Without this, your IPv4-only device would not be able to get the > IPv6-only content. >     > >     > >     > * Section 5: >     >   In fact, it may become an incentive for the IPv6 deployment in >     >   Internet services and provides the option to use an IPv4 > address >     >   (maybe anycast) for the "non-valid" A resource record, > that points to >     >   a "universal" web page (maybe hosted by IETF?) that displays a >     >   warning such as "Sorry, you don't IPv6 support in your > operator, so >     >   this service is not available for you". >     > >     > Please *no*, for so many different reasons. -- including > "the average >     > user doesn't care about IPv6, and may not even be aware of > what it is". > -> It can be a different text not necessarily mention IPv6 but > just "your Internet connection is not able to access this content, > please ask your ISP to upgrade it". Anyway, it is very contentious > topic ... This probably will get removed in a new version, or > moved to an annex, etc. >     Ok, it could be, but remember it is another proposal like the > other approaches and the idea is to get these kind of inputs. >     > >     > >     > >     > * Section 6: >     >   Should we recommend having A records for IPv6-only services in >     >   Internet?  The A record may point to a "reserved" or > "special" IPv4 >     >   address.  A web page IPv4-only hosted by IETF(?) showing > "sorry this >     >   web page/service is only available from IPv6 enabled > operators"?. >     > >     > Please no. This assumes (?) hosts prefer IPv6, but they > don't need to. >     > In which case they would get to such page and have a not so > great >     > WTH(!?) moment. >     > >     > >     > >     > * Section 6: >     >   NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the > right >     >   solution for optimizing the access to dual-stack services, > whether >     >   they are located inside or outside the ISP. >     > >     > It would seem to me that, actually, Approach #3, when the > ISP has no >     > control on the CDN, or approach #1 (when it does), are the > way to go. >     > Approach #2 seems rather complex, with the consequent > opportunities to >     > screw up. >     Approach #1 is not easy to be implemented because content > providers doesn't want to be envolved on this process despite > agreeing it can be an improvement , so the don't want to do any > change in configuration of their devices / interfaces. It applies > more in case where CDN is controlled by ISP (own CDN), but we want > to define a general solution, we need to consider the normal case > of public / external CDNs. >     Approach #3, as you say, it is when ISP doesn't have control > of the CDN. This is could not be a very scalable solution because > it's not dynamic and any change needs to be propagated to all > CPEs. On the other hand it's a very easy method to make a fast > deploy where there are not often changes. I think this is a way > where that allow to the operator to deploy the solution quickly > without depending on complex mechanisms and where content provider > doesn't change DNS records, this is the case of Netflix CDN where > A and AAAA records always have the same IPs associated for the > same FQDN (for CDN). >     Approach #2, yes, clearly it is more complex but it will > depends on how much complexity we want to give to the process and > we need to define very well which cases we want to consider. >     > >     > >     > * Section 6: >     >   SIIT already has a SHOULD for EAM support. Should 464XLAT > be updated >     >   by this document so the CLAT has a MUST for EAM support?. >     > >     > 464xlat employs existing technologies. So I'm not sure you > can do a MUST >     > in 464xlat, when it relies on SIIT, and for SIIT the > requirement is a >     > SHOULD. >     Yes, what you say is valid, these are questions to see exactly > what the community thinks. >     > >     > Besides, the 464xlat spec does not even employ RFC2119 language. >     > >     > >     > >     > * Section 7: >     > >     > Any solution where you spoof DNS records would play bad with > DNSsec. >     > This should at least be discussed. >     > >     > >     > Thanks! >     > >     > Cheers, >     > Fernando >     > >     > >     > >     > >     > On 11/12/19 14:24, Ron Bonica wrote: >     >> Folks, >     >> >     >> >     >> >     >> Each week between now and IETF 107, we will review and > discuss one draft >     >> with an eye towards progressing it. >     >> >     >> >     >> >     >> This week, please review and comment on >     >> draft-palet-v6ops-464xlat-opt-cdn-caches. >     >> >     >> >     >> >     >> When reviewing this draft, please indicate whether you > think that V6OPS >     >> should adopt it a s a work item. >     >> >     >> >     >> > >> Fred and Ron >     >> >     >> >     >> >     >> >     >> Juniper Business Use Only >     >> >     >> >     >> _______________________________________________ >     >> v6ops mailing list >     >> v6ops@ietf.org >     >> https://www.ietf.org/mailman/listinfo/v6ops >     >> >     > >     > >     > -- >     > Fernando Gont >     > SI6 Networks >     > e-mail: fgont@si6networks.com >     > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 > 1D4E 7492 >     > >     > >     > >     > >     > _______________________________________________ >     > 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 > ********************************************** > 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 --------------0F30D992975CD06BD826AA04 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 06/01/2020 05:35, xiechf@chinatelecom.cn wrote:

2\ Based on my experience, I think the possibility of XLAT to be used in wireline network is very small, Is there any large-scale ISP who plan to use XLAT for wireline broadband? Nearly every IPv6-capable CPE is dual stack, it is very difficult to convince the CPE industry to support XLAT in the forseen future. Another factor that we should consider is that the IPTV service of some ISPs is carried in a seperate layer-two channle, which does not mix with the default Internet access traffic. 

Although the biggest challenge for 464XLAT adoption in fixed broadband ISPs is the lack of CLAT client on most CPEs I don't think that would be a major issue to convince CPE industry to have it because technically speaking is a minor component of the firmware and quiet easy to add de daemon. Sure it takes some time to happen, but it's not a major thing really.
With this happening I bet in the future there is a potential of ISPs replacing CGNAT + IPv6 scenarios for 464XLAT for its advantages specially in being able to save more Public IPv4 addresses.

With regards the IPTV service of some ISPs it occurs inside the ISP backbone and in most cases wouldn't require any kind of translation on the ISP side.

Regards
Fernando Frediani



 
Date: 2020-01-06 04:56
Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
Hi Fernando,
 
Adding some inputs, below, in-line (->).
 
El 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" <v6ops-bounces@ietf.org en nombre de adegidio=40telecentro.net.ar@dmarc.ietf.org> escribió:
 
    Hello Fernando,
   
    First at all, thanks for your support to the work and the document and for taking your time to read all the document.
   
    I will try to answer your comments below.
   
   
    Regards,
    Alejandro
   
    ----- Mensaje original -----
    > De: "Fernando Gont" <fgont@si6networks.com>
    > Enviados: Viernes, 3 de Enero 2020 20:40:11
    > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
   
    > Folks,
    >
    > I've read the document, and have the following comments:
    >
    > It would seem to me is that this document has resulted from an
    > operators' concern that deployment of 464xlat might result in
    > unnecessary heavyweight use of the stateful PLAT, leading to scalability
    > problems or unnecessary money spendings. In that sense, I would like the
    > issue to be documented (even if somehow we don't agree on a workaround).
    Yes, from one point of view it is correct what you said and in addition to that we have an unnecessary second translation (NAT64) when customer traffic was translated to IPv6 (NAT46) and the destination (content) is available in IPv6 also, so we could avoid both a bottleneck and a performance impairment. That's why we consider this as an optimization.
 
-> I think the document is doing the work of documenting the problem statement and providing possible solutions, which the idea of choosing one. We understand that 464XLAT was not designed having this scenario in mind, but if we can find a good solution, is worth to solve it. Furthermore, if the WG agree that this is the way to go, we could update with this document 464XLAT (which is an informational one) and make it to the standards track. As I've already expressed several times, it is pity that being the transition mechanism that is more used in the world (versus all the others, in terms of number of devices), it is not a standard.
   
   
    >
    > So I support the adoption of this document (or some version of it) --
    > i.e., there's value in documenting the issue itself.
    >
    > That said, I think that further work is required on the document. PLease
    > find my review below:
    >
    >
    > **** Some meta comments ****
    >
    > * Meta: I'd put more stress on why this "optimization" is important. You
    > delve into many other (rather unnecessary) details, but don't elaborate
    > much regarding why this "optimization" is important.
 
-> My reading is that the optimization and the need for it is well described, but definitively will take a look into it and improve it if needed.
 
    Yes, it is true, maybe the introduction could be simpler and more oriented to show the concrete problem and why we believe this is important.
   
    I don't know if the info is wrong, maybe a specific initial summary that indicates it is missing. We can consider it.
   
   
    >
    > * Meta: It'd be important to note that, according to the Abstract of
    > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In that
    > sense, the behavior you describe is kind of "expected", and what you
    > describe would seem to me more of a mechanism to *opt out of 464xlat*
    > than an optimization to 464XLAT itself.
 
-> Yes, I said that in my first comment. With this optimization, if we are able to find consensus in a good solution, we improve something that was not initially expected to be done by 464XLAT. I don't see the "opt-out" point that you mention.
 
    Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also.
    Yes, this is the expected behavior of 464XLAT (and MAP-T also) but from a practical and performance point of view, maybe, it is not the most optimal path for the end-to-end traffic flow. As you said if we avoid the NAT64, technically speaking, the traffic will not be going through a 464XLAT/MAP-T scenario.
    We are not saying that 464XLAT is wrong at all, we are trying to expose a real problem for IPv6 only network deployments and trying to present some approaches to solve it (or minimize it).
   
    >
    > * It would seem to me that the cases where this issue is more of a
    > concern is essentially smartboxes (smart TVs) consuming media from large
    > CDNs. If so, this should be spelled out, since this essentially sets the
    > context for what options/approaches can be considered acceptable.
    Ok, yes, we can put more effort to explain that.
    
    >
    >
    >
    > *** Some specific comments: ****
    >
    > * Abstract: I'm curious if the term "NAT46" can be confusing, for
    > multiple reasons (for instance, it's not specified in RFC7915). Just use
    > "SIIT", and the context (i.e., describe what's on each side of the SIIT
    > device, and what's the intent).
 
-> Initially we were using the term CLAT, but then we realized that MAP-T has the same issue, and there it is not called CLAT, but NAT46. This is the reason, quite simple, because the optimization will also work for MAP-T.
 
    We can review it if it is confusing.
    The idea on this point was to talk about the NAT46 of CPE (CLAT).
    Yes, RFC7915 talks about SIIT independently if it is NAT46 or not.
    Regarding "(IP/ICMP Translation Algorithm) as described by [RFC7915]" it refers just to SIIT.
    As we know, CLAT is a combination of NAT46 + SIIT because it's an stateless translation from IPv4 to IPv6.
    
    >
    >
    > * Introduction:
    > It seems to me the intro contains too many unnecessary details. e.g.,
    > just talk about the CLAT as an abstract concept. Where/how
    > (specifically) it is implemented is mostly irrelevant in the context of
    > this document.
    Yes, I don't know, it could be, as I put above maybe in the introduction we talk about many specific things and we could talk more about the problem itself.
   
    >
    >
    > * Section 4:
    > Is the option where packets might get to the Cache with *private space*
    > worth mentioning/describing/discussing?
 
-> When we talked with CDN/cache providers, they don't like to use non-GUA (example the NAT64 WKP), so it is discussed as an option in approach 1.
 
    I'm sorry I didn't understand it very well.
    What *private space* are you talking about? IPv4 or IPv6?
    If you are talking about IPv6, CDNs normally have IPv6 GUA.
    If you are talking about customers with private IPv4 reaching public IPv4 destination CDNs, yes we could explain it because it is the main scenario we actually some content providers offers to ISPs to deliver content from public IPv4 of CDN to customers with private IPv4 avoiding a CGN platform. That was the first reason to create this document.
   
    >
    >
    > * Section 4.3:
    >   One more advantage of this solution is that the EAMT pairs doesn't
    >   need to match the "real" IPv4/IPv6 addresses available in the A/AAAA
    >   records, as shown in the next example.
    >
    > Please elaborate.
 
-> I think it is clear if you look at the example.
 
    >
    >
    > * Section 5:
    >   If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it can
    >   be complemented to resolve this issue, by means of making sure that
    >   IPv6-only destinations have one A resource record (even an invalid
    >   one), despite they aren't actually connected to IPv4.
    >
    > Not sure what you mean.
 
-> I think it is clear if you read the paragraph before that one. Otherwise we could expand the text to make it more obvious.
 
    It's an idea, we offer different ideas (approaches) to try optimize the traffic flow.
    Here, the idea is that if the destination is IPv6-only, when we have an IPv4-only device, in a normal case you could never reach the destination but if you have this optimization your Proxy DNS could detect that it doesn't have an A record but it has an AAAA record, so you could be connected to the IPv6 destination. Without this, your IPv4-only device would not be able to get the IPv6-only content.
   
    >
    >
    > * Section 5:
    >   In fact, it may become an incentive for the IPv6 deployment in
    >   Internet services and provides the option to use an IPv4 address
    >   (maybe anycast) for the "non-valid" A resource record, that points to
    >   a "universal" web page (maybe hosted by IETF?) that displays a
    >   warning such as "Sorry, you don't IPv6 support in your operator, so
    >   this service is not available for you".
    >
    > Please *no*, for so many different reasons. -- including "the average
    > user doesn't care about IPv6, and may not even be aware of what it is".
 
-> It can be a different text not necessarily mention IPv6 but just "your Internet connection is not able to access this content, please ask your ISP to upgrade it". Anyway, it is very contentious topic ... This probably will get removed in a new version, or moved to an annex, etc.
 
    Ok, it could be, but remember it is another proposal like the other approaches and the idea is to get these kind of inputs.
   
    >
    >
    >
    > * Section 6:
    >   Should we recommend having A records for IPv6-only services in
    >   Internet?  The A record may point to a "reserved" or "special" IPv4
    >   address.  A web page IPv4-only hosted by IETF(?) showing "sorry this
    >   web page/service is only available from IPv6 enabled operators"?.
    >
    > Please no. This assumes (?) hosts prefer IPv6, but they don't need to.
    > In which case they would get to such page and have a not so great
    > WTH(!?) moment.
    >
    >
    >
    > * Section 6:
    >   NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right
    >   solution for optimizing the access to dual-stack services, whether
    >   they are located inside or outside the ISP.
    >
    > It would seem to me that, actually, Approach #3, when the ISP has no
    > control on the CDN, or approach #1 (when it does), are the way to go.
    > Approach #2 seems rather complex, with the consequent opportunities to
    > screw up.
    Approach #1 is not easy to be implemented because content providers doesn't want to be envolved on this process despite agreeing it can be an improvement , so the don't want to do any change in configuration of their devices / interfaces. It applies more in case where CDN is controlled by ISP (own CDN), but we want to define a general solution, we need to consider the normal case of public / external CDNs.
    Approach #3, as you say, it is when ISP doesn't have control of the CDN. This is could not be a very scalable solution because it's not dynamic and any change needs to be propagated to all CPEs. On the other hand it's a very easy method to make a fast deploy where there are not often changes. I think this is a way where that allow to the operator to deploy the solution quickly without depending on complex mechanisms and where content provider doesn't change DNS records, this is the case of Netflix CDN where A and AAAA records always have the same IPs associated for the same FQDN (for CDN).
    Approach #2, yes, clearly it is more complex but it will depends on how much complexity we want to give to the process and we need to define very well which cases we want to consider.
   
   
    >
    >
    > * Section 6:
    >   SIIT already has a SHOULD for EAM support.  Should 464XLAT be updated
    >   by this document so the CLAT has a MUST for EAM support?.
    >
    > 464xlat employs existing technologies. So I'm not sure you can do a MUST
    > in 464xlat, when it relies on SIIT, and for SIIT the requirement is a
    > SHOULD.
    Yes, what you say is valid, these are questions to see exactly what the community thinks.
   
    >
    > Besides, the 464xlat spec does not even employ RFC2119 language.
    >
    >
    >
    > * Section 7:
    >
    > Any solution where you spoof DNS records would play bad with DNSsec.
    > This should at least be discussed.
    >
    >
    > Thanks!
    >
    > Cheers,
    > Fernando
    >
    >
    >
    >
    > On 11/12/19 14:24, Ron Bonica wrote:
    >> Folks,
    >>
    >> 
    >>
    >> Each week between now and IETF 107, we will review and discuss one draft
    >> with an eye towards progressing it.
    >>
    >> 
    >>
    >> This week, please review and comment on
    >> draft-palet-v6ops-464xlat-opt-cdn-caches.
    >>
    >> 
    >>
    >> When reviewing this draft, please indicate whether you think that V6OPS
    >> should adopt it a s a work item.
    >>
    >> 
    >>
    >>                                                       Fred and Ron
    >>
    >> 
    >>
    >>
    >> Juniper Business Use Only
    >>
    >>
    >> _______________________________________________
    >> v6ops mailing list
    >> v6ops@ietf.org
    >>
    >
    >
    > --
    > Fernando Gont
    > SI6 Networks
    > e-mail: fgont@si6networks.com
    > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
    >
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
   
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
   
 
 
 
**********************************************
IPv4 is over
Are you ready for the new Internet ?
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 mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------0F30D992975CD06BD826AA04-- From nobody Mon Jan 6 08:10:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1B812088A for ; Mon, 6 Jan 2020 08:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldx2C8Q8jX7u for ; Mon, 6 Jan 2020 08:10:35 -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 1F7BD120871 for ; Mon, 6 Jan 2020 08:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1578327030; x=1578931830; 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=aBkgG/40EBeQIulPL/ees8PdrmBH8F/C05 aQyVc6ksE=; b=dCfcbjsVCTp0VTc+0kdA1LAb54ovjdR06lEAeWkWltHhoAUmA2 mR9YEfYY9bUPAmiz0t3sto/hvRq9UI2HFy2Mue3/Vlsh6QMFS1Gcs1fA206wP3+v MfC4EmSSAkcMb6xAFhoGpmLSNKH2U4y9JQ7/5z753NM47FLeLLMiRL+Vw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 06 Jan 2020 17:10:30 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 06 Jan 2020 17:10:27 +0100 Received: from [10.192.0.137] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000017896.msg for ; Mon, 06 Jan 2020 17:10:26 +0100 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.192.0.137] X-MDArrival-Date: Mon, 06 Jan 2020 17:10:26 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1274b5e573=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Mon, 06 Jan 2020 17:10:18 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <0287E75D-7643-4E32-B118-A172FADFB84F@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> In-Reply-To: <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3661175421_1151710743" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jan 2020 16:10:39 -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_3661175421_1151710743 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable In fact, we are working with several candidate vendors for several projects= . =20 In the RFC8585 you can see at least two vendors, and Alejandro and myself a= re working with a few others as well. =20 Regards, Jordi @jordipalet =20 =20 =20 El 6/1/20 17:01, "v6ops en nombre de Fernando Frediani" escribi=C3=B3: =20 On 06/01/2020 05:35, xiechf@chinatelecom.cn wrote: =20 2\ Based on my experience, I think the possibility of XLAT to be used in wi= reline network is very small, Is there any large-scale ISP who plan to use = XLAT for wireline broadband? Nearly every IPv6-capable CPE is dual stack, i= t is very difficult to convince the CPE industry to support XLAT in the for= seen future. Another factor that we should consider is that the IPTV servic= e of some ISPs is carried in a seperate layer-two channle, which does not m= ix with the default Internet access traffic. =20 Although the biggest challenge for 464XLAT adoption in fixed broadband ISPs= is the lack of CLAT client on most CPEs I don't think that would be a majo= r issue to convince CPE industry to have it because technically speaking is= a minor component of the firmware and quiet easy to add de daemon. Sure it= takes some time to happen, but it's not a major thing really. With this happening I bet in the future there is a potential of ISPs replac= ing CGNAT + IPv6 scenarios for 464XLAT for its advantages specially in bein= g able to save more Public IPv4 addresses. With regards the IPTV service of some ISPs it occurs inside the ISP backbon= e and in most cases wouldn't require any kind of translation on the ISP sid= e. Regards Fernando Frediani =20 =20 =20 From: JORDI PALET MARTINEZ Date: 2020-01-06 04:56 To: v6ops@ietf.org list Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Ad= option** Hi Fernando, =20 Adding some inputs, below, in-line (->). =20 =EF=BB=BFEl 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" e= scribi=C3=B3: =20 Hello Fernando, =20 First at all, thanks for your support to the work and the document and = for taking your time to read all the document. =20 I will try to answer your comments below. =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- > De: "Fernando Gont" > Para: "Ron Bonica" , "v6ops@i= etf.org list" > Enviados: Viernes, 3 de Enero 2020 20:40:11 > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call f= or Adoption** =20 > Folks, >=20 > I've read the document, and have the following comments: >=20 > It would seem to me is that this document has resulted from an > operators' concern that deployment of 464xlat might result in > unnecessary heavyweight use of the stateful PLAT, leading to scalabil= ity > problems or unnecessary money spendings. In that sense, I would like = the > issue to be documented (even if somehow we don't agree on a workaroun= d). Yes, from one point of view it is correct what you said and in addition= to that we have an unnecessary second translation (NAT64) when customer tr= affic was translated to IPv6 (NAT46) and the destination (content) is avail= able in IPv6 also, so we could avoid both a bottleneck and a performance im= pairment. That's why we consider this as an optimization. =20 -> I think the document is doing the work of documenting the problem statem= ent and providing possible solutions, which the idea of choosing one. We un= derstand that 464XLAT was not designed having this scenario in mind, but if= we can find a good solution, is worth to solve it. Furthermore, if the WG = agree that this is the way to go, we could update with this document 464XLA= T (which is an informational one) and make it to the standards track. As I'= ve already expressed several times, it is pity that being the transition me= chanism that is more used in the world (versus all the others, in terms of = number of devices), it is not a standard. =20 =20 >=20 > So I support the adoption of this document (or some version of it) -- > i.e., there's value in documenting the issue itself. >=20 > That said, I think that further work is required on the document. PLe= ase > find my review below: >=20 >=20 > **** Some meta comments **** >=20 > * Meta: I'd put more stress on why this "optimization" is important. = You > delve into many other (rather unnecessary) details, but don't elabora= te > much regarding why this "optimization" is important. =20 -> My reading is that the optimization and the need for it is well describe= d, but definitively will take a look into it and improve it if needed. =20 Yes, it is true, maybe the introduction could be simpler and more orien= ted to show the concrete problem and why we believe this is important. =20 I don't know if the info is wrong, maybe a specific initial summary tha= t indicates it is missing. We can consider it. =20 =20 >=20 > * Meta: It'd be important to note that, according to the Abstract of > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In tha= t > sense, the behavior you describe is kind of "expected", and what you > describe would seem to me more of a mechanism to *opt out of 464xlat* > than an optimization to 464XLAT itself. =20 -> Yes, I said that in my first comment. With this optimization, if we are = able to find consensus in a good solution, we improve something that was no= t initially expected to be done by 464XLAT. I don't see the "opt-out" point= that you mention. =20 Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also. Yes, this is the expected behavior of 464XLAT (and MAP-T also) but from= a practical and performance point of view, maybe, it is not the most optim= al path for the end-to-end traffic flow. As you said if we avoid the NAT64,= technically speaking, the traffic will not be going through a 464XLAT/MAP-= T scenario. We are not saying that 464XLAT is wrong at all, we are trying to expose= a real problem for IPv6 only network deployments and trying to present som= e approaches to solve it (or minimize it). =20 >=20 > * It would seem to me that the cases where this issue is more of a > concern is essentially smartboxes (smart TVs) consuming media from la= rge > CDNs. If so, this should be spelled out, since this essentially sets = the > context for what options/approaches can be considered acceptable. Ok, yes, we can put more effort to explain that. =20 >=20 >=20 >=20 > *** Some specific comments: **** >=20 > * Abstract: I'm curious if the term "NAT46" can be confusing, for > multiple reasons (for instance, it's not specified in RFC7915). Just = use > "SIIT", and the context (i.e., describe what's on each side of the SI= IT > device, and what's the intent). =20 -> Initially we were using the term CLAT, but then we realized that MAP-T h= as the same issue, and there it is not called CLAT, but NAT46. This is the = reason, quite simple, because the optimization will also work for MAP-T. =20 We can review it if it is confusing. The idea on this point was to talk about the NAT46 of CPE (CLAT). Yes, RFC7915 talks about SIIT independently if it is NAT46 or not. Regarding "(IP/ICMP Translation Algorithm) as described by [RFC7915]" i= t refers just to SIIT. As we know, CLAT is a combination of NAT46 + SIIT because it's an state= less translation from IPv4 to IPv6. =20 >=20 >=20 > * Introduction: > It seems to me the intro contains too many unnecessary details. e.g., > just talk about the CLAT as an abstract concept. Where/how > (specifically) it is implemented is mostly irrelevant in the context = of > this document. Yes, I don't know, it could be, as I put above maybe in the introductio= n we talk about many specific things and we could talk more about the probl= em itself. =20 >=20 >=20 > * Section 4: > Is the option where packets might get to the Cache with *private spac= e* > worth mentioning/describing/discussing? =20 -> When we talked with CDN/cache providers, they don't like to use non-GUA = (example the NAT64 WKP), so it is discussed as an option in approach 1. =20 I'm sorry I didn't understand it very well. What *private space* are you talking about? IPv4 or IPv6? If you are talking about IPv6, CDNs normally have IPv6 GUA. If you are talking about customers with private IPv4 reaching public IP= v4 destination CDNs, yes we could explain it because it is the main scenari= o we actually some content providers offers to ISPs to deliver content from= public IPv4 of CDN to customers with private IPv4 avoiding a CGN platform.= That was the first reason to create this document. =20 >=20 >=20 > * Section 4.3: > One more advantage of this solution is that the EAMT pairs doesn't > need to match the "real" IPv4/IPv6 addresses available in the A/AAA= A > records, as shown in the next example. >=20 > Please elaborate. =20 -> I think it is clear if you look at the example. =20 >=20 >=20 > * Section 5: > If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it ca= n > be complemented to resolve this issue, by means of making sure that > IPv6-only destinations have one A resource record (even an invalid > one), despite they aren't actually connected to IPv4. >=20 > Not sure what you mean. =20 -> I think it is clear if you read the paragraph before that one. Otherwise= we could expand the text to make it more obvious. =20 It's an idea, we offer different ideas (approaches) to try optimize the= traffic flow. Here, the idea is that if the destination is IPv6-only, when we have an= IPv4-only device, in a normal case you could never reach the destination b= ut if you have this optimization your Proxy DNS could detect that it doesn'= t have an A record but it has an AAAA record, so you could be connected to = the IPv6 destination. Without this, your IPv4-only device would not be able= to get the IPv6-only content. =20 >=20 >=20 > * Section 5: > In fact, it may become an incentive for the IPv6 deployment in > Internet services and provides the option to use an IPv4 address > (maybe anycast) for the "non-valid" A resource record, that points = to > a "universal" web page (maybe hosted by IETF?) that displays a > warning such as "Sorry, you don't IPv6 support in your operator, so > this service is not available for you". >=20 > Please *no*, for so many different reasons. -- including "the average > user doesn't care about IPv6, and may not even be aware of what it is= ". =20 -> It can be a different text not necessarily mention IPv6 but just "your I= nternet connection is not able to access this content, please ask your ISP = to upgrade it". Anyway, it is very contentious topic ... This probably will= get removed in a new version, or moved to an annex, etc. =20 Ok, it could be, but remember it is another proposal like the other app= roaches and the idea is to get these kind of inputs. =20 >=20 >=20 >=20 > * Section 6: > Should we recommend having A records for IPv6-only services in > Internet? The A record may point to a "reserved" or "special" IPv4 > address. A web page IPv4-only hosted by IETF(?) showing "sorry thi= s > web page/service is only available from IPv6 enabled operators"?. >=20 > Please no. This assumes (?) hosts prefer IPv6, but they don't need to= . > In which case they would get to such page and have a not so great > WTH(!?) moment. >=20 >=20 >=20 > * Section 6: > NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right > solution for optimizing the access to dual-stack services, whether > they are located inside or outside the ISP. >=20 > It would seem to me that, actually, Approach #3, when the ISP has no > control on the CDN, or approach #1 (when it does), are the way to go. > Approach #2 seems rather complex, with the consequent opportunities t= o > screw up. Approach #1 is not easy to be implemented because content providers doe= sn't want to be envolved on this process despite agreeing it can be an impr= ovement , so the don't want to do any change in configuration of their devi= ces / interfaces. It applies more in case where CDN is controlled by ISP (o= wn CDN), but we want to define a general solution, we need to consider the = normal case of public / external CDNs. Approach #3, as you say, it is when ISP doesn't have control of the CDN= . This is could not be a very scalable solution because it's not dynamic an= d any change needs to be propagated to all CPEs. On the other hand it's a v= ery easy method to make a fast deploy where there are not often changes. I = think this is a way where that allow to the operator to deploy the solution= quickly without depending on complex mechanisms and where content provider= doesn't change DNS records, this is the case of Netflix CDN where A and AA= AA records always have the same IPs associated for the same FQDN (for CDN). Approach #2, yes, clearly it is more complex but it will depends on how= much complexity we want to give to the process and we need to define very = well which cases we want to consider. =20 =20 >=20 >=20 > * Section 6: > SIIT already has a SHOULD for EAM support. Should 464XLAT be updat= ed > by this document so the CLAT has a MUST for EAM support?. >=20 > 464xlat employs existing technologies. So I'm not sure you can do a M= UST > in 464xlat, when it relies on SIIT, and for SIIT the requirement is a > SHOULD. Yes, what you say is valid, these are questions to see exactly what the= community thinks. =20 >=20 > Besides, the 464xlat spec does not even employ RFC2119 language. >=20 >=20 >=20 > * Section 7: >=20 > Any solution where you spoof DNS records would play bad with DNSsec. > This should at least be discussed. >=20 >=20 > Thanks! >=20 > Cheers, > Fernando >=20 >=20 >=20 >=20 > On 11/12/19 14:24, Ron Bonica wrote: >> Folks, >>=20 >> =20 >>=20 >> Each week between now and IETF 107, we will review and discuss one d= raft >> with an eye towards progressing it. >>=20 >> =20 >>=20 >> This week, please review and comment on >> draft-palet-v6ops-464xlat-opt-cdn-caches. >>=20 >> =20 >>=20 >> When reviewing this draft, please indicate whether you think that V6= OPS >> should adopt it a s a work item. >>=20 >> =20 >>=20 >> Fred and Ron >>=20 >> =20 >>=20 >>=20 >> Juniper Business Use Only >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3661175421_1151710743 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

In fact, we are working with several candida= te vendors for several projects.

=  

In the RFC8585 you can see at = least two vendors, and Alejandro and myself are working with a few others a= s well.

 

Rega= rds,

Jordi

@jordipalet

 

=

 

<= span lang=3DEN-US style=3D'font-size:12.0pt;mso-fareast-language:EN-US'> 

El 6/1/20 17:01, "v6ops en nombre de Fernando Frediani"= <v6ops-bounces@ietf.org e= n nombre de fhfrediani@gmail.com> escribi=C3=B3:

On 06/01/2020 05:35, xiechf@chinatelecom.cn wrote:

 

2\ Based on my experience, I thi= nk the possibility of XLAT to be used in wireline network is very small, Is= there any large-scale ISP who plan to use XLAT for wireline broadband? Nea= rly every IPv6-capable CPE is dual stack, it is very difficult to convince = the CPE industry to support XLAT in the forseen future. Another factor that= we should consider is that the IPTV service of some ISPs is carried in a s= eperate layer-two channle, which does not mix with the default Internet acc= ess traffic. 

Although the biggest challenge for 464XLAT adoption in fixe= d broadband ISPs is the lack of CLAT client on most CPEs I don't think that= would be a major issue to convince CPE industry to have it because technic= ally speaking is a minor component of the firmware and quiet easy to add de= daemon. Sure it takes some time to happen, but it's not a major thing real= ly.
With this happening I bet in the future there is a potential of ISPs= replacing CGNAT + IPv6 scenarios for 464XLAT for its advantages specially = in being able to save more Public IPv4 addresses.

With regards the IPTV service of some ISPs it occurs i= nside the ISP backbone and in most cases wouldn't require any kind of trans= lation on the ISP side.

Regar= ds
Fernando Frediani

=  

 

 

From: JORDI PALET MARTINEZ<= /span>

Date: 2020-01-06 04:56<= /span>

Subject:&n= bsp;Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoptio= n**

Hi Fernando,

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>Adding some inputs, below,= in-line (->).

 

=EF=BB=BFEl 4/1/20 4:34, "v6ops en nombre de = Alejandro D'Egidio" <v6ops-bounces@ietf.org e= n nombre de adegidio=3D40telecentro.net.ar@dmarc.ietf.org> escribi= =C3=B3:

 

    Hello Fernando,

=

    <= /o:p>

 = ;   First at all, thanks for your support to the work and the doc= ument and for taking your time to read all the document.

   =

    I will try to answer your comments below.

  =  

   

    Regards,

    = Alejandro

   

    ----- Mensaje original ---= --

    > De: "Fernando Gont" <fgont@si6networks.com>

=

    &= gt; Enviados: Viernes, 3 de Enero 2020 20:40:11

    > Asu= nto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

   

  &= nbsp; > Folks,

    >

    > I've rea= d the document, and have the following comments:

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

&= nbsp;   > It would seem to me is that this document has result= ed from an

    > operators' concern that deployment of 46= 4xlat might result in

    > unnecessary heavyweight use= of the stateful PLAT, leading to scalability

    > probl= ems or unnecessary money spendings. In that sense, I would like the

 &= nbsp;  > issue to be documented (even if somehow we don't agree on = a workaround).

    Yes, from one point of view it is correct= what you said and in addition to that we have an unnecessary second transl= ation (NAT64) when customer traffic was translated to IPv6 (NAT46) and the = destination (content) is available in IPv6 also, so we could avoid both a b= ottleneck and a performance impairment. That's why we consider this as an o= ptimization.

 

-> I think the document is doing the work of documen= ting the problem statement and providing possible solutions, which the idea= of choosing one. We understand that 464XLAT was not designed having this s= cenario in mind, but if we can find a good solution, is worth to solve it. = Furthermore, if the WG agree that this is the way to go, we could update wi= th this document 464XLAT (which is an informational one) and make it to the= standards track. As I've already expressed several times, it is pity that = being the transition mechanism that is more used in the world (versus all t= he others, in terms of number of devices), it is not a standard.=

 &nbs= p; 

   

    >

=

    &= gt; So I support the adoption of this document (or some version of it) --

&= nbsp;   > i.e., there's value in documenting the issue itself.=

    >

    > That said, I think that f= urther work is required on the document. PLease

    > fin= d my review below:

    >

    >

 =    > **** Some meta comments ****

    >

    > * Meta: I'd put more stress on why this "optimiz= ation" is important. You

    > delve into many other= (rather unnecessary) details, but don't elaborate

    > = much regarding why this "optimization" is important.

 <= /o:p>

->= My reading is that the optimization and the need for it is well described,= but definitively will take a look into it and improve it if needed.

 =

    Yes, it is true, maybe the introduction could be simple= r and more oriented to show the concrete problem and why we believe this is= important.

   

    I don't know if the info= is wrong, maybe a specific initial summary that indicates it is missing. W= e can consider it.

   

   

  &nbs= p; >

    > * Meta: It'd be important to note that, ac= cording to the Abstract of

    > RFC6877, 464XLAT assumes= IPv4 services over an IPv6-only node. In that

    > sens= e, the behavior you describe is kind of "expected", and what you<= o:p>

=     > describe would seem to me more of a mechanism to *o= pt out of 464xlat*

    > than an optimization to 464XLAT = itself.

 

-> Yes, I said that in my first comment. With this optimi= zation, if we are able to find consensus in a good solution, we improve som= ething that was not initially expected to be done by 464XLAT. I don't see t= he "opt-out" point that you mention.

 

<= div>

    Ye= s, 464XLAT asumes both IPv4 services and IPv4-only devices also.=

 &nbs= p;  Yes, this is the expected behavior of 464XLAT (and MAP-T also) but= from a practical and performance point of view, maybe, it is not the most = optimal path for the end-to-end traffic flow. As you said if we avoid the N= AT64, technically speaking, the traffic will not be going through a 464XLAT= /MAP-T scenario.

    We are not saying that 464XLAT is wrong= at all, we are trying to expose a real problem for IPv6 only network deplo= yments and trying to present some approaches to solve it (or minimize it).<= o:p>

=    

    >

    > * It w= ould seem to me that the cases where this issue is more of a

 = ;   > concern is essentially smartboxes (smart TVs) consuming = media from large

    > CDNs. If so, this should be spelle= d out, since this essentially sets the

    > context for = what options/approaches can be considered acceptable.

<= div>

    Ok= , yes, we can put more effort to explain that.

    

&n= bsp;   >

    >

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

&= nbsp;   > *** Some specific comments: ****

    = >

    > * Abstract: I'm curious if the term "NAT= 46" can be confusing, for

    > multiple reasons (fo= r instance, it's not specified in RFC7915). Just use

    >= ; "SIIT", and the context (i.e., describe what's on each side of = the SIIT

    > device, and what's the intent).=

 

-&g= t; Initially we were using the term CLAT, but then we realized that MAP-T h= as the same issue, and there it is not called CLAT, but NAT46. This is the = reason, quite simple, because the optimization will also work for MAP-T.

&n= bsp;

    We can review it if it is confusing.

=

  &n= bsp; The idea on this point was to talk about the NAT46 of CPE (CLAT).=

&nbs= p;   Yes, RFC7915 talks about SIIT independently if it is NAT46 o= r not.

    Regarding "(IP/ICMP Translation Algorithm) a= s described by [RFC7915]" it refers just to SIIT.

=

    A= s we know, CLAT is a combination of NAT46 + SIIT because it's an stateless = translation from IPv4 to IPv6.

    

   = >

    >

    > * Introduction:

&nb= sp;   > It seems to me the intro contains too many unnecessary= details. e.g.,

    > just talk about the CLAT as an abst= ract concept. Where/how

    > (specifically) it is implem= ented is mostly irrelevant in the context of

    > this document.

&= nbsp;   Yes, I don't know, it could be, as I put above maybe in t= he introduction we talk about many specific things and we could talk more a= bout the problem itself.

   

    > <= /o:p>

 = ;   >

    > * Section 4:

   = > Is the option where packets might get to the Cache with *private spac= e*

    > worth mentioning/describing/discussing?

 

-= > When we talked with CDN/cache providers, they don't like to use non-GU= A (example the NAT64 WKP), so it is discussed as an option in approach 1.

&= nbsp;

    I'm sorry I didn't understand it very well.

 =    What *private space* are you talking about? IPv4 or IPv6?=

&nbs= p;   If you are talking about IPv6, CDNs normally have IPv6 GUA.<= o:p>

=     If you are talking about customers with private IPv4 rea= ching public IPv4 destination CDNs, yes we could explain it because it is t= he main scenario we actually some content providers offers to ISPs to deliv= er content from public IPv4 of CDN to customers with private IPv4 avoiding = a CGN platform. That was the first reason to create this document.

 &n= bsp; 

    >

    >

  &= nbsp; > * Section 4.3:

    >   One more adva= ntage of this solution is that the EAMT pairs doesn't

<= div>

    &g= t;   need to match the "real" IPv4/IPv6 addresses avail= able in the A/AAAA

    >   records, as shown in= the next example.

    >

    > Please = elaborate.

 

-> I think it is clear if you look at the example.

&nb= sp;

    >

    >

<= div>

    &g= t; * Section 5:

    >   If NAT46/CLAT/DNS-proxy= -EAM approach (Section 4.2) is chosen, it can

    >   be com= plemented to resolve this issue, by means of making sure that

  &= nbsp; >   IPv6-only destinations have one A resource record (e= ven an invalid

    >   one), despite they aren'= t actually connected to IPv4.

    >

=

    &= gt; Not sure what you mean.

 

-> I think it is clear if you read th= e paragraph before that one. Otherwise we could expand the text to make it = more obvious.

 

    It's an idea, we offer different id= eas (approaches) to try optimize the traffic flow.

    Here,= the idea is that if the destination is IPv6-only, when we have an IPv4-onl= y device, in a normal case you could never reach the destination but if you= have this optimization your Proxy DNS could detect that it doesn't have an= A record but it has an AAAA record, so you could be connected to the IPv6 = destination. Without this, your IPv4-only device would not be able to get t= he IPv6-only content.

   

    >

 =    >

    > * Section 5:

    = >   In fact, it may become an incentive for the IPv6 deploymen= t in

    >   Internet services and provides the= option to use an IPv4 address

    >   (maybe a= nycast) for the "non-valid" A resource record, that points to

&nb= sp;   >   a "universal" web page (maybe ho= sted by IETF?) that displays a

    >   warning = such as "Sorry, you don't IPv6 support in your operator, so=

 &nbs= p;  >   this service is not available for you".=

&nbs= p;   >

    > Please *no*, for so many diffe= rent reasons. -- including "the average

    > user d= oesn't care about IPv6, and may not even be aware of what it is".=

&nbs= p;

-> It can be a different text not necessarily mention IPv6 but just &= quot;your Internet connection is not able to access this content, please as= k your ISP to upgrade it". Anyway, it is very contentious topic ... Th= is probably will get removed in a new version, or moved to an annex, etc.

 

    Ok, it could be, but remember it is another= proposal like the other approaches and the idea is to get these kind of in= puts.

   

    >

    > =

    >

    > * Section 6:

  =   >   Should we recommend having A records for IPv6-only = services in

    >   Internet?  The A recor= d may point to a "reserved" or "special" IPv4

 &nb= sp;  >   address.  A web page IPv4-only hosted by IE= TF(?) showing "sorry this

    >   web page= /service is only available from IPv6 enabled operators"?.

  =   >

    > Please no. This assumes (?) hosts pref= er IPv6, but they don't need to.

    > In which case they= would get to such page and have a not so great

    > WTH= (!?) moment.

    >

    >

  =   >

    > * Section 6:

=

    >&n= bsp;  NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right<= o:p>

=     >   solution for optimizing the access to d= ual-stack services, whether

    >   they are lo= cated inside or outside the ISP.

    >

   = ; > It would seem to me that, actually, Approach #3, when the ISP has no=

    > control on the CDN, or approach #1 (when it does),= are the way to go.

    > Approach #2 seems rather comple= x, with the consequent opportunities to

    > screw up.=

    Approach #1 is not easy to be implemented because conte= nt providers doesn't want to be envolved on this process despite agreeing i= t can be an improvement , so the don't want to do any change in configurati= on of their devices / interfaces. It applies more in case where CDN is cont= rolled by ISP (own CDN), but we want to define a general solution, we need = to consider the normal case of public / external CDNs.

=

    Approa= ch #3, as you say, it is when ISP doesn't have control of the CDN. This is = could not be a very scalable solution because it's not dynamic and any chan= ge needs to be propagated to all CPEs. On the other hand it's a very easy m= ethod to make a fast deploy where there are not often changes. I think this= is a way where that allow to the operator to deploy the solution quickly w= ithout depending on complex mechanisms and where content provider doesn't c= hange DNS records, this is the case of Netflix CDN where A and AAAA records= always have the same IPs associated for the same FQDN (for CDN).

 &nb= sp;  Approach #2, yes, clearly it is more complex but it will depends = on how much complexity we want to give to the process and we need to define= very well which cases we want to consider.

    <= /p>

  = ; 

    >

    >

  &nbs= p; > * Section 6:

    >   SIIT already has a= SHOULD for EAM support.  Should 464XLAT be updated

   = >   by this document so the CLAT has a MUST for EAM support?.=

    >

    > 464xlat employs existing = technologies. So I'm not sure you can do a MUST

    > in = 464xlat, when it relies on SIIT, and for SIIT the requirement is a

 &n= bsp;  > SHOULD.

    Yes, what you say is valid, thes= e are questions to see exactly what the community thinks.

   = ;

    >

    > Besides, the 464xlat sp= ec does not even employ RFC2119 language.

    >

 &n= bsp;  >

    >

    > * Section= 7:

    >

    > Any solution where you= spoof DNS records would play bad with DNSsec.

    > This= should at least be discussed.

    >

    = >

    > Thanks!

    >

  &nb= sp; > Cheers,

    > Fernando

=

    > <= o:p>

=     >

    >

=

    > <= o:p>

=     > On 11/12/19 14:24, Ron Bonica wrote:

=

  &n= bsp; >> Folks,

    >>

=

    >&g= t; 

    >>

    >> Each wee= k between now and IETF 107, we will review and discuss one draft=

 &nbs= p;  >> with an eye towards progressing it.

<= div>

    &g= t;>

    >> 

    >>

&nb= sp;   >> This week, please review and comment on=

 &nbs= p;  >> draft-palet-v6ops-464xlat-opt-cdn-caches.

<= /div>

  &nb= sp; >>

    >> 

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

    >> When reviewing this draft, please indicate w= hether you think that V6OPS

    >> should adopt it a s= a work item.

    >>

    >> = ;

    >>

    >>  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Fred and Ron

    >>

    >= ;> 

    >>

    >> =

&nbs= p;   >> Juniper Business Use Only

=

    >&g= t;

    >>

    >> ___________________________________________= ____

    >> v6ops mailing list

    >= > v6ops@ietf.org

    >> =

&nbs= p;   >

    >

    > --

&n= bsp;   > Fernando Gont

    > SI6 Networks

&n= bsp;   > e-mail: fgon= t@si6networks.com

    > PGP Fingerprint: 6666 31C6 = D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

    >

 &n= bsp;  >

    >

    >

 &n= bsp;  > _______________________________________________<= /p>

  = ;  > v6ops mailing list

   

    ________________________= _______________________

    v6ops mailing list

  &= nbsp; v6ops@ietf.org

   

 

 

 

**= ********************************************

IPv4 is over

Are you ready for= the new Internet ?

The IPv6 Company

 =

This= electronic message contains information which may be privileged or confide= ntial. The information is intended to be for the exclusive use of the indiv= idual(s) named above and further non-explicilty authorized disclosure, copy= ing, distribution or use of the contents of this information, even if parti= ally, including attached files, is strictly prohibited and will be consider= ed a criminal offense. If you are not the intended recipient be aware that = any disclosure, copying, distribution or use of the contents of this inform= ation, even if partially, including attached files, is strictly prohibited,= will be considered a criminal offense, so you must reply to the original s= ender to inform about this communication and delete it.

 

 <= /o:p>

 = ;

_______________________________________________

=

v6ops mailing list



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

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

**********************************************
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_3661175421_1151710743-- From nobody Mon Jan 6 09:58:12 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5501200FD for ; Mon, 6 Jan 2020 09:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 ILKpF62sEMqC for ; Mon, 6 Jan 2020 09:58:07 -0800 (PST) Received: from gw2mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (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 EF18D1200FB for ; Mon, 6 Jan 2020 09:58:06 -0800 (PST) Received: from gw2mail.telecentro.local (localhost [127.0.0.1]) by gw2mail.telecentro.net.ar (Postfix) with ESMTP id 375B1201B1; Mon, 6 Jan 2020 14:57:50 -0300 (-03) Received: from mail.telecentro.net.ar (unknown [10.4.20.96]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gw2mail.telecentro.net.ar (Postfix) with ESMTPS; Mon, 6 Jan 2020 14:57:39 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id A90B7320093A; Mon, 6 Jan 2020 14:57:53 -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 0cxxd0Kf6_o4; Mon, 6 Jan 2020 14:57:52 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 8EBE13200948; Mon, 6 Jan 2020 14:57:52 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 8EBE13200948 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1578333472; bh=G9G6WIsTrCjTZO+II67rG5Wl13x9swwDeovp4Q0BHHI=; h=Date:Message-ID:To:From:MIME-Version; b=JmppVkJ9RH3uPVAaNXfCN8PbJkg114JRE6y5mvufrMQfRKnveDOt91pXyBl0F4t3V xBDfcO61NJ0x+g53HHcluZygmda5m2GnaN63AstNe4Gt9nXCLGQoM+GhNHlcd5yAos FBfONC36vR0vzpQq2MaLDokD1BdL9QlAp0lpseuOhSC0QlWEYFr/DtG8IEBZNydgTV vBtE61/UhKb5Lo1skl+hY5Niv5RtzjW9ONqkkh8870+bQKhRekqUG6ev78GxUdZ8DG rTkrqRwiSl6a7v+tONissUzdX67LBrsnNFs3k/W2ANvLu8Od264212MdGlxVa6Lwmm L40vqfq3wemvg== 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 915R5dKyT8Lw; Mon, 6 Jan 2020 14:57:52 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 674C5320093A; Mon, 6 Jan 2020 14:57:52 -0300 (-03) Date: Mon, 6 Jan 2020 14:57:52 -0300 (ART) Message-ID: <20652dea-185e-458a-b052-da5de252bf8b@email.android.com> X-Android-Message-ID: <20652dea-185e-458a-b052-da5de252bf8b@email.android.com> To: xiechf@chinatelecom.cn Cc: JORDI PALET MARTINEZ , v6ops Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal From: Alejandro D'Egidio MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.12_GA_3803 (Android-Mail/2019.11.21.283644823.release(...758360) devip=186.141.138.211 ZPZB/65) Thread-Index: dzKsM4WGjEN2hC25H4pqk7P4kS6RGQ== Thread-Topic: draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-KSMG-Rule-ID: 1 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 149576 [Jan 06 2020] X-KSMG-AntiSpam-Version: 5.8.14.0 X-KSMG-AntiSpam-Envelope-From: adegidio@telecentro.net.ar X-KSMG-AntiSpam-Auth: dkim=pass header.d=telecentro.net.ar X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Info: LuaCore: 336 336 9396dd2f401bf2feca9da187509bda34e224ee24, {Tracking_content_type, html}, {Tracking_from_domain_doesnt_match_to}, email.android.com:7.1.1; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; telecentro.net.ar:7.1.1; www.ietf.org:7.1.1; mail.telecentro.net.ar:7.1.1; 127.0.0.199:7.1.2; www.theipv6company.com:7.1.1 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean, bases: 2020/01/06 17:26:00 X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.12, bases: 2020/01/06 16:18:00 #14976795 X-KSMG-AntiVirus-Status: Clean, skipped Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jan 2020 17:58:11 -0000 PGRpdiBkaXI9J2F1dG8nPjxkaXY+SGkgQ2hvbmdmZW5nLDwvZGl2PjxkaXYgZGlyPSJhdXRvIj48 YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPkkgd2lsbCB0cnkgdG8gYW5zd2VyIGluIGxpbmUuPC9k aXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+VGhhbmtzITxicj48 YnI+PGRpdiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIiBkaXI9ImF1dG8iPkJSLDxi cj5BbGVqYW5kcm88L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSIgZGlyPSJhdXRvIj48YnI+ PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkVsIDYgZW5lLiAyMDIwIDA1OjM2LCB4aWVjaGZAY2hp bmF0ZWxlY29tLmNuIGVzY3JpYmnDszo8YnIgdHlwZT0iYXR0cmlidXRpb24iPjxibG9ja3F1b3Rl IGNsYXNzPSJxdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXY+CjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRp dj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtsaW5lLWhlaWdodDoxLjU7YmFja2dyb3Vu ZC1jb2xvcjp0cmFuc3BhcmVudCI+SGnvvIxKb3JkaSw8L3NwYW4+PC9kaXY+PGRpdj5JIGhhdmUg dGhlIGZvbGxvd2luZyBjb21tZW50cyBhZnRlciByZWFkaW5nIHRoZSBkcmFmdCw8L2Rpdj48ZGl2 PjFcVGhpcyBkcmFmdCBpcyBhYm91dCBJUHY2LW9ubHkgZm9yIHRoZSBhY2NjZXNzIG9mIElQdjQt b25seSBjbGllbnQgdG8gZHVhbC1zdGFjayBDRE4vQ2FjaGVzLiBGcm9tIHRoZSBwZXJzcGVjdGl2 ZSBvZiBvcGVyYXRpb24sIGV2ZXJ5IHBvc3NpYmxlIGFwcHJvYWNoIHByb3Bvc2VkIHNob3VsZCBu b3QgcG9zZSBhZGRpdGlvbmwgcmVxdWlybWVudHMgZm9yIHRoZSBuZXR3b3JrIGNvbmZpZ3VyYXRp b24uJm5ic3A7PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2 PjxkaXYgZGlyPSJhdXRvIj5Gcm9tIG9uZSBwb2ludCBvZiB2aWV3IGl0J3MgdHJ1ZSB0aGF0IGl0 J3MgYmV0dGVyIHRvIG5vdCB0cnkgdG8gbWFrZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBmb3Ig dGhlIG5ldHdvcmsgY29uZmlndXJhdGlvbiBidXQgaW4gc29tZSBjYXNlcyBidXQgaW4gc29tZSBj YXNlcyB3aGVyZSB0aG9zZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBhcmUgc3RhdGljcyAoaWUg RlFETiBvZiBOZXRmbGl4IENETikgaXQncyBub3QgYSBwcm9ibGVtLCBpbiBmYWN0IHRoaXMgY291 bGQgYmUgYSBiZXR0ZXIgYSBzaW1wbGUgd2F5IHRvIGltcGxlbWVudCBpdC48L2Rpdj48ZGl2IGRp cj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48ZGl2IGNsYXNzPSJnbWFpbF9leHRy YSI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxibG9ja3F1b3RlIGNsYXNzPSJxdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPjxkaXY+PGRpdj48ZGl2PjJcIEJhc2VkIG9uIG15IGV4cGVyaWVuY2UsIEkgdGhp bmsgdGhlIHBvc3NpYmlsaXR5IG9mIFhMQVQgdG8gYmUgdXNlZCBpbiB3aXJlbGluZSBuZXR3b3Jr IGlzIHZlcnkgc21hbGwsIElzIHRoZXJlIGFueSBsYXJnZS1zY2FsZSBJU1Agd2hvIHBsYW4gdG8g dXNlIFhMQVQgZm9yIHdpcmVsaW5lIGJyb2FkYmFuZD8gTmVhcmx5IGV2ZXJ5IElQdjYtY2FwYWJs ZSBDUEUgaXMgZHVhbCBzdGFjaywgaXQgaXMgdmVyeSBkaWZmaWN1bHQgdG8gY29udmluY2UgdGhl IENQRSBpbmR1c3RyeSB0byBzdXBwb3J0IFhMQVQgaW4gdGhlIGZvcnNlZW4gZnV0dXJlLiBBbm90 aGVyIGZhY3RvciB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBpcyB0aGF0IHRoZSBJUFRWIHNlcnZp Y2Ugb2Ygc29tZSBJU1BzIGlzIGNhcnJpZWQgaW4gYSBzZXBlcmF0ZSBsYXllci10d28gY2hhbm5s ZSwgd2hpY2ggZG9lcyBub3QgbWl4IHdpdGggdGhlIGRlZmF1bHQgSW50ZXJuZXQgYWNjZXNzIHRy YWZmaWMuJm5ic3A7Jm5ic3A7PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjwv ZGl2PjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5JIHdvcmsgaW4gYSBjYWJsZSBvcGVyYXRvciBhbmQg SSB3b3VsZCBsaWtlIHRvIGltcGxlbWVudCA0NjRYTEFULiBDYWJsZWxhYnMgaGFzIGRlZmluZWQg TUFQLVQgYXMgYSBNVVNUIGluIGNhYmxlbW9kZW0gZmlybXdhcmUgc2luY2UgbGFzdCB5ZWFycy4g VGhpcyBvcHRpbWl6YXRpb24gd29ya3MgYWxzbyBmb3IgTUFQLVQuIE9uIHRoZSBvdGhlciBoYW5k LCBkZXNwaXRlIG9mIDQ2NFhMQVQgaXMgbm90IGluY2x1ZGVkIGluIGNhYmxlbGFicyBzcGVjaWZp Y2F0aW9ucywgU2FnZW1jb20gZGV2ZWxvcGVkIGEgRlcgZm9yIENNIHN1cHBvcnRpbmcgaXQuIEkg aGF2ZSBwcmVzZW50ZWQgaXQgTEFDTklDIDMxIGV2ZW50LjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48 YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxibG9ja3F1b3RlIGNsYXNz PSJxdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXY+PGRpdj48ZGl2PjNcSSBkb24ndCB0aGluayB0aGUg SVAgYWRkcmVzcyAxOTIuMC4yLjEgdXNlZCBpbiB0aGUgZXhhbXBsZSBpcyBzdWl0YWJsZSwgZm9y IHRoZSBJUCBhZGRyZXNzIDE5Mi4wLjAuMC8xNiBoYXMgYmVlbiBkZWZpbmVkIHVzZWQgZm9yIHNw ZWNpYWwgcHVycG9zZSwgbWF5YmUgdGhlIHB1YmxpYyBJUCBhZGRyZXNzIGlzIGJldHRlciBmb3Ig dGhlIGludGVyZmFjZSBvZiBDRE4gc2VydmVyLjwvZGl2PjxkaXY+Jm5ic3A7NFxJbiBhZGRpdGlv biwgdGhlIHRpdGxlIG9mIHRoZSBkcmFmdCAiNDY0WExBVCBPcHRpbWl6YXRpb24iIGlzIHRvbyBn ZW5lcmFsIGFuZCBhbWJpZ3VvdXMsIEkgdGhpbmsgYSBtb3JlIHNwZWNpZmljIG9uZSBpcyBiZXR0 ZXIuPC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYg ZGlyPSJhdXRvIj5ZZXMsIGl0IGNvdWxkIGJlLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9k aXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGRpdiBjbGFzcz0i Z21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48YmxvY2txdW90ZSBjbGFzcz0i cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2PjxkaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0IHJl Z2FyZHM8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNob25nZmVuZyZuYnNwOzwvZGl2PjwvZGl2 Pgo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7bWFy Z2luLWxlZnQ6MC41ZW0iPjxkaXY+Jm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDFwdDtwYWRkaW5nOjNwdCAwY20gMGNtIDBjbSI+PGRp diBzdHlsZT0icGFkZGluZy1yaWdodDo4cHg7cGFkZGluZy1sZWZ0OjhweDtmb250LXNpemU6MTJw eDtmb250LWZhbWlseTondGFob21hJztjb2xvcjojMDAwMDAwO2JhY2tncm91bmQ6I2VmZWZlZjtw YWRkaW5nLWJvdHRvbTo4cHg7cGFkZGluZy10b3A6OHB4Ij48ZGl2PjxiPkZyb206PC9iPiZuYnNw OzxhIGhyZWY9Im1haWx0bzpqb3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYu b3JnIj5KT1JESSBQQUxFVCBNQVJUSU5FWjwvYT48L2Rpdj48ZGl2PjxiPkRhdGU6PC9iPiZuYnNw OzIwMjAtMDEtMDYmbmJzcDswNDo1NjwvZGl2PjxkaXY+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9 Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmcgbGlzdDwvYT48L2Rpdj48ZGl2 PjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbdjZvcHNdIGRyYWZ0LXBhbGV0LXY2b3BzLTQ2NHhs YXQtb3B0LWNkbi1jYWNoZXMgKipDYWxsIGZvciBBZG9wdGlvbioqPC9kaXY+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PkhpIEZlcm5hbmRvLDwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkFkZGlu ZyBzb21lIGlucHV0cywgYmVsb3csIGluLWxpbmUgKC0mZ3Q7KS48L2Rpdj4KPGRpdj4gPC9kaXY+ CjxkaXY+IDwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pu+7v0VsIDQvMS8yMCA0OjM0LCAi djZvcHMgZW4gbm9tYnJlIGRlIEFsZWphbmRybyBEJ0VnaWRpbyIgJmx0O3Y2b3BzLWJvdW5jZXNA aWV0Zi5vcmcgZW4gbm9tYnJlIGRlIGFkZWdpZGlvPTQwdGVsZWNlbnRyby5uZXQuYXJAZG1hcmMu aWV0Zi5vcmcmZ3Q7IGVzY3JpYmnDszo8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4mbmJz cDsmbmJzcDsmbmJzcDsgSGVsbG8gRmVybmFuZG8sPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBGaXJzdCBhdCBhbGwsIHRoYW5rcyBm b3IgeW91ciBzdXBwb3J0IHRvIHRoZSB3b3JrIGFuZCB0aGUgZG9jdW1lbnQgYW5kIGZvciB0YWtp bmcgeW91ciB0aW1lIHRvIHJlYWQgYWxsIHRoZSBkb2N1bWVudC48L2Rpdj4KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2lsbCB0cnkgdG8g YW5zd2VyIHlvdXIgY29tbWVudHMgYmVsb3cuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsm bmJzcDsgUmVnYXJkcyw8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgQWxlamFuZHJvPC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyAtLS0tLSBNZW5zYWplIG9yaWdpbmFsIC0tLS0tPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgRGU6ICJGZXJuYW5kbyBHb250IiAmbHQ7ZmdvbnRAc2k2bmV0d29ya3MuY29tJmd0 OzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFBhcmE6ICJSb24gQm9uaWNhIiAm bHQ7cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnJmd0OywgInY2b3BzQGlldGYu b3JnIGxpc3QiICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBFbnZpYWRvczogVmllcm5lcywgMyBkZSBFbmVybyAyMDIwIDIwOjQwOjExPC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQXN1bnRvOiBSZTogW3Y2b3BzXSBkcmFm dC1wYWxldC12Nm9wcy00NjR4bGF0LW9wdC1jZG4tY2FjaGVzICoqQ2FsbCBmb3IgQWRvcHRpb24q KjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBGb2xrcyw8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8L2Rp dj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBJJ3ZlIHJlYWQgdGhlIGRvY3VtZW50LCBh bmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEl0IHdvdWxkIHNl ZW0gdG8gbWUgaXMgdGhhdCB0aGlzIGRvY3VtZW50IGhhcyByZXN1bHRlZCBmcm9tIGFuPC9kaXY+ CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgb3BlcmF0b3JzJyBjb25jZXJuIHRoYXQgZGVw bG95bWVudCBvZiA0NjR4bGF0IG1pZ2h0IHJlc3VsdCBpbjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IHVubmVjZXNzYXJ5IGhlYXZ5d2VpZ2h0IHVzZSBvZiB0aGUgc3RhdGVmdWwg UExBVCwgbGVhZGluZyB0byBzY2FsYWJpbGl0eTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IHByb2JsZW1zIG9yIHVubmVjZXNzYXJ5IG1vbmV5IHNwZW5kaW5ncy4gSW4gdGhhdCBz ZW5zZSwgSSB3b3VsZCBsaWtlIHRoZTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGlzc3VlIHRvIGJlIGRvY3VtZW50ZWQgKGV2ZW4gaWYgc29tZWhvdyB3ZSBkb24ndCBhZ3JlZSBv biBhIHdvcmthcm91bmQpLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBZZXMsIGZyb20g b25lIHBvaW50IG9mIHZpZXcgaXQgaXMgY29ycmVjdCB3aGF0IHlvdSBzYWlkIGFuZCBpbiBhZGRp dGlvbiB0byB0aGF0IHdlIGhhdmUgYW4gdW5uZWNlc3Nhcnkgc2Vjb25kIHRyYW5zbGF0aW9uIChO QVQ2NCkgd2hlbiBjdXN0b21lciB0cmFmZmljIHdhcyB0cmFuc2xhdGVkIHRvIElQdjYgKE5BVDQ2 KSBhbmQgdGhlIGRlc3RpbmF0aW9uIChjb250ZW50KSBpcyBhdmFpbGFibGUgaW4gSVB2NiBhbHNv LCBzbyB3ZSBjb3VsZCBhdm9pZCBib3RoIGEgYm90dGxlbmVjayBhbmQgYSBwZXJmb3JtYW5jZSBp bXBhaXJtZW50LiBUaGF0J3Mgd2h5IHdlIGNvbnNpZGVyIHRoaXMgYXMgYW4gb3B0aW1pemF0aW9u LjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pi0mZ3Q7IEkgdGhpbmsgdGhlIGRvY3VtZW50 IGlzIGRvaW5nIHRoZSB3b3JrIG9mIGRvY3VtZW50aW5nIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBh bmQgcHJvdmlkaW5nIHBvc3NpYmxlIHNvbHV0aW9ucywgd2hpY2ggdGhlIGlkZWEgb2YgY2hvb3Np bmcgb25lLiBXZSB1bmRlcnN0YW5kIHRoYXQgNDY0WExBVCB3YXMgbm90IGRlc2lnbmVkIGhhdmlu ZyB0aGlzIHNjZW5hcmlvIGluIG1pbmQsIGJ1dCBpZiB3ZSBjYW4gZmluZCBhIGdvb2Qgc29sdXRp b24sIGlzIHdvcnRoIHRvIHNvbHZlIGl0LiBGdXJ0aGVybW9yZSwgaWYgdGhlIFdHIGFncmVlIHRo YXQgdGhpcyBpcyB0aGUgd2F5IHRvIGdvLCB3ZSBjb3VsZCB1cGRhdGUgd2l0aCB0aGlzIGRvY3Vt ZW50IDQ2NFhMQVQgKHdoaWNoIGlzIGFuIGluZm9ybWF0aW9uYWwgb25lKSBhbmQgbWFrZSBpdCB0 byB0aGUgc3RhbmRhcmRzIHRyYWNrLiBBcyBJJ3ZlIGFscmVhZHkgZXhwcmVzc2VkIHNldmVyYWwg dGltZXMsIGl0IGlzIHBpdHkgdGhhdCBiZWluZyB0aGUgdHJhbnNpdGlvbiBtZWNoYW5pc20gdGhh dCBpcyBtb3JlIHVzZWQgaW4gdGhlIHdvcmxkICh2ZXJzdXMgYWxsIHRoZSBvdGhlcnMsIGluIHRl cm1zIG9mIG51bWJlciBvZiBkZXZpY2VzKSwgaXQgaXMgbm90IGEgc3RhbmRhcmQuPC9kaXY+Cjxk aXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyA8L2Rp dj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBTbyBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKG9y IHNvbWUgdmVyc2lvbiBvZiBpdCkgLS08L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyBpLmUuLCB0aGVyZSdzIHZhbHVlIGluIGRvY3VtZW50aW5nIHRoZSBpc3N1ZSBpdHNlbGYuPC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgVGhhdCBzYWlkLCBJIHRoaW5rIHRoYXQgZnVydGhlciB3b3JrIGlzIHJlcXVp cmVkIG9uIHRoZSBkb2N1bWVudC4gUExlYXNlPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgZmluZCBteSByZXZpZXcgYmVsb3c6PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgKioqKiBTb21lIG1ldGEgY29tbWVudHMgKioqKjwvZGl2Pgo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICogTWV0YTogSSdkIHB1dCBtb3JlIHN0cmVzcyBvbiB3aHkgdGhpcyAib3B0aW1pemF0 aW9uIiBpcyBpbXBvcnRhbnQuIFlvdTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGRlbHZlIGludG8gbWFueSBvdGhlciAocmF0aGVyIHVubmVjZXNzYXJ5KSBkZXRhaWxzLCBidXQg ZG9uJ3QgZWxhYm9yYXRlPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbXVjaCBy ZWdhcmRpbmcgd2h5IHRoaXMgIm9wdGltaXphdGlvbiIgaXMgaW1wb3J0YW50LjwvZGl2Pgo8ZGl2 PiZuYnNwOzwvZGl2Pgo8ZGl2Pi0mZ3Q7IE15IHJlYWRpbmcgaXMgdGhhdCB0aGUgb3B0aW1pemF0 aW9uIGFuZCB0aGUgbmVlZCBmb3IgaXQgaXMgd2VsbCBkZXNjcmliZWQsIGJ1dCBkZWZpbml0aXZl bHkgd2lsbCB0YWtlIGEgbG9vayBpbnRvIGl0IGFuZCBpbXByb3ZlIGl0IGlmIG5lZWRlZC48L2Rp dj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgWWVzLCBpdCBpcyB0 cnVlLCBtYXliZSB0aGUgaW50cm9kdWN0aW9uIGNvdWxkIGJlIHNpbXBsZXIgYW5kIG1vcmUgb3Jp ZW50ZWQgdG8gc2hvdyB0aGUgY29uY3JldGUgcHJvYmxlbSBhbmQgd2h5IHdlIGJlbGlldmUgdGhp cyBpcyBpbXBvcnRhbnQuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvZGl2Pgo8ZGl2 PiZuYnNwOyZuYnNwOyZuYnNwOyBJIGRvbid0IGtub3cgaWYgdGhlIGluZm8gaXMgd3JvbmcsIG1h eWJlIGEgc3BlY2lmaWMgaW5pdGlhbCBzdW1tYXJ5IHRoYXQgaW5kaWNhdGVzIGl0IGlzIG1pc3Np bmcuIFdlIGNhbiBjb25zaWRlciBpdC48L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICogTWV0YTogSXQnZCBi ZSBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0LCBhY2NvcmRpbmcgdG8gdGhlIEFic3RyYWN0IG9mPC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgUkZDNjg3NywgNDY0WExBVCBhc3N1bWVz IElQdjQgc2VydmljZXMgb3ZlciBhbiBJUHY2LW9ubHkgbm9kZS4gSW4gdGhhdDwvZGl2Pgo8ZGl2 PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHNlbnNlLCB0aGUgYmVoYXZpb3IgeW91IGRlc2NyaWJl IGlzIGtpbmQgb2YgImV4cGVjdGVkIiwgYW5kIHdoYXQgeW91PC9kaXY+CjxkaXY+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgZGVzY3JpYmUgd291bGQgc2VlbSB0byBtZSBtb3JlIG9mIGEgbWVjaGFu aXNtIHRvICpvcHQgb3V0IG9mIDQ2NHhsYXQqPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgdGhhbiBhbiBvcHRpbWl6YXRpb24gdG8gNDY0WExBVCBpdHNlbGYuPC9kaXY+CjxkaXY+ Jm5ic3A7PC9kaXY+CjxkaXY+LSZndDsgWWVzLCBJIHNhaWQgdGhhdCBpbiBteSBmaXJzdCBjb21t ZW50LiBXaXRoIHRoaXMgb3B0aW1pemF0aW9uLCBpZiB3ZSBhcmUgYWJsZSB0byBmaW5kIGNvbnNl bnN1cyBpbiBhIGdvb2Qgc29sdXRpb24sIHdlIGltcHJvdmUgc29tZXRoaW5nIHRoYXQgd2FzIG5v dCBpbml0aWFsbHkgZXhwZWN0ZWQgdG8gYmUgZG9uZSBieSA0NjRYTEFULiBJIGRvbid0IHNlZSB0 aGUgIm9wdC1vdXQiIHBvaW50IHRoYXQgeW91IG1lbnRpb24uPC9kaXY+CjxkaXY+Jm5ic3A7PC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFllcywgNDY0WExBVCBhc3VtZXMgYm90aCBJUHY0 IHNlcnZpY2VzIGFuZCBJUHY0LW9ubHkgZGV2aWNlcyBhbHNvLjwvZGl2Pgo8ZGl2PiZuYnNwOyZu YnNwOyZuYnNwOyBZZXMsIHRoaXMgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIG9mIDQ2NFhMQVQg KGFuZCBNQVAtVCBhbHNvKSBidXQgZnJvbSBhIHByYWN0aWNhbCBhbmQgcGVyZm9ybWFuY2UgcG9p bnQgb2YgdmlldywgbWF5YmUsIGl0IGlzIG5vdCB0aGUgbW9zdCBvcHRpbWFsIHBhdGggZm9yIHRo ZSBlbmQtdG8tZW5kIHRyYWZmaWMgZmxvdy4gQXMgeW91IHNhaWQgaWYgd2UgYXZvaWQgdGhlIE5B VDY0LCB0ZWNobmljYWxseSBzcGVha2luZywgdGhlIHRyYWZmaWMgd2lsbCBub3QgYmUgZ29pbmcg dGhyb3VnaCBhIDQ2NFhMQVQvTUFQLVQgc2NlbmFyaW8uPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFdlIGFyZSBub3Qgc2F5aW5nIHRoYXQgNDY0WExBVCBpcyB3cm9uZyBhdCBhbGwsIHdl IGFyZSB0cnlpbmcgdG8gZXhwb3NlIGEgcmVhbCBwcm9ibGVtIGZvciBJUHY2IG9ubHkgbmV0d29y ayBkZXBsb3ltZW50cyBhbmQgdHJ5aW5nIHRvIHByZXNlbnQgc29tZSBhcHByb2FjaGVzIHRvIHNv bHZlIGl0IChvciBtaW5pbWl6ZSBpdCkuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv ZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICogSXQgd291bGQgc2VlbSB0byBtZSB0aGF0IHRoZSBjYXNlcyB3aGVyZSB0 aGlzIGlzc3VlIGlzIG1vcmUgb2YgYTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGNvbmNlcm4gaXMgZXNzZW50aWFsbHkgc21hcnRib3hlcyAoc21hcnQgVFZzKSBjb25zdW1pbmcg bWVkaWEgZnJvbSBsYXJnZTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IENETnMu IElmIHNvLCB0aGlzIHNob3VsZCBiZSBzcGVsbGVkIG91dCwgc2luY2UgdGhpcyBlc3NlbnRpYWxs eSBzZXRzIHRoZTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGNvbnRleHQgZm9y IHdoYXQgb3B0aW9ucy9hcHByb2FjaGVzIGNhbiBiZSBjb25zaWRlcmVkIGFjY2VwdGFibGUuPC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9rLCB5ZXMsIHdlIGNhbiBwdXQgbW9yZSBlZmZv cnQgdG8gZXhwbGFpbiB0aGF0LjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8L2Rpdj4K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAqKiogU29tZSBzcGVjaWZpYyBjb21tZW50czog KioqKjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICogQWJzdHJhY3Q6IEknbSBjdXJpb3VzIGlmIHRoZSB0ZXJtICJO QVQ0NiIgY2FuIGJlIGNvbmZ1c2luZywgZm9yPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgbXVsdGlwbGUgcmVhc29ucyAoZm9yIGluc3RhbmNlLCBpdCdzIG5vdCBzcGVjaWZpZWQg aW4gUkZDNzkxNSkuIEp1c3QgdXNlPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg IlNJSVQiLCBhbmQgdGhlIGNvbnRleHQgKGkuZS4sIGRlc2NyaWJlIHdoYXQncyBvbiBlYWNoIHNp ZGUgb2YgdGhlIFNJSVQ8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBkZXZpY2Us IGFuZCB3aGF0J3MgdGhlIGludGVudCkuPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+LSZn dDsgSW5pdGlhbGx5IHdlIHdlcmUgdXNpbmcgdGhlIHRlcm0gQ0xBVCwgYnV0IHRoZW4gd2UgcmVh bGl6ZWQgdGhhdCBNQVAtVCBoYXMgdGhlIHNhbWUgaXNzdWUsIGFuZCB0aGVyZSBpdCBpcyBub3Qg Y2FsbGVkIENMQVQsIGJ1dCBOQVQ0Ni4gVGhpcyBpcyB0aGUgcmVhc29uLCBxdWl0ZSBzaW1wbGUs IGJlY2F1c2UgdGhlIG9wdGltaXphdGlvbiB3aWxsIGFsc28gd29yayBmb3IgTUFQLVQuPC9kaXY+ CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdlIGNhbiByZXZpZXcg aXQgaWYgaXQgaXMgY29uZnVzaW5nLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUg aWRlYSBvbiB0aGlzIHBvaW50IHdhcyB0byB0YWxrIGFib3V0IHRoZSBOQVQ0NiBvZiBDUEUgKENM QVQpLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBZZXMsIFJGQzc5MTUgdGFsa3MgYWJv dXQgU0lJVCBpbmRlcGVuZGVudGx5IGlmIGl0IGlzIE5BVDQ2IG9yIG5vdC48L2Rpdj4KPGRpdj4m bmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkaW5nICIoSVAvSUNNUCBUcmFuc2xhdGlvbiBBbGdvcml0 aG0pIGFzIGRlc2NyaWJlZCBieSBbUkZDNzkxNV0iIGl0IHJlZmVycyBqdXN0IHRvIFNJSVQuPC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFzIHdlIGtub3csIENMQVQgaXMgYSBjb21iaW5h dGlvbiBvZiBOQVQ0NiArIFNJSVQgYmVjYXVzZSBpdCdzIGFuIHN0YXRlbGVzcyB0cmFuc2xhdGlv biBmcm9tIElQdjQgdG8gSVB2Ni48L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgKiBJbnRy b2R1Y3Rpb246PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSXQgc2VlbXMgdG8g bWUgdGhlIGludHJvIGNvbnRhaW5zIHRvbyBtYW55IHVubmVjZXNzYXJ5IGRldGFpbHMuIGUuZy4s PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsganVzdCB0YWxrIGFib3V0IHRoZSBD TEFUIGFzIGFuIGFic3RyYWN0IGNvbmNlcHQuIFdoZXJlL2hvdzwvZGl2Pgo8ZGl2PiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IChzcGVjaWZpY2FsbHkpIGl0IGlzIGltcGxlbWVudGVkIGlzIG1vc3Rs eSBpcnJlbGV2YW50IGluIHRoZSBjb250ZXh0IG9mPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgdGhpcyBkb2N1bWVudC48L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgWWVz LCBJIGRvbid0IGtub3csIGl0IGNvdWxkIGJlLCBhcyBJIHB1dCBhYm92ZSBtYXliZSBpbiB0aGUg aW50cm9kdWN0aW9uIHdlIHRhbGsgYWJvdXQgbWFueSBzcGVjaWZpYyB0aGluZ3MgYW5kIHdlIGNv dWxkIHRhbGsgbW9yZSBhYm91dCB0aGUgcHJvYmxlbSBpdHNlbGYuPC9kaXY+CjxkaXY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICogU2VjdGlvbiA0OjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IElz IHRoZSBvcHRpb24gd2hlcmUgcGFja2V0cyBtaWdodCBnZXQgdG8gdGhlIENhY2hlIHdpdGggKnBy aXZhdGUgc3BhY2UqPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgd29ydGggbWVu dGlvbmluZy9kZXNjcmliaW5nL2Rpc2N1c3Npbmc/PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+Cjxk aXY+LSZndDsgV2hlbiB3ZSB0YWxrZWQgd2l0aCBDRE4vY2FjaGUgcHJvdmlkZXJzLCB0aGV5IGRv bid0IGxpa2UgdG8gdXNlIG5vbi1HVUEgKGV4YW1wbGUgdGhlIE5BVDY0IFdLUCksIHNvIGl0IGlz IGRpc2N1c3NlZCBhcyBhbiBvcHRpb24gaW4gYXBwcm9hY2ggMS48L2Rpdj4KPGRpdj4mbmJzcDs8 L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgSSdtIHNvcnJ5IEkgZGlkbid0IHVuZGVyc3Rh bmQgaXQgdmVyeSB3ZWxsLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBXaGF0ICpwcml2 YXRlIHNwYWNlKiBhcmUgeW91IHRhbGtpbmcgYWJvdXQ/IElQdjQgb3IgSVB2Nj88L2Rpdj4KPGRp dj4mbmJzcDsmbmJzcDsmbmJzcDsgSWYgeW91IGFyZSB0YWxraW5nIGFib3V0IElQdjYsIENETnMg bm9ybWFsbHkgaGF2ZSBJUHY2IEdVQS48L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgSWYg eW91IGFyZSB0YWxraW5nIGFib3V0IGN1c3RvbWVycyB3aXRoIHByaXZhdGUgSVB2NCByZWFjaGlu ZyBwdWJsaWMgSVB2NCBkZXN0aW5hdGlvbiBDRE5zLCB5ZXMgd2UgY291bGQgZXhwbGFpbiBpdCBi ZWNhdXNlIGl0IGlzIHRoZSBtYWluIHNjZW5hcmlvIHdlIGFjdHVhbGx5IHNvbWUgY29udGVudCBw cm92aWRlcnMgb2ZmZXJzIHRvIElTUHMgdG8gZGVsaXZlciBjb250ZW50IGZyb20gcHVibGljIElQ djQgb2YgQ0ROIHRvIGN1c3RvbWVycyB3aXRoIHByaXZhdGUgSVB2NCBhdm9pZGluZyBhIENHTiBw bGF0Zm9ybS4gVGhhdCB3YXMgdGhlIGZpcnN0IHJlYXNvbiB0byBjcmVhdGUgdGhpcyBkb2N1bWVu dC48L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+Cjxk aXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgKiBTZWN0aW9uIDQuMzo8L2Rpdj4KPGRpdj4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyBPbmUgbW9yZSBhZHZhbnRhZ2Ugb2YgdGhp cyBzb2x1dGlvbiBpcyB0aGF0IHRoZSBFQU1UIHBhaXJzIGRvZXNuJ3Q8L2Rpdj4KPGRpdj4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyBuZWVkIHRvIG1hdGNoIHRoZSAicmVhbCIg SVB2NC9JUHY2IGFkZHJlc3NlcyBhdmFpbGFibGUgaW4gdGhlIEEvQUFBQTwvZGl2Pgo8ZGl2PiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IHJlY29yZHMsIGFzIHNob3duIGluIHRo ZSBuZXh0IGV4YW1wbGUuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+ CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgUGxlYXNlIGVsYWJvcmF0ZS48L2Rpdj4KPGRp dj4mbmJzcDs8L2Rpdj4KPGRpdj4tJmd0OyBJIHRoaW5rIGl0IGlzIGNsZWFyIGlmIHlvdSBsb29r IGF0IHRoZSBleGFtcGxlLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICogU2VjdGlvbiA1OjwvZGl2Pgo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IElmIE5BVDQ2L0NMQVQvRE5TLXByb3h5LUVB TSBhcHByb2FjaCAoU2VjdGlvbiA0LjIpIGlzIGNob3NlbiwgaXQgY2FuPC9kaXY+CjxkaXY+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsgYmUgY29tcGxlbWVudGVkIHRvIHJlc29s dmUgdGhpcyBpc3N1ZSwgYnkgbWVhbnMgb2YgbWFraW5nIHN1cmUgdGhhdDwvZGl2Pgo8ZGl2PiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IElQdjYtb25seSBkZXN0aW5hdGlvbnMg aGF2ZSBvbmUgQSByZXNvdXJjZSByZWNvcmQgKGV2ZW4gYW4gaW52YWxpZDwvZGl2Pgo8ZGl2PiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IG9uZSksIGRlc3BpdGUgdGhleSBhcmVu J3QgYWN0dWFsbHkgY29ubmVjdGVkIHRvIElQdjQuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgTm90IHN1cmUgd2hh dCB5b3UgbWVhbi48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4tJmd0OyBJIHRoaW5rIGl0 IGlzIGNsZWFyIGlmIHlvdSByZWFkIHRoZSBwYXJhZ3JhcGggYmVmb3JlIHRoYXQgb25lLiBPdGhl cndpc2Ugd2UgY291bGQgZXhwYW5kIHRoZSB0ZXh0IHRvIG1ha2UgaXQgbW9yZSBvYnZpb3VzLjwv ZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBJdCdzIGFuIGlk ZWEsIHdlIG9mZmVyIGRpZmZlcmVudCBpZGVhcyAoYXBwcm9hY2hlcykgdG8gdHJ5IG9wdGltaXpl IHRoZSB0cmFmZmljIGZsb3cuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhlcmUsIHRo ZSBpZGVhIGlzIHRoYXQgaWYgdGhlIGRlc3RpbmF0aW9uIGlzIElQdjYtb25seSwgd2hlbiB3ZSBo YXZlIGFuIElQdjQtb25seSBkZXZpY2UsIGluIGEgbm9ybWFsIGNhc2UgeW91IGNvdWxkIG5ldmVy IHJlYWNoIHRoZSBkZXN0aW5hdGlvbiBidXQgaWYgeW91IGhhdmUgdGhpcyBvcHRpbWl6YXRpb24g eW91ciBQcm94eSBETlMgY291bGQgZGV0ZWN0IHRoYXQgaXQgZG9lc24ndCBoYXZlIGFuIEEgcmVj b3JkIGJ1dCBpdCBoYXMgYW4gQUFBQSByZWNvcmQsIHNvIHlvdSBjb3VsZCBiZSBjb25uZWN0ZWQg dG8gdGhlIElQdjYgZGVzdGluYXRpb24uIFdpdGhvdXQgdGhpcywgeW91ciBJUHY0LW9ubHkgZGV2 aWNlIHdvdWxkIG5vdCBiZSBhYmxlIHRvIGdldCB0aGUgSVB2Ni1vbmx5IGNvbnRlbnQuPC9kaXY+ CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICogU2VjdGlvbiA1OjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IEluIGZhY3QsIGl0IG1heSBiZWNvbWUgYW4gaW5jZW50aXZl IGZvciB0aGUgSVB2NiBkZXBsb3ltZW50IGluPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmbmJzcDsmbmJzcDsgSW50ZXJuZXQgc2VydmljZXMgYW5kIHByb3ZpZGVzIHRoZSBvcHRp b24gdG8gdXNlIGFuIElQdjQgYWRkcmVzczwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jm5ic3A7Jm5ic3A7IChtYXliZSBhbnljYXN0KSBmb3IgdGhlICJub24tdmFsaWQiIEEgcmVz b3VyY2UgcmVjb3JkLCB0aGF0IHBvaW50cyB0bzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jm5ic3A7Jm5ic3A7IGEgInVuaXZlcnNhbCIgd2ViIHBhZ2UgKG1heWJlIGhvc3RlZCBi eSBJRVRGPykgdGhhdCBkaXNwbGF5cyBhPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmbmJzcDsmbmJzcDsgd2FybmluZyBzdWNoIGFzICJTb3JyeSwgeW91IGRvbid0IElQdjYgc3Vw cG9ydCBpbiB5b3VyIG9wZXJhdG9yLCBzbzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jm5ic3A7Jm5ic3A7IHRoaXMgc2VydmljZSBpcyBub3QgYXZhaWxhYmxlIGZvciB5b3UiLjwv ZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IFBsZWFzZSAqbm8qLCBmb3Igc28gbWFueSBkaWZmZXJlbnQgcmVhc29ucy4g LS0gaW5jbHVkaW5nICJ0aGUgYXZlcmFnZTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IHVzZXIgZG9lc24ndCBjYXJlIGFib3V0IElQdjYsIGFuZCBtYXkgbm90IGV2ZW4gYmUgYXdh cmUgb2Ygd2hhdCBpdCBpcyIuPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+LSZndDsgSXQg Y2FuIGJlIGEgZGlmZmVyZW50IHRleHQgbm90IG5lY2Vzc2FyaWx5IG1lbnRpb24gSVB2NiBidXQg anVzdCAieW91ciBJbnRlcm5ldCBjb25uZWN0aW9uIGlzIG5vdCBhYmxlIHRvIGFjY2VzcyB0aGlz IGNvbnRlbnQsIHBsZWFzZSBhc2sgeW91ciBJU1AgdG8gdXBncmFkZSBpdCIuIEFueXdheSwgaXQg aXMgdmVyeSBjb250ZW50aW91cyB0b3BpYyAuLi4gVGhpcyBwcm9iYWJseSB3aWxsIGdldCByZW1v dmVkIGluIGEgbmV3IHZlcnNpb24sIG9yIG1vdmVkIHRvIGFuIGFubmV4LCBldGMuPC9kaXY+Cjxk aXY+Jm5ic3A7PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9rLCBpdCBjb3VsZCBiZSwg YnV0IHJlbWVtYmVyIGl0IGlzIGFub3RoZXIgcHJvcG9zYWwgbGlrZSB0aGUgb3RoZXIgYXBwcm9h Y2hlcyBhbmQgdGhlIGlkZWEgaXMgdG8gZ2V0IHRoZXNlIGtpbmQgb2YgaW5wdXRzLjwvZGl2Pgo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAqIFNl Y3Rpb24gNjo8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyBT aG91bGQgd2UgcmVjb21tZW5kIGhhdmluZyBBIHJlY29yZHMgZm9yIElQdjYtb25seSBzZXJ2aWNl cyBpbjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IEludGVy bmV0PyZuYnNwOyBUaGUgQSByZWNvcmQgbWF5IHBvaW50IHRvIGEgInJlc2VydmVkIiBvciAic3Bl Y2lhbCIgSVB2NDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7 IGFkZHJlc3MuJm5ic3A7IEEgd2ViIHBhZ2UgSVB2NC1vbmx5IGhvc3RlZCBieSBJRVRGKD8pIHNo b3dpbmcgInNvcnJ5IHRoaXM8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNw OyZuYnNwOyB3ZWIgcGFnZS9zZXJ2aWNlIGlzIG9ubHkgYXZhaWxhYmxlIGZyb20gSVB2NiBlbmFi bGVkIG9wZXJhdG9ycyI/LjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2 Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFBsZWFzZSBuby4gVGhpcyBhc3N1bWVzICg/ KSBob3N0cyBwcmVmZXIgSVB2NiwgYnV0IHRoZXkgZG9uJ3QgbmVlZCB0by48L2Rpdj4KPGRpdj4m bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBJbiB3aGljaCBjYXNlIHRoZXkgd291bGQgZ2V0IHRvIHN1 Y2ggcGFnZSBhbmQgaGF2ZSBhIG5vdCBzbyBncmVhdDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IFdUSCghPykgbW9tZW50LjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICog U2VjdGlvbiA2OjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7 IE5BVDQ2L0NMQVQvRE5TLXByb3h5LUVBTSBhcHByb2FjaCAoU2VjdGlvbiA0LjIpIHNlZW1zIHRo ZSByaWdodDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IHNv bHV0aW9uIGZvciBvcHRpbWl6aW5nIHRoZSBhY2Nlc3MgdG8gZHVhbC1zdGFjayBzZXJ2aWNlcywg d2hldGhlcjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IHRo ZXkgYXJlIGxvY2F0ZWQgaW5zaWRlIG9yIG91dHNpZGUgdGhlIElTUC48L2Rpdj4KPGRpdj4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBJ dCB3b3VsZCBzZWVtIHRvIG1lIHRoYXQsIGFjdHVhbGx5LCBBcHByb2FjaCAjMywgd2hlbiB0aGUg SVNQIGhhcyBubzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGNvbnRyb2wgb24g dGhlIENETiwgb3IgYXBwcm9hY2ggIzEgKHdoZW4gaXQgZG9lcyksIGFyZSB0aGUgd2F5IHRvIGdv LjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEFwcHJvYWNoICMyIHNlZW1zIHJh dGhlciBjb21wbGV4LCB3aXRoIHRoZSBjb25zZXF1ZW50IG9wcG9ydHVuaXRpZXMgdG88L2Rpdj4K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBzY3JldyB1cC48L2Rpdj4KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsgQXBwcm9hY2ggIzEgaXMgbm90IGVhc3kgdG8gYmUgaW1wbGVtZW50ZWQgYmVj YXVzZSBjb250ZW50IHByb3ZpZGVycyBkb2Vzbid0IHdhbnQgdG8gYmUgZW52b2x2ZWQgb24gdGhp cyBwcm9jZXNzIGRlc3BpdGUgYWdyZWVpbmcgaXQgY2FuIGJlIGFuIGltcHJvdmVtZW50ICwgc28g dGhlIGRvbid0IHdhbnQgdG8gZG8gYW55IGNoYW5nZSBpbiBjb25maWd1cmF0aW9uIG9mIHRoZWly IGRldmljZXMgLyBpbnRlcmZhY2VzLiBJdCBhcHBsaWVzIG1vcmUgaW4gY2FzZSB3aGVyZSBDRE4g aXMgY29udHJvbGxlZCBieSBJU1AgKG93biBDRE4pLCBidXQgd2Ugd2FudCB0byBkZWZpbmUgYSBn ZW5lcmFsIHNvbHV0aW9uLCB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRoZSBub3JtYWwgY2FzZSBvZiBw dWJsaWMgLyBleHRlcm5hbCBDRE5zLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBBcHBy b2FjaCAjMywgYXMgeW91IHNheSwgaXQgaXMgd2hlbiBJU1AgZG9lc24ndCBoYXZlIGNvbnRyb2wg b2YgdGhlIENETi4gVGhpcyBpcyBjb3VsZCBub3QgYmUgYSB2ZXJ5IHNjYWxhYmxlIHNvbHV0aW9u IGJlY2F1c2UgaXQncyBub3QgZHluYW1pYyBhbmQgYW55IGNoYW5nZSBuZWVkcyB0byBiZSBwcm9w YWdhdGVkIHRvIGFsbCBDUEVzLiBPbiB0aGUgb3RoZXIgaGFuZCBpdCdzIGEgdmVyeSBlYXN5IG1l dGhvZCB0byBtYWtlIGEgZmFzdCBkZXBsb3kgd2hlcmUgdGhlcmUgYXJlIG5vdCBvZnRlbiBjaGFu Z2VzLiBJIHRoaW5rIHRoaXMgaXMgYSB3YXkgd2hlcmUgdGhhdCBhbGxvdyB0byB0aGUgb3BlcmF0 b3IgdG8gZGVwbG95IHRoZSBzb2x1dGlvbiBxdWlja2x5IHdpdGhvdXQgZGVwZW5kaW5nIG9uIGNv bXBsZXggbWVjaGFuaXNtcyBhbmQgd2hlcmUgY29udGVudCBwcm92aWRlciBkb2Vzbid0IGNoYW5n ZSBETlMgcmVjb3JkcywgdGhpcyBpcyB0aGUgY2FzZSBvZiBOZXRmbGl4IENETiB3aGVyZSBBIGFu ZCBBQUFBIHJlY29yZHMgYWx3YXlzIGhhdmUgdGhlIHNhbWUgSVBzIGFzc29jaWF0ZWQgZm9yIHRo ZSBzYW1lIEZRRE4gKGZvciBDRE4pLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBBcHBy b2FjaCAjMiwgeWVzLCBjbGVhcmx5IGl0IGlzIG1vcmUgY29tcGxleCBidXQgaXQgd2lsbCBkZXBl bmRzIG9uIGhvdyBtdWNoIGNvbXBsZXhpdHkgd2Ugd2FudCB0byBnaXZlIHRvIHRoZSBwcm9jZXNz IGFuZCB3ZSBuZWVkIHRvIGRlZmluZSB2ZXJ5IHdlbGwgd2hpY2ggY2FzZXMgd2Ugd2FudCB0byBj b25zaWRlci48L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9kaXY+CjxkaXY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICogU2VjdGlvbiA2OjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5i c3A7Jm5ic3A7IFNJSVQgYWxyZWFkeSBoYXMgYSBTSE9VTEQgZm9yIEVBTSBzdXBwb3J0LiZuYnNw OyBTaG91bGQgNDY0WExBVCBiZSB1cGRhdGVkPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmbmJzcDsmbmJzcDsgYnkgdGhpcyBkb2N1bWVudCBzbyB0aGUgQ0xBVCBoYXMgYSBNVVNU IGZvciBFQU0gc3VwcG9ydD8uPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9k aXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgNDY0eGxhdCBlbXBsb3lzIGV4aXN0aW5n IHRlY2hub2xvZ2llcy4gU28gSSdtIG5vdCBzdXJlIHlvdSBjYW4gZG8gYSBNVVNUPC9kaXY+Cjxk aXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgaW4gNDY0eGxhdCwgd2hlbiBpdCByZWxpZXMgb24g U0lJVCwgYW5kIGZvciBTSUlUIHRoZSByZXF1aXJlbWVudCBpcyBhPC9kaXY+CjxkaXY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgU0hPVUxELjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBZ ZXMsIHdoYXQgeW91IHNheSBpcyB2YWxpZCwgdGhlc2UgYXJlIHF1ZXN0aW9ucyB0byBzZWUgZXhh Y3RseSB3aGF0IHRoZSBjb21tdW5pdHkgdGhpbmtzLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZu YnNwOyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8L2Rpdj4KPGRpdj4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBCZXNpZGVzLCB0aGUgNDY0eGxhdCBzcGVjIGRvZXMgbm90IGV2 ZW4gZW1wbG95IFJGQzIxMTkgbGFuZ3VhZ2UuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg KiBTZWN0aW9uIDc6PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+Cjxk aXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQW55IHNvbHV0aW9uIHdoZXJlIHlvdSBzcG9vZiBE TlMgcmVjb3JkcyB3b3VsZCBwbGF5IGJhZCB3aXRoIEROU3NlYy48L2Rpdj4KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBUaGlzIHNob3VsZCBhdCBsZWFzdCBiZSBkaXNjdXNzZWQuPC9kaXY+ CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgVGhhbmtzITwvZGl2 Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IENoZWVycyw8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBGZXJu YW5kbzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwv ZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IE9uIDExLzEyLzE5IDE0OjI0LCBSb24gQm9uaWNhIHdyb3RlOjwvZGl2Pgo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBGb2xrcyw8L2Rpdj4KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jm5ic3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8L2Rpdj4K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgRWFjaCB3ZWVrIGJldHdlZW4gbm93IGFu ZCBJRVRGIDEwNywgd2Ugd2lsbCByZXZpZXcgYW5kIGRpc2N1c3Mgb25lIGRyYWZ0PC9kaXY+Cjxk aXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IHdpdGggYW4gZXllIHRvd2FyZHMgcHJvZ3Jl c3NpbmcgaXQuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDwvZGl2Pgo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyA8L2Rpdj4KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7IFRoaXMgd2VlaywgcGxlYXNlIHJldmlldyBhbmQgY29tbWVudCBvbjwvZGl2Pgo8ZGl2PiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBkcmFmdC1wYWxldC12Nm9wcy00NjR4bGF0LW9wdC1j ZG4tY2FjaGVzLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8L2Rpdj4K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmbmJzcDsgPC9kaXY+CjxkaXY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyBXaGVuIHJldmlld2luZyB0aGlzIGRyYWZ0LCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5 b3UgdGhpbmsgdGhhdCBWNk9QUzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyBzaG91bGQgYWRvcHQgaXQgYSBzIGEgd29yayBpdGVtLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm bmJzcDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDwvZGl2Pgo8ZGl2 PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBGcmVkIGFuZCBSb248L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7IDwvZGl2 Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHk8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDwvZGl2Pgo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsgdjZvcHNAaWV0Zi5vcmc8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvZGl2Pgo8ZGl2 PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8L2Rpdj4KPGRpdj4m bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAtLTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IEZlcm5hbmRvIEdvbnQ8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBTSTYg TmV0d29ya3M8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBlLW1haWw6IGZnb250 QHNpNm5ldHdvcmtzLmNvbTwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFBHUCBG aW5nZXJwcmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAwRDU1IDFENEUg NzQ5MjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwv ZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdjZvcHMgbWFpbGluZyBsaXN0 PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdjZvcHNAaWV0Zi5vcmc8L2Rpdj4K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvZGl2Pgo8ZGl2 PiZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyB2Nm9wcyBtYWlsaW5nIGxp c3Q8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgdjZvcHNAaWV0Zi5vcmc8L2Rpdj4KPGRp dj4mbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wczwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyA8L2Rpdj4KPGRpdj4mbmJzcDs8 L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4qKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9kaXY+CjxkaXY+SVB2NCBpcyBv dmVyPC9kaXY+CjxkaXY+QXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/PC9kaXY+ CjxkaXY+aHR0cDovL3d3dy50aGVpcHY2Y29tcGFueS5jb208L2Rpdj4KPGRpdj5UaGUgSVB2NiBD b21wYW55PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+VGhpcyBlbGVjdHJvbmljIG1lc3Nh Z2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlk ZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1l eHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9y IHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFs bHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQg d2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5n LCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9u LCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5 b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlz IGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRp dj4mbmJzcDs8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pgo8ZGl2PnY2b3BzIG1haWxpbmcgbGlz dDwvZGl2Pgo8ZGl2PnY2b3BzQGlldGYub3JnPC9kaXY+CjxkaXY+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvZGl2Pgo8L2Rpdj48L2Jsb2NrcXVvdGU+Cjxicj48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPGJyPnY2 b3BzIG1haWxpbmcgbGlzdAo8YnI+djZvcHNAaWV0Zi5vcmcKPGJyPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMKPGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PC9kaXY+PC9kaXY+PC9kaXY+ From nobody Mon Jan 6 23:05:13 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E6120046; Mon, 6 Jan 2020 23:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZFNZOdxuXV4; Mon, 6 Jan 2020 23:05:06 -0800 (PST) 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 EFF3712001B; Mon, 6 Jan 2020 23:05:05 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id x17so22832867pln.1; Mon, 06 Jan 2020 23:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SMuzxDNhvjT4HBFBWUzJkfgZKnCQTHRhqJZ7bharp0s=; b=RByfEJ+aXqTk08ZI+PTqUrtNfL8xoJ80AnaEyeC6gpZZLHF/eXFfNvSIgmAABDEvPR kM+Zh7GhH8DSfaYcl0Vzsjih49qH8ZeEQKUfsog1KAt66/XVvtBpywrF5uSZ7DpzEpNN OxRXW9QKZJX9sbJkyeBTKMkPA8vBS6ZvTqqs+C0J673ltW9pZ0yLnLX60Lkv2NvDV6bK SjgOwKEHUADRgxhal3YO8pQ9r4TvRmI/uM77hmpNR6PAFS5dAwJDBhDlHLYgW9150Fqg IMtNzztmyT/4lAuAydkwJj8WKzl84Hkh4uJi5GsvmsATbdStz1WTKB1258m+RuHr/6xy IwBQ== 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=SMuzxDNhvjT4HBFBWUzJkfgZKnCQTHRhqJZ7bharp0s=; b=s95P4lsW+cqwSclTD/aEVJ3WCIeMZZ/aIQhwjHXN77dIsit/9Bwtps0xdh0ZGEJfYL tb8N76I9B8Sna5u3gr9RJM3EfoEZBeFaiToxPUUwOg9WYE+9arFa6A1UmwASr7BPa/D6 9gSM9O9JGqefHEOPql0LaTEG2NRPIRZIoH+w3h+QDzawb0n4dVwM2XnSpRUzeeh4hNll Cf4qh3qnX2lHzfsAi2cuqTHz8ylnfrml7VrMrPHv3Oetfod3nkZv8cFZLYw9H5/Ny2d1 Mr52sQl9DpuIe4boAmPB0DVTdW+B31hGoR0j4qmIu79X3Apf61Jn+QJ0nj0NI3fOVryF GXoQ== X-Gm-Message-State: APjAAAUXfchauiR2wXhdwvrxPVqlAjIhx+cBS/tGgnpjE0I9RR1tYGgY rzMKjBn0I6/74h3PICaOWnE= X-Google-Smtp-Source: APXvYqwyFQGyp8AjFvta/Wbcam/Txfq7tqMRC77ADGicqdrxTHLNLZMLceUS6pcYlrZs3gw+M3xkdQ== X-Received: by 2002:a17:90a:d78f:: with SMTP id z15mr47547857pju.36.1578380705186; Mon, 06 Jan 2020 23:05:05 -0800 (PST) Received: from ?IPv6:2600:8802:5900:13c4::100c? ([2600:8802:5900:13c4::100c]) by smtp.gmail.com with ESMTPSA id o31sm75640343pgb.56.2020.01.06.23.05.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jan 2020 23:05:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) From: Fred Baker In-Reply-To: Date: Mon, 6 Jan 2020 23:05:02 -0800 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4F5F8586-7DCC-4F1B-82B3-B0D57D7EDFDE@gmail.com> References: <2020010616354842655859@chinatelecom.cn> To: =?utf-8?Q?Lencse_G=C3=A1bor?= , draft-palet-v6ops-464xlat-opt-cdn-caches X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Jan 2020 07:05:11 -0000 > On Jan 6, 2020, at 12:42 AM, Lencse G=C3=A1bor = wrote: >=20 >=20 >=20 > 1/6/2020 9:35 AM keltez=C3=A9ssel, xiechf@chinatelecom.cn =C3=ADrta: >>=20 >> Hi=EF=BC=8CJordi, >> I have the following comments after reading the draft, >> 1\This draft is about IPv6-only for the acccess of IPv4-only client = to dual-stack CDN/Caches. =46rom the perspective of operation, every = possible approach proposed should not pose additionl requirments for the = network configuration.=20 >> 2\ Based on my experience, I think the possibility of XLAT to be used = in wireline network is very small, Is there any large-scale ISP who plan = to use XLAT for wireline broadband? Nearly every IPv6-capable CPE is = dual stack, it is very difficult to convince the CPE industry to support = XLAT in the forseen future. Another factor that we should consider is = that the IPTV service of some ISPs is carried in a seperate layer-two = channle, which does not mix with the default Internet access traffic. =20= >> 3\I don't think the IP address 192.0.2.1 used in the example is = suitable, for the IP address 192.0.0.0/16 has been defined used for = special purpose, maybe the public IP address is better for the interface = of CDN server. >=20 > 192.0.2.0/24 is reserved for documentation purposes, thus, IMHO, it is = ideal for examples. Indeed; The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 = (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3) are provided for use in = documentation (RFC 5737), as is 2001:db8::/32 (RFC 3849).=20 Jordi, I would actually suggest you run this through indits = (https://tools.ietf.org/tools/idnits/) and act on its comments before = reposting the draft.=20 > Address Block Name RFC Allocation Date = Termination Date Source Destination Forwardable Globally = Reachable Reserved-by-Protocol > [...] >=20 > 192.0.2.0/24 Documentation (TEST-NET-1) [RFC5737] 2010-01 = N/A False False False False False >=20 > Source: = https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-spec= ial-registry.xhtml >=20 > Best regards, >=20 > G=C3=A1bor Lencse >=20 >=20 >=20 >> 4\In addition, the title of the draft "464XLAT Optimization" is too = general and ambiguous, I think a more specific one is better. >>=20 >> Best regards >>=20 >> Chongfeng=20 >> =20 >> From: JORDI PALET MARTINEZ >> Date: 2020-01-06 04:56 >> To: v6ops@ietf.org list >> Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call = for Adoption** >> Hi Fernando, >> =20 >> Adding some inputs, below, in-line (->). >> =20 >> =EF=BB=BFEl 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" = escribi=C3=B3: >> =20 >> Hello Fernando, >> =20 >> First at all, thanks for your support to the work and the = document and for taking your time to read all the document. >> =20 >> I will try to answer your comments below. >> =20 >> =20 >> Regards, >> Alejandro >> =20 >> ----- Mensaje original ----- >> > De: "Fernando Gont" >> > Para: "Ron Bonica" , = "v6ops@ietf.org list" >> > Enviados: Viernes, 3 de Enero 2020 20:40:11 >> > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches = **Call for Adoption** >> =20 >> > Folks, >> > >> > I've read the document, and have the following comments: >> > >> > It would seem to me is that this document has resulted from an >> > operators' concern that deployment of 464xlat might result in >> > unnecessary heavyweight use of the stateful PLAT, leading to = scalability >> > problems or unnecessary money spendings. In that sense, I would = like the >> > issue to be documented (even if somehow we don't agree on a = workaround). >> Yes, from one point of view it is correct what you said and in = addition to that we have an unnecessary second translation (NAT64) when = customer traffic was translated to IPv6 (NAT46) and the destination = (content) is available in IPv6 also, so we could avoid both a bottleneck = and a performance impairment. That's why we consider this as an = optimization. >> =20 >> -> I think the document is doing the work of documenting the problem = statement and providing possible solutions, which the idea of choosing = one. We understand that 464XLAT was not designed having this scenario in = mind, but if we can find a good solution, is worth to solve it. = Furthermore, if the WG agree that this is the way to go, we could update = with this document 464XLAT (which is an informational one) and make it = to the standards track. As I've already expressed several times, it is = pity that being the transition mechanism that is more used in the world = (versus all the others, in terms of number of devices), it is not a = standard. >> =20 >> =20 >> > >> > So I support the adoption of this document (or some version of = it) -- >> > i.e., there's value in documenting the issue itself. >> > >> > That said, I think that further work is required on the = document. PLease >> > find my review below: >> > >> > >> > **** Some meta comments **** >> > >> > * Meta: I'd put more stress on why this "optimization" is = important. You >> > delve into many other (rather unnecessary) details, but don't = elaborate >> > much regarding why this "optimization" is important. >> =20 >> -> My reading is that the optimization and the need for it is well = described, but definitively will take a look into it and improve it if = needed. >> =20 >> Yes, it is true, maybe the introduction could be simpler and more = oriented to show the concrete problem and why we believe this is = important. >> =20 >> I don't know if the info is wrong, maybe a specific initial = summary that indicates it is missing. We can consider it. >> =20 >> =20 >> > >> > * Meta: It'd be important to note that, according to the = Abstract of >> > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. = In that >> > sense, the behavior you describe is kind of "expected", and = what you >> > describe would seem to me more of a mechanism to *opt out of = 464xlat* >> > than an optimization to 464XLAT itself. >> =20 >> -> Yes, I said that in my first comment. With this optimization, if = we are able to find consensus in a good solution, we improve something = that was not initially expected to be done by 464XLAT. I don't see the = "opt-out" point that you mention. >> =20 >> Yes, 464XLAT asumes both IPv4 services and IPv4-only devices = also. >> Yes, this is the expected behavior of 464XLAT (and MAP-T also) = but from a practical and performance point of view, maybe, it is not the = most optimal path for the end-to-end traffic flow. As you said if we = avoid the NAT64, technically speaking, the traffic will not be going = through a 464XLAT/MAP-T scenario. >> We are not saying that 464XLAT is wrong at all, we are trying to = expose a real problem for IPv6 only network deployments and trying to = present some approaches to solve it (or minimize it). >> =20 >> > >> > * It would seem to me that the cases where this issue is more = of a >> > concern is essentially smartboxes (smart TVs) consuming media = from large >> > CDNs. If so, this should be spelled out, since this essentially = sets the >> > context for what options/approaches can be considered = acceptable. >> Ok, yes, we can put more effort to explain that. >> =20 >> > >> > >> > >> > *** Some specific comments: **** >> > >> > * Abstract: I'm curious if the term "NAT46" can be confusing, = for >> > multiple reasons (for instance, it's not specified in RFC7915). = Just use >> > "SIIT", and the context (i.e., describe what's on each side of = the SIIT >> > device, and what's the intent). >> =20 >> -> Initially we were using the term CLAT, but then we realized that = MAP-T has the same issue, and there it is not called CLAT, but NAT46. = This is the reason, quite simple, because the optimization will also = work for MAP-T. >> =20 >> We can review it if it is confusing. >> The idea on this point was to talk about the NAT46 of CPE (CLAT). >> Yes, RFC7915 talks about SIIT independently if it is NAT46 or = not. >> Regarding "(IP/ICMP Translation Algorithm) as described by = [RFC7915]" it refers just to SIIT. >> As we know, CLAT is a combination of NAT46 + SIIT because it's an = stateless translation from IPv4 to IPv6. >> =20 >> > >> > >> > * Introduction: >> > It seems to me the intro contains too many unnecessary details. = e.g., >> > just talk about the CLAT as an abstract concept. Where/how >> > (specifically) it is implemented is mostly irrelevant in the = context of >> > this document. >> Yes, I don't know, it could be, as I put above maybe in the = introduction we talk about many specific things and we could talk more = about the problem itself. >> =20 >> > >> > >> > * Section 4: >> > Is the option where packets might get to the Cache with = *private space* >> > worth mentioning/describing/discussing? >> =20 >> -> When we talked with CDN/cache providers, they don't like to use = non-GUA (example the NAT64 WKP), so it is discussed as an option in = approach 1. >> =20 >> I'm sorry I didn't understand it very well. >> What *private space* are you talking about? IPv4 or IPv6? >> If you are talking about IPv6, CDNs normally have IPv6 GUA. >> If you are talking about customers with private IPv4 reaching = public IPv4 destination CDNs, yes we could explain it because it is the = main scenario we actually some content providers offers to ISPs to = deliver content from public IPv4 of CDN to customers with private IPv4 = avoiding a CGN platform. That was the first reason to create this = document. >> =20 >> > >> > >> > * Section 4.3: >> > One more advantage of this solution is that the EAMT pairs = doesn't >> > need to match the "real" IPv4/IPv6 addresses available in the = A/AAAA >> > records, as shown in the next example. >> > >> > Please elaborate. >> =20 >> -> I think it is clear if you look at the example. >> =20 >> > >> > >> > * Section 5: >> > If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, = it can >> > be complemented to resolve this issue, by means of making = sure that >> > IPv6-only destinations have one A resource record (even an = invalid >> > one), despite they aren't actually connected to IPv4. >> > >> > Not sure what you mean. >> =20 >> -> I think it is clear if you read the paragraph before that one. = Otherwise we could expand the text to make it more obvious. >> =20 >> It's an idea, we offer different ideas (approaches) to try = optimize the traffic flow. >> Here, the idea is that if the destination is IPv6-only, when we = have an IPv4-only device, in a normal case you could never reach the = destination but if you have this optimization your Proxy DNS could = detect that it doesn't have an A record but it has an AAAA record, so = you could be connected to the IPv6 destination. Without this, your = IPv4-only device would not be able to get the IPv6-only content. >> =20 >> > >> > >> > * Section 5: >> > In fact, it may become an incentive for the IPv6 deployment = in >> > Internet services and provides the option to use an IPv4 = address >> > (maybe anycast) for the "non-valid" A resource record, that = points to >> > a "universal" web page (maybe hosted by IETF?) that displays = a >> > warning such as "Sorry, you don't IPv6 support in your = operator, so >> > this service is not available for you". >> > >> > Please *no*, for so many different reasons. -- including "the = average >> > user doesn't care about IPv6, and may not even be aware of what = it is". >> =20 >> -> It can be a different text not necessarily mention IPv6 but just = "your Internet connection is not able to access this content, please ask = your ISP to upgrade it". Anyway, it is very contentious topic ... This = probably will get removed in a new version, or moved to an annex, etc. >> =20 >> Ok, it could be, but remember it is another proposal like the = other approaches and the idea is to get these kind of inputs. >> =20 >> > >> > >> > >> > * Section 6: >> > Should we recommend having A records for IPv6-only services = in >> > Internet? The A record may point to a "reserved" or = "special" IPv4 >> > address. A web page IPv4-only hosted by IETF(?) showing = "sorry this >> > web page/service is only available from IPv6 enabled = operators"?. >> > >> > Please no. This assumes (?) hosts prefer IPv6, but they don't = need to. >> > In which case they would get to such page and have a not so = great >> > WTH(!?) moment. >> > >> > >> > >> > * Section 6: >> > NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the = right >> > solution for optimizing the access to dual-stack services, = whether >> > they are located inside or outside the ISP. >> > >> > It would seem to me that, actually, Approach #3, when the ISP = has no >> > control on the CDN, or approach #1 (when it does), are the way = to go. >> > Approach #2 seems rather complex, with the consequent = opportunities to >> > screw up. >> Approach #1 is not easy to be implemented because content = providers doesn't want to be envolved on this process despite agreeing = it can be an improvement , so the don't want to do any change in = configuration of their devices / interfaces. It applies more in case = where CDN is controlled by ISP (own CDN), but we want to define a = general solution, we need to consider the normal case of public / = external CDNs. >> Approach #3, as you say, it is when ISP doesn't have control of = the CDN. This is could not be a very scalable solution because it's not = dynamic and any change needs to be propagated to all CPEs. On the other = hand it's a very easy method to make a fast deploy where there are not = often changes. I think this is a way where that allow to the operator to = deploy the solution quickly without depending on complex mechanisms and = where content provider doesn't change DNS records, this is the case of = Netflix CDN where A and AAAA records always have the same IPs associated = for the same FQDN (for CDN). >> Approach #2, yes, clearly it is more complex but it will depends = on how much complexity we want to give to the process and we need to = define very well which cases we want to consider. >> =20 >> =20 >> > >> > >> > * Section 6: >> > SIIT already has a SHOULD for EAM support. Should 464XLAT be = updated >> > by this document so the CLAT has a MUST for EAM support?. >> > >> > 464xlat employs existing technologies. So I'm not sure you can = do a MUST >> > in 464xlat, when it relies on SIIT, and for SIIT the = requirement is a >> > SHOULD. >> Yes, what you say is valid, these are questions to see exactly = what the community thinks. >> =20 >> > >> > Besides, the 464xlat spec does not even employ RFC2119 = language. >> > >> > >> > >> > * Section 7: >> > >> > Any solution where you spoof DNS records would play bad with = DNSsec. >> > This should at least be discussed. >> > >> > >> > Thanks! >> > >> > Cheers, >> > Fernando >> > >> > >> > >> > >> > On 11/12/19 14:24, Ron Bonica wrote: >> >> Folks, >> >> >> >>=20 >> >> >> >> Each week between now and IETF 107, we will review and discuss = one draft >> >> with an eye towards progressing it. >> >> >> >>=20 >> >> >> >> This week, please review and comment on >> >> draft-palet-v6ops-464xlat-opt-cdn-caches. >> >> >> >>=20 >> >> >> >> When reviewing this draft, please indicate whether you think = that V6OPS >> >> should adopt it a s a work item. >> >> >> >>=20 >> >> >> >> Fred and = Ron >> >> >> >>=20 >> >> >> >> >> >> Juniper Business Use Only >> >> >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > >> > >> > -- >> > Fernando Gont >> > SI6 Networks >> > e-mail: fgont@si6networks.com >> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E = 7492 >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >>=20 >> 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 Tue Jan 7 06:10:05 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B87120123 for ; Tue, 7 Jan 2020 06:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 074ypurHrJNs for ; Tue, 7 Jan 2020 06:09:59 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id E70EB1200E9 for ; Tue, 7 Jan 2020 06:09:57 -0800 (PST) HMM_SOURCE_IP: 172.18.0.92:23570.1342615900 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-123.119.34.253?logid-14BF4348AD734311B7E1AAC3AC40544D (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 9F29428008E; Tue, 7 Jan 2020 22:09:51 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id 14BF4348AD734311B7E1AAC3AC40544D for fhfrediani@gmail.com; Tue Jan 7 22:09:54 2020 X-Transaction-ID: 14BF4348AD734311B7E1AAC3AC40544D X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Date: Tue, 7 Jan 2020 22:09:48 +0800 From: "xiechf@chinatelecom.cn" To: "Fernando Frediani" , v6ops References: , <2020010616354842655859@chinatelecom.cn>, <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.14.409[cn] Mime-Version: 1.0 Message-ID: <2020010722094585159928@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart743384616626_=----" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Jan 2020 14:10:03 -0000 This is a multi-part message in MIME format. ------=_001_NextPart743384616626_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQpIae+8jEZlcm5hbmRvLA0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiAgWW91IG1lbnRp b25lZCB0aGF0IDQ2NFhMQVQgaXMgYWJsZSB0byBzYXZlIG1vcmUgSVB2NCBhZGRyZXNzZXMsIEkg dGhpbmsgdGhpcyBpcyBiYXNlZCBvbiB0aGUgY29tcGFyaXNvbiB3aXRoIGR1YWwtc3RhY2sgYXBw cm9hY2gsIHN1Y2ggYXMgTkFUNDQuIEhhdmUgeW91IGV2ZXIgZG9uZSBzb21lIHF1YW50aXRhdGl2 ZSBhbmFseXNpcyBvZiAgaG93IG11Y2ggcGVyY2VudGFnZSBvZiBJUHY0IGFkZGVzc2VzIGNhbiBi ZSBzYXZlZCB3aXRoIDQ2NFhMQVTvvJ8gVGhhbmsgeW9177yBDQpCZXN0IHJlZ2FyZHMNCkNob25n ZmVuZw0KDQogDQpGcm9tOiBGZXJuYW5kbyBGcmVkaWFuaQ0KRGF0ZTogMjAyMC0wMS0wNyAwMDow MA0KVG86IHY2b3BzDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1wYWxldC12Nm9wcy00NjR4 bGF0LW9wdC1jZG4tY2FjaGVzICoqQ2FsbCBmb3IgQWRvcHRpb24qKg0KT24gMDYvMDEvMjAyMCAw NTozNSwgeGllY2hmQGNoaW5hdGVsZWNvbS5jbiB3cm90ZToNCg0KMlwgQmFzZWQgb24gbXkgZXhw ZXJpZW5jZSwgSSB0aGluayB0aGUgcG9zc2liaWxpdHkgb2YgWExBVCB0byBiZSB1c2VkIGluIHdp cmVsaW5lIG5ldHdvcmsgaXMgdmVyeSBzbWFsbCwgSXMgdGhlcmUgYW55IGxhcmdlLXNjYWxlIElT UCB3aG8gcGxhbiB0byB1c2UgWExBVCBmb3Igd2lyZWxpbmUgYnJvYWRiYW5kPyBOZWFybHkgZXZl cnkgSVB2Ni1jYXBhYmxlIENQRSBpcyBkdWFsIHN0YWNrLCBpdCBpcyB2ZXJ5IGRpZmZpY3VsdCB0 byBjb252aW5jZSB0aGUgQ1BFIGluZHVzdHJ5IHRvIHN1cHBvcnQgWExBVCBpbiB0aGUgZm9yc2Vl biBmdXR1cmUuIEFub3RoZXIgZmFjdG9yIHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyIGlzIHRoYXQg dGhlIElQVFYgc2VydmljZSBvZiBzb21lIElTUHMgaXMgY2FycmllZCBpbiBhIHNlcGVyYXRlIGxh eWVyLXR3byBjaGFubmxlLCB3aGljaCBkb2VzIG5vdCBtaXggd2l0aCB0aGUgZGVmYXVsdCBJbnRl cm5ldCBhY2Nlc3MgdHJhZmZpYy4gIA0KQWx0aG91Z2ggdGhlIGJpZ2dlc3QgY2hhbGxlbmdlIGZv ciA0NjRYTEFUIGFkb3B0aW9uIGluIGZpeGVkIGJyb2FkYmFuZCBJU1BzIGlzIHRoZSBsYWNrIG9m IENMQVQgY2xpZW50IG9uIG1vc3QgQ1BFcyBJIGRvbid0IHRoaW5rIHRoYXQgd291bGQgYmUgYSBt YWpvciBpc3N1ZSB0byBjb252aW5jZSBDUEUgaW5kdXN0cnkgdG8gaGF2ZSBpdCBiZWNhdXNlIHRl Y2huaWNhbGx5IHNwZWFraW5nIGlzIGEgbWlub3IgY29tcG9uZW50IG9mIHRoZSBmaXJtd2FyZSBh bmQgcXVpZXQgZWFzeSB0byBhZGQgZGUgZGFlbW9uLiBTdXJlIGl0IHRha2VzIHNvbWUgdGltZSB0 byBoYXBwZW4sIGJ1dCBpdCdzIG5vdCBhIG1ham9yIHRoaW5nIHJlYWxseS4NCldpdGggdGhpcyBo YXBwZW5pbmcgSSBiZXQgaW4gdGhlIGZ1dHVyZSB0aGVyZSBpcyBhIHBvdGVudGlhbCBvZiBJU1Bz IHJlcGxhY2luZyBDR05BVCArIElQdjYgc2NlbmFyaW9zIGZvciA0NjRYTEFUIGZvciBpdHMgYWR2 YW50YWdlcyBzcGVjaWFsbHkgaW4gYmVpbmcgYWJsZSB0byBzYXZlIG1vcmUgUHVibGljIElQdjQg YWRkcmVzc2VzLg0KV2l0aCByZWdhcmRzIHRoZSBJUFRWIHNlcnZpY2Ugb2Ygc29tZSBJU1BzIGl0 IG9jY3VycyBpbnNpZGUgdGhlIElTUCBiYWNrYm9uZSBhbmQgaW4gbW9zdCBjYXNlcyB3b3VsZG4n dCByZXF1aXJlIGFueSBraW5kIG9mIHRyYW5zbGF0aW9uIG9uIHRoZSBJU1Agc2lkZS4NClJlZ2Fy ZHMNCkZlcm5hbmRvIEZyZWRpYW5pDQoNCg0KIA0KRnJvbTogSk9SREkgUEFMRVQgTUFSVElORVoN CkRhdGU6IDIwMjAtMDEtMDYgMDQ6NTYNClRvOiB2Nm9wc0BpZXRmLm9yZyBsaXN0DQpTdWJqZWN0 OiBSZTogW3Y2b3BzXSBkcmFmdC1wYWxldC12Nm9wcy00NjR4bGF0LW9wdC1jZG4tY2FjaGVzICoq Q2FsbCBmb3IgQWRvcHRpb24qKg0KSGkgRmVybmFuZG8sDQogDQpBZGRpbmcgc29tZSBpbnB1dHMs IGJlbG93LCBpbi1saW5lICgtPikuDQogDQrvu79FbCA0LzEvMjAgNDozNCwgInY2b3BzIGVuIG5v bWJyZSBkZSBBbGVqYW5kcm8gRCdFZ2lkaW8iIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIGVuIG5v bWJyZSBkZSBhZGVnaWRpbz00MHRlbGVjZW50cm8ubmV0LmFyQGRtYXJjLmlldGYub3JnPiBlc2Ny aWJpw7M6DQogDQogICAgSGVsbG8gRmVybmFuZG8sDQogICAgDQogICAgRmlyc3QgYXQgYWxsLCB0 aGFua3MgZm9yIHlvdXIgc3VwcG9ydCB0byB0aGUgd29yayBhbmQgdGhlIGRvY3VtZW50IGFuZCBm b3IgdGFraW5nIHlvdXIgdGltZSB0byByZWFkIGFsbCB0aGUgZG9jdW1lbnQuDQogICAgDQogICAg SSB3aWxsIHRyeSB0byBhbnN3ZXIgeW91ciBjb21tZW50cyBiZWxvdy4NCiAgICANCiAgICANCiAg ICBSZWdhcmRzLA0KICAgIEFsZWphbmRybw0KICAgIA0KICAgIC0tLS0tIE1lbnNhamUgb3JpZ2lu YWwgLS0tLS0NCiAgICA+IERlOiAiRmVybmFuZG8gR29udCIgPGZnb250QHNpNm5ldHdvcmtzLmNv bT4NCiAgICA+IFBhcmE6ICJSb24gQm9uaWNhIiA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJj LmlldGYub3JnPiwgInY2b3BzQGlldGYub3JnIGxpc3QiIDx2Nm9wc0BpZXRmLm9yZz4NCiAgICA+ IEVudmlhZG9zOiBWaWVybmVzLCAzIGRlIEVuZXJvIDIwMjAgMjA6NDA6MTENCiAgICA+IEFzdW50 bzogUmU6IFt2Nm9wc10gZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxhdC1vcHQtY2RuLWNhY2hlcyAq KkNhbGwgZm9yIEFkb3B0aW9uKioNCiAgICANCiAgICA+IEZvbGtzLA0KICAgID4gDQogICAgPiBJ J3ZlIHJlYWQgdGhlIGRvY3VtZW50LCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0K ICAgID4gDQogICAgPiBJdCB3b3VsZCBzZWVtIHRvIG1lIGlzIHRoYXQgdGhpcyBkb2N1bWVudCBo YXMgcmVzdWx0ZWQgZnJvbSBhbg0KICAgID4gb3BlcmF0b3JzJyBjb25jZXJuIHRoYXQgZGVwbG95 bWVudCBvZiA0NjR4bGF0IG1pZ2h0IHJlc3VsdCBpbg0KICAgID4gdW5uZWNlc3NhcnkgaGVhdnl3 ZWlnaHQgdXNlIG9mIHRoZSBzdGF0ZWZ1bCBQTEFULCBsZWFkaW5nIHRvIHNjYWxhYmlsaXR5DQog ICAgPiBwcm9ibGVtcyBvciB1bm5lY2Vzc2FyeSBtb25leSBzcGVuZGluZ3MuIEluIHRoYXQgc2Vu c2UsIEkgd291bGQgbGlrZSB0aGUNCiAgICA+IGlzc3VlIHRvIGJlIGRvY3VtZW50ZWQgKGV2ZW4g aWYgc29tZWhvdyB3ZSBkb24ndCBhZ3JlZSBvbiBhIHdvcmthcm91bmQpLg0KICAgIFllcywgZnJv bSBvbmUgcG9pbnQgb2YgdmlldyBpdCBpcyBjb3JyZWN0IHdoYXQgeW91IHNhaWQgYW5kIGluIGFk ZGl0aW9uIHRvIHRoYXQgd2UgaGF2ZSBhbiB1bm5lY2Vzc2FyeSBzZWNvbmQgdHJhbnNsYXRpb24g KE5BVDY0KSB3aGVuIGN1c3RvbWVyIHRyYWZmaWMgd2FzIHRyYW5zbGF0ZWQgdG8gSVB2NiAoTkFU NDYpIGFuZCB0aGUgZGVzdGluYXRpb24gKGNvbnRlbnQpIGlzIGF2YWlsYWJsZSBpbiBJUHY2IGFs c28sIHNvIHdlIGNvdWxkIGF2b2lkIGJvdGggYSBib3R0bGVuZWNrIGFuZCBhIHBlcmZvcm1hbmNl IGltcGFpcm1lbnQuIFRoYXQncyB3aHkgd2UgY29uc2lkZXIgdGhpcyBhcyBhbiBvcHRpbWl6YXRp b24uDQogDQotPiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBkb2luZyB0aGUgd29yayBvZiBkb2N1 bWVudGluZyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHByb3ZpZGluZyBwb3NzaWJsZSBzb2x1 dGlvbnMsIHdoaWNoIHRoZSBpZGVhIG9mIGNob29zaW5nIG9uZS4gV2UgdW5kZXJzdGFuZCB0aGF0 IDQ2NFhMQVQgd2FzIG5vdCBkZXNpZ25lZCBoYXZpbmcgdGhpcyBzY2VuYXJpbyBpbiBtaW5kLCBi dXQgaWYgd2UgY2FuIGZpbmQgYSBnb29kIHNvbHV0aW9uLCBpcyB3b3J0aCB0byBzb2x2ZSBpdC4g RnVydGhlcm1vcmUsIGlmIHRoZSBXRyBhZ3JlZSB0aGF0IHRoaXMgaXMgdGhlIHdheSB0byBnbywg d2UgY291bGQgdXBkYXRlIHdpdGggdGhpcyBkb2N1bWVudCA0NjRYTEFUICh3aGljaCBpcyBhbiBp bmZvcm1hdGlvbmFsIG9uZSkgYW5kIG1ha2UgaXQgdG8gdGhlIHN0YW5kYXJkcyB0cmFjay4gQXMg SSd2ZSBhbHJlYWR5IGV4cHJlc3NlZCBzZXZlcmFsIHRpbWVzLCBpdCBpcyBwaXR5IHRoYXQgYmVp bmcgdGhlIHRyYW5zaXRpb24gbWVjaGFuaXNtIHRoYXQgaXMgbW9yZSB1c2VkIGluIHRoZSB3b3Js ZCAodmVyc3VzIGFsbCB0aGUgb3RoZXJzLCBpbiB0ZXJtcyBvZiBudW1iZXIgb2YgZGV2aWNlcyks IGl0IGlzIG5vdCBhIHN0YW5kYXJkLg0KICAgIA0KICAgIA0KICAgID4gDQogICAgPiBTbyBJIHN1 cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKG9yIHNvbWUgdmVyc2lvbiBvZiBp dCkgLS0NCiAgICA+IGkuZS4sIHRoZXJlJ3MgdmFsdWUgaW4gZG9jdW1lbnRpbmcgdGhlIGlzc3Vl IGl0c2VsZi4NCiAgICA+IA0KICAgID4gVGhhdCBzYWlkLCBJIHRoaW5rIHRoYXQgZnVydGhlciB3 b3JrIGlzIHJlcXVpcmVkIG9uIHRoZSBkb2N1bWVudC4gUExlYXNlDQogICAgPiBmaW5kIG15IHJl dmlldyBiZWxvdzoNCiAgICA+IA0KICAgID4gDQogICAgPiAqKioqIFNvbWUgbWV0YSBjb21tZW50 cyAqKioqDQogICAgPiANCiAgICA+ICogTWV0YTogSSdkIHB1dCBtb3JlIHN0cmVzcyBvbiB3aHkg dGhpcyAib3B0aW1pemF0aW9uIiBpcyBpbXBvcnRhbnQuIFlvdQ0KICAgID4gZGVsdmUgaW50byBt YW55IG90aGVyIChyYXRoZXIgdW5uZWNlc3NhcnkpIGRldGFpbHMsIGJ1dCBkb24ndCBlbGFib3Jh dGUNCiAgICA+IG11Y2ggcmVnYXJkaW5nIHdoeSB0aGlzICJvcHRpbWl6YXRpb24iIGlzIGltcG9y dGFudC4NCiANCi0+IE15IHJlYWRpbmcgaXMgdGhhdCB0aGUgb3B0aW1pemF0aW9uIGFuZCB0aGUg bmVlZCBmb3IgaXQgaXMgd2VsbCBkZXNjcmliZWQsIGJ1dCBkZWZpbml0aXZlbHkgd2lsbCB0YWtl IGEgbG9vayBpbnRvIGl0IGFuZCBpbXByb3ZlIGl0IGlmIG5lZWRlZC4NCiANCiAgICBZZXMsIGl0 IGlzIHRydWUsIG1heWJlIHRoZSBpbnRyb2R1Y3Rpb24gY291bGQgYmUgc2ltcGxlciBhbmQgbW9y ZSBvcmllbnRlZCB0byBzaG93IHRoZSBjb25jcmV0ZSBwcm9ibGVtIGFuZCB3aHkgd2UgYmVsaWV2 ZSB0aGlzIGlzIGltcG9ydGFudC4NCiAgICANCiAgICBJIGRvbid0IGtub3cgaWYgdGhlIGluZm8g aXMgd3JvbmcsIG1heWJlIGEgc3BlY2lmaWMgaW5pdGlhbCBzdW1tYXJ5IHRoYXQgaW5kaWNhdGVz IGl0IGlzIG1pc3NpbmcuIFdlIGNhbiBjb25zaWRlciBpdC4NCiAgICANCiAgICANCiAgICA+IA0K ICAgID4gKiBNZXRhOiBJdCdkIGJlIGltcG9ydGFudCB0byBub3RlIHRoYXQsIGFjY29yZGluZyB0 byB0aGUgQWJzdHJhY3Qgb2YNCiAgICA+IFJGQzY4NzcsIDQ2NFhMQVQgYXNzdW1lcyBJUHY0IHNl cnZpY2VzIG92ZXIgYW4gSVB2Ni1vbmx5IG5vZGUuIEluIHRoYXQNCiAgICA+IHNlbnNlLCB0aGUg YmVoYXZpb3IgeW91IGRlc2NyaWJlIGlzIGtpbmQgb2YgImV4cGVjdGVkIiwgYW5kIHdoYXQgeW91 DQogICAgPiBkZXNjcmliZSB3b3VsZCBzZWVtIHRvIG1lIG1vcmUgb2YgYSBtZWNoYW5pc20gdG8g Km9wdCBvdXQgb2YgNDY0eGxhdCoNCiAgICA+IHRoYW4gYW4gb3B0aW1pemF0aW9uIHRvIDQ2NFhM QVQgaXRzZWxmLg0KIA0KLT4gWWVzLCBJIHNhaWQgdGhhdCBpbiBteSBmaXJzdCBjb21tZW50LiBX aXRoIHRoaXMgb3B0aW1pemF0aW9uLCBpZiB3ZSBhcmUgYWJsZSB0byBmaW5kIGNvbnNlbnN1cyBp biBhIGdvb2Qgc29sdXRpb24sIHdlIGltcHJvdmUgc29tZXRoaW5nIHRoYXQgd2FzIG5vdCBpbml0 aWFsbHkgZXhwZWN0ZWQgdG8gYmUgZG9uZSBieSA0NjRYTEFULiBJIGRvbid0IHNlZSB0aGUgIm9w dC1vdXQiIHBvaW50IHRoYXQgeW91IG1lbnRpb24uDQogDQogICAgWWVzLCA0NjRYTEFUIGFzdW1l cyBib3RoIElQdjQgc2VydmljZXMgYW5kIElQdjQtb25seSBkZXZpY2VzIGFsc28uDQogICAgWWVz LCB0aGlzIGlzIHRoZSBleHBlY3RlZCBiZWhhdmlvciBvZiA0NjRYTEFUIChhbmQgTUFQLVQgYWxz bykgYnV0IGZyb20gYSBwcmFjdGljYWwgYW5kIHBlcmZvcm1hbmNlIHBvaW50IG9mIHZpZXcsIG1h eWJlLCBpdCBpcyBub3QgdGhlIG1vc3Qgb3B0aW1hbCBwYXRoIGZvciB0aGUgZW5kLXRvLWVuZCB0 cmFmZmljIGZsb3cuIEFzIHlvdSBzYWlkIGlmIHdlIGF2b2lkIHRoZSBOQVQ2NCwgdGVjaG5pY2Fs bHkgc3BlYWtpbmcsIHRoZSB0cmFmZmljIHdpbGwgbm90IGJlIGdvaW5nIHRocm91Z2ggYSA0NjRY TEFUL01BUC1UIHNjZW5hcmlvLg0KICAgIFdlIGFyZSBub3Qgc2F5aW5nIHRoYXQgNDY0WExBVCBp cyB3cm9uZyBhdCBhbGwsIHdlIGFyZSB0cnlpbmcgdG8gZXhwb3NlIGEgcmVhbCBwcm9ibGVtIGZv ciBJUHY2IG9ubHkgbmV0d29yayBkZXBsb3ltZW50cyBhbmQgdHJ5aW5nIHRvIHByZXNlbnQgc29t ZSBhcHByb2FjaGVzIHRvIHNvbHZlIGl0IChvciBtaW5pbWl6ZSBpdCkuDQogICAgDQogICAgPiAN CiAgICA+ICogSXQgd291bGQgc2VlbSB0byBtZSB0aGF0IHRoZSBjYXNlcyB3aGVyZSB0aGlzIGlz c3VlIGlzIG1vcmUgb2YgYQ0KICAgID4gY29uY2VybiBpcyBlc3NlbnRpYWxseSBzbWFydGJveGVz IChzbWFydCBUVnMpIGNvbnN1bWluZyBtZWRpYSBmcm9tIGxhcmdlDQogICAgPiBDRE5zLiBJZiBz bywgdGhpcyBzaG91bGQgYmUgc3BlbGxlZCBvdXQsIHNpbmNlIHRoaXMgZXNzZW50aWFsbHkgc2V0 cyB0aGUNCiAgICA+IGNvbnRleHQgZm9yIHdoYXQgb3B0aW9ucy9hcHByb2FjaGVzIGNhbiBiZSBj b25zaWRlcmVkIGFjY2VwdGFibGUuDQogICAgT2ssIHllcywgd2UgY2FuIHB1dCBtb3JlIGVmZm9y dCB0byBleHBsYWluIHRoYXQuDQogICAgIA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4g KioqIFNvbWUgc3BlY2lmaWMgY29tbWVudHM6ICoqKioNCiAgICA+IA0KICAgID4gKiBBYnN0cmFj dDogSSdtIGN1cmlvdXMgaWYgdGhlIHRlcm0gIk5BVDQ2IiBjYW4gYmUgY29uZnVzaW5nLCBmb3IN CiAgICA+IG11bHRpcGxlIHJlYXNvbnMgKGZvciBpbnN0YW5jZSwgaXQncyBub3Qgc3BlY2lmaWVk IGluIFJGQzc5MTUpLiBKdXN0IHVzZQ0KICAgID4gIlNJSVQiLCBhbmQgdGhlIGNvbnRleHQgKGku ZS4sIGRlc2NyaWJlIHdoYXQncyBvbiBlYWNoIHNpZGUgb2YgdGhlIFNJSVQNCiAgICA+IGRldmlj ZSwgYW5kIHdoYXQncyB0aGUgaW50ZW50KS4NCiANCi0+IEluaXRpYWxseSB3ZSB3ZXJlIHVzaW5n IHRoZSB0ZXJtIENMQVQsIGJ1dCB0aGVuIHdlIHJlYWxpemVkIHRoYXQgTUFQLVQgaGFzIHRoZSBz YW1lIGlzc3VlLCBhbmQgdGhlcmUgaXQgaXMgbm90IGNhbGxlZCBDTEFULCBidXQgTkFUNDYuIFRo aXMgaXMgdGhlIHJlYXNvbiwgcXVpdGUgc2ltcGxlLCBiZWNhdXNlIHRoZSBvcHRpbWl6YXRpb24g d2lsbCBhbHNvIHdvcmsgZm9yIE1BUC1ULg0KIA0KICAgIFdlIGNhbiByZXZpZXcgaXQgaWYgaXQg aXMgY29uZnVzaW5nLg0KICAgIFRoZSBpZGVhIG9uIHRoaXMgcG9pbnQgd2FzIHRvIHRhbGsgYWJv dXQgdGhlIE5BVDQ2IG9mIENQRSAoQ0xBVCkuDQogICAgWWVzLCBSRkM3OTE1IHRhbGtzIGFib3V0 IFNJSVQgaW5kZXBlbmRlbnRseSBpZiBpdCBpcyBOQVQ0NiBvciBub3QuDQogICAgUmVnYXJkaW5n ICIoSVAvSUNNUCBUcmFuc2xhdGlvbiBBbGdvcml0aG0pIGFzIGRlc2NyaWJlZCBieSBbUkZDNzkx NV0iIGl0IHJlZmVycyBqdXN0IHRvIFNJSVQuDQogICAgQXMgd2Uga25vdywgQ0xBVCBpcyBhIGNv bWJpbmF0aW9uIG9mIE5BVDQ2ICsgU0lJVCBiZWNhdXNlIGl0J3MgYW4gc3RhdGVsZXNzIHRyYW5z bGF0aW9uIGZyb20gSVB2NCB0byBJUHY2Lg0KICAgICANCiAgICA+IA0KICAgID4gDQogICAgPiAq IEludHJvZHVjdGlvbjoNCiAgICA+IEl0IHNlZW1zIHRvIG1lIHRoZSBpbnRybyBjb250YWlucyB0 b28gbWFueSB1bm5lY2Vzc2FyeSBkZXRhaWxzLiBlLmcuLA0KICAgID4ganVzdCB0YWxrIGFib3V0 IHRoZSBDTEFUIGFzIGFuIGFic3RyYWN0IGNvbmNlcHQuIFdoZXJlL2hvdw0KICAgID4gKHNwZWNp ZmljYWxseSkgaXQgaXMgaW1wbGVtZW50ZWQgaXMgbW9zdGx5IGlycmVsZXZhbnQgaW4gdGhlIGNv bnRleHQgb2YNCiAgICA+IHRoaXMgZG9jdW1lbnQuDQogICAgWWVzLCBJIGRvbid0IGtub3csIGl0 IGNvdWxkIGJlLCBhcyBJIHB1dCBhYm92ZSBtYXliZSBpbiB0aGUgaW50cm9kdWN0aW9uIHdlIHRh bGsgYWJvdXQgbWFueSBzcGVjaWZpYyB0aGluZ3MgYW5kIHdlIGNvdWxkIHRhbGsgbW9yZSBhYm91 dCB0aGUgcHJvYmxlbSBpdHNlbGYuDQogICAgDQogICAgPiANCiAgICA+IA0KICAgID4gKiBTZWN0 aW9uIDQ6DQogICAgPiBJcyB0aGUgb3B0aW9uIHdoZXJlIHBhY2tldHMgbWlnaHQgZ2V0IHRvIHRo ZSBDYWNoZSB3aXRoICpwcml2YXRlIHNwYWNlKg0KICAgID4gd29ydGggbWVudGlvbmluZy9kZXNj cmliaW5nL2Rpc2N1c3Npbmc/DQogDQotPiBXaGVuIHdlIHRhbGtlZCB3aXRoIENETi9jYWNoZSBw cm92aWRlcnMsIHRoZXkgZG9uJ3QgbGlrZSB0byB1c2Ugbm9uLUdVQSAoZXhhbXBsZSB0aGUgTkFU NjQgV0tQKSwgc28gaXQgaXMgZGlzY3Vzc2VkIGFzIGFuIG9wdGlvbiBpbiBhcHByb2FjaCAxLg0K IA0KICAgIEknbSBzb3JyeSBJIGRpZG4ndCB1bmRlcnN0YW5kIGl0IHZlcnkgd2VsbC4NCiAgICBX aGF0ICpwcml2YXRlIHNwYWNlKiBhcmUgeW91IHRhbGtpbmcgYWJvdXQ/IElQdjQgb3IgSVB2Nj8N CiAgICBJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgSVB2NiwgQ0ROcyBub3JtYWxseSBoYXZlIElQ djYgR1VBLg0KICAgIElmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBjdXN0b21lcnMgd2l0aCBwcml2 YXRlIElQdjQgcmVhY2hpbmcgcHVibGljIElQdjQgZGVzdGluYXRpb24gQ0ROcywgeWVzIHdlIGNv dWxkIGV4cGxhaW4gaXQgYmVjYXVzZSBpdCBpcyB0aGUgbWFpbiBzY2VuYXJpbyB3ZSBhY3R1YWxs eSBzb21lIGNvbnRlbnQgcHJvdmlkZXJzIG9mZmVycyB0byBJU1BzIHRvIGRlbGl2ZXIgY29udGVu dCBmcm9tIHB1YmxpYyBJUHY0IG9mIENETiB0byBjdXN0b21lcnMgd2l0aCBwcml2YXRlIElQdjQg YXZvaWRpbmcgYSBDR04gcGxhdGZvcm0uIFRoYXQgd2FzIHRoZSBmaXJzdCByZWFzb24gdG8gY3Jl YXRlIHRoaXMgZG9jdW1lbnQuDQogICAgDQogICAgPiANCiAgICA+IA0KICAgID4gKiBTZWN0aW9u IDQuMzoNCiAgICA+ICAgT25lIG1vcmUgYWR2YW50YWdlIG9mIHRoaXMgc29sdXRpb24gaXMgdGhh dCB0aGUgRUFNVCBwYWlycyBkb2Vzbid0DQogICAgPiAgIG5lZWQgdG8gbWF0Y2ggdGhlICJyZWFs IiBJUHY0L0lQdjYgYWRkcmVzc2VzIGF2YWlsYWJsZSBpbiB0aGUgQS9BQUFBDQogICAgPiAgIHJl Y29yZHMsIGFzIHNob3duIGluIHRoZSBuZXh0IGV4YW1wbGUuDQogICAgPiANCiAgICA+IFBsZWFz ZSBlbGFib3JhdGUuDQogDQotPiBJIHRoaW5rIGl0IGlzIGNsZWFyIGlmIHlvdSBsb29rIGF0IHRo ZSBleGFtcGxlLg0KIA0KICAgID4gDQogICAgPiANCiAgICA+ICogU2VjdGlvbiA1Og0KICAgID4g ICBJZiBOQVQ0Ni9DTEFUL0ROUy1wcm94eS1FQU0gYXBwcm9hY2ggKFNlY3Rpb24gNC4yKSBpcyBj aG9zZW4sIGl0IGNhbg0KICAgID4gICBiZSBjb21wbGVtZW50ZWQgdG8gcmVzb2x2ZSB0aGlzIGlz c3VlLCBieSBtZWFucyBvZiBtYWtpbmcgc3VyZSB0aGF0DQogICAgPiAgIElQdjYtb25seSBkZXN0 aW5hdGlvbnMgaGF2ZSBvbmUgQSByZXNvdXJjZSByZWNvcmQgKGV2ZW4gYW4gaW52YWxpZA0KICAg ID4gICBvbmUpLCBkZXNwaXRlIHRoZXkgYXJlbid0IGFjdHVhbGx5IGNvbm5lY3RlZCB0byBJUHY0 Lg0KICAgID4gDQogICAgPiBOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuLg0KIA0KLT4gSSB0aGluayBp dCBpcyBjbGVhciBpZiB5b3UgcmVhZCB0aGUgcGFyYWdyYXBoIGJlZm9yZSB0aGF0IG9uZS4gT3Ro ZXJ3aXNlIHdlIGNvdWxkIGV4cGFuZCB0aGUgdGV4dCB0byBtYWtlIGl0IG1vcmUgb2J2aW91cy4N CiANCiAgICBJdCdzIGFuIGlkZWEsIHdlIG9mZmVyIGRpZmZlcmVudCBpZGVhcyAoYXBwcm9hY2hl cykgdG8gdHJ5IG9wdGltaXplIHRoZSB0cmFmZmljIGZsb3cuDQogICAgSGVyZSwgdGhlIGlkZWEg aXMgdGhhdCBpZiB0aGUgZGVzdGluYXRpb24gaXMgSVB2Ni1vbmx5LCB3aGVuIHdlIGhhdmUgYW4g SVB2NC1vbmx5IGRldmljZSwgaW4gYSBub3JtYWwgY2FzZSB5b3UgY291bGQgbmV2ZXIgcmVhY2gg dGhlIGRlc3RpbmF0aW9uIGJ1dCBpZiB5b3UgaGF2ZSB0aGlzIG9wdGltaXphdGlvbiB5b3VyIFBy b3h5IEROUyBjb3VsZCBkZXRlY3QgdGhhdCBpdCBkb2Vzbid0IGhhdmUgYW4gQSByZWNvcmQgYnV0 IGl0IGhhcyBhbiBBQUFBIHJlY29yZCwgc28geW91IGNvdWxkIGJlIGNvbm5lY3RlZCB0byB0aGUg SVB2NiBkZXN0aW5hdGlvbi4gV2l0aG91dCB0aGlzLCB5b3VyIElQdjQtb25seSBkZXZpY2Ugd291 bGQgbm90IGJlIGFibGUgdG8gZ2V0IHRoZSBJUHY2LW9ubHkgY29udGVudC4NCiAgICANCiAgICA+ IA0KICAgID4gDQogICAgPiAqIFNlY3Rpb24gNToNCiAgICA+ICAgSW4gZmFjdCwgaXQgbWF5IGJl Y29tZSBhbiBpbmNlbnRpdmUgZm9yIHRoZSBJUHY2IGRlcGxveW1lbnQgaW4NCiAgICA+ICAgSW50 ZXJuZXQgc2VydmljZXMgYW5kIHByb3ZpZGVzIHRoZSBvcHRpb24gdG8gdXNlIGFuIElQdjQgYWRk cmVzcw0KICAgID4gICAobWF5YmUgYW55Y2FzdCkgZm9yIHRoZSAibm9uLXZhbGlkIiBBIHJlc291 cmNlIHJlY29yZCwgdGhhdCBwb2ludHMgdG8NCiAgICA+ICAgYSAidW5pdmVyc2FsIiB3ZWIgcGFn ZSAobWF5YmUgaG9zdGVkIGJ5IElFVEY/KSB0aGF0IGRpc3BsYXlzIGENCiAgICA+ICAgd2Fybmlu ZyBzdWNoIGFzICJTb3JyeSwgeW91IGRvbid0IElQdjYgc3VwcG9ydCBpbiB5b3VyIG9wZXJhdG9y LCBzbw0KICAgID4gICB0aGlzIHNlcnZpY2UgaXMgbm90IGF2YWlsYWJsZSBmb3IgeW91Ii4NCiAg ICA+IA0KICAgID4gUGxlYXNlICpubyosIGZvciBzbyBtYW55IGRpZmZlcmVudCByZWFzb25zLiAt LSBpbmNsdWRpbmcgInRoZSBhdmVyYWdlDQogICAgPiB1c2VyIGRvZXNuJ3QgY2FyZSBhYm91dCBJ UHY2LCBhbmQgbWF5IG5vdCBldmVuIGJlIGF3YXJlIG9mIHdoYXQgaXQgaXMiLg0KIA0KLT4gSXQg Y2FuIGJlIGEgZGlmZmVyZW50IHRleHQgbm90IG5lY2Vzc2FyaWx5IG1lbnRpb24gSVB2NiBidXQg anVzdCAieW91ciBJbnRlcm5ldCBjb25uZWN0aW9uIGlzIG5vdCBhYmxlIHRvIGFjY2VzcyB0aGlz IGNvbnRlbnQsIHBsZWFzZSBhc2sgeW91ciBJU1AgdG8gdXBncmFkZSBpdCIuIEFueXdheSwgaXQg aXMgdmVyeSBjb250ZW50aW91cyB0b3BpYyAuLi4gVGhpcyBwcm9iYWJseSB3aWxsIGdldCByZW1v dmVkIGluIGEgbmV3IHZlcnNpb24sIG9yIG1vdmVkIHRvIGFuIGFubmV4LCBldGMuDQogDQogICAg T2ssIGl0IGNvdWxkIGJlLCBidXQgcmVtZW1iZXIgaXQgaXMgYW5vdGhlciBwcm9wb3NhbCBsaWtl IHRoZSBvdGhlciBhcHByb2FjaGVzIGFuZCB0aGUgaWRlYSBpcyB0byBnZXQgdGhlc2Uga2luZCBv ZiBpbnB1dHMuDQogICAgDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiAqIFNlY3Rpb24g NjoNCiAgICA+ICAgU2hvdWxkIHdlIHJlY29tbWVuZCBoYXZpbmcgQSByZWNvcmRzIGZvciBJUHY2 LW9ubHkgc2VydmljZXMgaW4NCiAgICA+ICAgSW50ZXJuZXQ/ICBUaGUgQSByZWNvcmQgbWF5IHBv aW50IHRvIGEgInJlc2VydmVkIiBvciAic3BlY2lhbCIgSVB2NA0KICAgID4gICBhZGRyZXNzLiAg QSB3ZWIgcGFnZSBJUHY0LW9ubHkgaG9zdGVkIGJ5IElFVEYoPykgc2hvd2luZyAic29ycnkgdGhp cw0KICAgID4gICB3ZWIgcGFnZS9zZXJ2aWNlIGlzIG9ubHkgYXZhaWxhYmxlIGZyb20gSVB2NiBl bmFibGVkIG9wZXJhdG9ycyI/Lg0KICAgID4gDQogICAgPiBQbGVhc2Ugbm8uIFRoaXMgYXNzdW1l cyAoPykgaG9zdHMgcHJlZmVyIElQdjYsIGJ1dCB0aGV5IGRvbid0IG5lZWQgdG8uDQogICAgPiBJ biB3aGljaCBjYXNlIHRoZXkgd291bGQgZ2V0IHRvIHN1Y2ggcGFnZSBhbmQgaGF2ZSBhIG5vdCBz byBncmVhdA0KICAgID4gV1RIKCE/KSBtb21lbnQuDQogICAgPiANCiAgICA+IA0KICAgID4gDQog ICAgPiAqIFNlY3Rpb24gNjoNCiAgICA+ICAgTkFUNDYvQ0xBVC9ETlMtcHJveHktRUFNIGFwcHJv YWNoIChTZWN0aW9uIDQuMikgc2VlbXMgdGhlIHJpZ2h0DQogICAgPiAgIHNvbHV0aW9uIGZvciBv cHRpbWl6aW5nIHRoZSBhY2Nlc3MgdG8gZHVhbC1zdGFjayBzZXJ2aWNlcywgd2hldGhlcg0KICAg ID4gICB0aGV5IGFyZSBsb2NhdGVkIGluc2lkZSBvciBvdXRzaWRlIHRoZSBJU1AuDQogICAgPiAN CiAgICA+IEl0IHdvdWxkIHNlZW0gdG8gbWUgdGhhdCwgYWN0dWFsbHksIEFwcHJvYWNoICMzLCB3 aGVuIHRoZSBJU1AgaGFzIG5vDQogICAgPiBjb250cm9sIG9uIHRoZSBDRE4sIG9yIGFwcHJvYWNo ICMxICh3aGVuIGl0IGRvZXMpLCBhcmUgdGhlIHdheSB0byBnby4NCiAgICA+IEFwcHJvYWNoICMy IHNlZW1zIHJhdGhlciBjb21wbGV4LCB3aXRoIHRoZSBjb25zZXF1ZW50IG9wcG9ydHVuaXRpZXMg dG8NCiAgICA+IHNjcmV3IHVwLg0KICAgIEFwcHJvYWNoICMxIGlzIG5vdCBlYXN5IHRvIGJlIGlt cGxlbWVudGVkIGJlY2F1c2UgY29udGVudCBwcm92aWRlcnMgZG9lc24ndCB3YW50IHRvIGJlIGVu dm9sdmVkIG9uIHRoaXMgcHJvY2VzcyBkZXNwaXRlIGFncmVlaW5nIGl0IGNhbiBiZSBhbiBpbXBy b3ZlbWVudCAsIHNvIHRoZSBkb24ndCB3YW50IHRvIGRvIGFueSBjaGFuZ2UgaW4gY29uZmlndXJh dGlvbiBvZiB0aGVpciBkZXZpY2VzIC8gaW50ZXJmYWNlcy4gSXQgYXBwbGllcyBtb3JlIGluIGNh c2Ugd2hlcmUgQ0ROIGlzIGNvbnRyb2xsZWQgYnkgSVNQIChvd24gQ0ROKSwgYnV0IHdlIHdhbnQg dG8gZGVmaW5lIGEgZ2VuZXJhbCBzb2x1dGlvbiwgd2UgbmVlZCB0byBjb25zaWRlciB0aGUgbm9y bWFsIGNhc2Ugb2YgcHVibGljIC8gZXh0ZXJuYWwgQ0ROcy4NCiAgICBBcHByb2FjaCAjMywgYXMg eW91IHNheSwgaXQgaXMgd2hlbiBJU1AgZG9lc24ndCBoYXZlIGNvbnRyb2wgb2YgdGhlIENETi4g VGhpcyBpcyBjb3VsZCBub3QgYmUgYSB2ZXJ5IHNjYWxhYmxlIHNvbHV0aW9uIGJlY2F1c2UgaXQn cyBub3QgZHluYW1pYyBhbmQgYW55IGNoYW5nZSBuZWVkcyB0byBiZSBwcm9wYWdhdGVkIHRvIGFs bCBDUEVzLiBPbiB0aGUgb3RoZXIgaGFuZCBpdCdzIGEgdmVyeSBlYXN5IG1ldGhvZCB0byBtYWtl IGEgZmFzdCBkZXBsb3kgd2hlcmUgdGhlcmUgYXJlIG5vdCBvZnRlbiBjaGFuZ2VzLiBJIHRoaW5r IHRoaXMgaXMgYSB3YXkgd2hlcmUgdGhhdCBhbGxvdyB0byB0aGUgb3BlcmF0b3IgdG8gZGVwbG95 IHRoZSBzb2x1dGlvbiBxdWlja2x5IHdpdGhvdXQgZGVwZW5kaW5nIG9uIGNvbXBsZXggbWVjaGFu aXNtcyBhbmQgd2hlcmUgY29udGVudCBwcm92aWRlciBkb2Vzbid0IGNoYW5nZSBETlMgcmVjb3Jk cywgdGhpcyBpcyB0aGUgY2FzZSBvZiBOZXRmbGl4IENETiB3aGVyZSBBIGFuZCBBQUFBIHJlY29y ZHMgYWx3YXlzIGhhdmUgdGhlIHNhbWUgSVBzIGFzc29jaWF0ZWQgZm9yIHRoZSBzYW1lIEZRRE4g KGZvciBDRE4pLg0KICAgIEFwcHJvYWNoICMyLCB5ZXMsIGNsZWFybHkgaXQgaXMgbW9yZSBjb21w bGV4IGJ1dCBpdCB3aWxsIGRlcGVuZHMgb24gaG93IG11Y2ggY29tcGxleGl0eSB3ZSB3YW50IHRv IGdpdmUgdG8gdGhlIHByb2Nlc3MgYW5kIHdlIG5lZWQgdG8gZGVmaW5lIHZlcnkgd2VsbCB3aGlj aCBjYXNlcyB3ZSB3YW50IHRvIGNvbnNpZGVyLg0KICAgIA0KICAgIA0KICAgID4gDQogICAgPiAN CiAgICA+ICogU2VjdGlvbiA2Og0KICAgID4gICBTSUlUIGFscmVhZHkgaGFzIGEgU0hPVUxEIGZv ciBFQU0gc3VwcG9ydC4gIFNob3VsZCA0NjRYTEFUIGJlIHVwZGF0ZWQNCiAgICA+ICAgYnkgdGhp cyBkb2N1bWVudCBzbyB0aGUgQ0xBVCBoYXMgYSBNVVNUIGZvciBFQU0gc3VwcG9ydD8uDQogICAg PiANCiAgICA+IDQ2NHhsYXQgZW1wbG95cyBleGlzdGluZyB0ZWNobm9sb2dpZXMuIFNvIEknbSBu b3Qgc3VyZSB5b3UgY2FuIGRvIGEgTVVTVA0KICAgID4gaW4gNDY0eGxhdCwgd2hlbiBpdCByZWxp ZXMgb24gU0lJVCwgYW5kIGZvciBTSUlUIHRoZSByZXF1aXJlbWVudCBpcyBhDQogICAgPiBTSE9V TEQuDQogICAgWWVzLCB3aGF0IHlvdSBzYXkgaXMgdmFsaWQsIHRoZXNlIGFyZSBxdWVzdGlvbnMg dG8gc2VlIGV4YWN0bHkgd2hhdCB0aGUgY29tbXVuaXR5IHRoaW5rcy4NCiAgICANCiAgICA+IA0K ICAgID4gQmVzaWRlcywgdGhlIDQ2NHhsYXQgc3BlYyBkb2VzIG5vdCBldmVuIGVtcGxveSBSRkMy MTE5IGxhbmd1YWdlLg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gKiBTZWN0aW9uIDc6 DQogICAgPiANCiAgICA+IEFueSBzb2x1dGlvbiB3aGVyZSB5b3Ugc3Bvb2YgRE5TIHJlY29yZHMg d291bGQgcGxheSBiYWQgd2l0aCBETlNzZWMuDQogICAgPiBUaGlzIHNob3VsZCBhdCBsZWFzdCBi ZSBkaXNjdXNzZWQuDQogICAgPiANCiAgICA+IA0KICAgID4gVGhhbmtzIQ0KICAgID4gDQogICAg PiBDaGVlcnMsDQogICAgPiBGZXJuYW5kbw0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4g DQogICAgPiBPbiAxMS8xMi8xOSAxNDoyNCwgUm9uIEJvbmljYSB3cm90ZToNCiAgICA+PiBGb2xr cywNCiAgICA+PiANCiAgICA+PiAgDQogICAgPj4gDQogICAgPj4gRWFjaCB3ZWVrIGJldHdlZW4g bm93IGFuZCBJRVRGIDEwNywgd2Ugd2lsbCByZXZpZXcgYW5kIGRpc2N1c3Mgb25lIGRyYWZ0DQog ICAgPj4gd2l0aCBhbiBleWUgdG93YXJkcyBwcm9ncmVzc2luZyBpdC4NCiAgICA+PiANCiAgICA+ PiAgDQogICAgPj4gDQogICAgPj4gVGhpcyB3ZWVrLCBwbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50 IG9uDQogICAgPj4gZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxhdC1vcHQtY2RuLWNhY2hlcy4NCiAg ICA+PiANCiAgICA+PiAgDQogICAgPj4gDQogICAgPj4gV2hlbiByZXZpZXdpbmcgdGhpcyBkcmFm dCwgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IHRoaW5rIHRoYXQgVjZPUFMNCiAgICA+PiBz aG91bGQgYWRvcHQgaXQgYSBzIGEgd29yayBpdGVtLg0KICAgID4+IA0KICAgID4+ICANCiAgICA+ PiANCiAgICA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGcmVkIGFuZCBSb24NCiAgICA+PiANCiAgICA+PiAgDQogICAgPj4gDQogICAgPj4g DQogICAgPj4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KICAgID4+IA0KICAgID4+IA0KICAg ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQogICAgPj4gdjZvcHNAaWV0Zi5vcmcNCiAgICA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgPj4gDQogICAgPiAN CiAgICA+IA0KICAgID4gLS0NCiAgICA+IEZlcm5hbmRvIEdvbnQNCiAgICA+IFNJNiBOZXR3b3Jr cw0KICAgID4gZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb20NCiAgICA+IFBHUCBGaW5nZXJw cmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAwRDU1IDFENEUgNzQ5Mg0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gdjZvcHMgbWFpbGluZyBsaXN0DQog ICAgPiB2Nm9wc0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZvcHNAaWV0Zi5v cmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAg DQogDQogDQogDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQpJUHY0IGlzIG92ZXINCkFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KaHR0 cDovL3d3dy50aGVpcHY2Y29tcGFueS5jb20NClRoZSBJUHY2IENvbXBhbnkNCiANClRoaXMgZWxl Y3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxl Z2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZv ciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQg ZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRp c3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2 ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xv c3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhp cyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxl cywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwg b2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZv cm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQogDQogDQogDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGlu ZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwp2Nm9wcyBtYWlsaW5nIGxpc3QKdjZvcHNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcwoNCg== ------=_001_NextPart743384616626_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Chongfeng,

 

In 464XLAT, the w= ay you allocate ports to customers in the NAT64 is typically much more effi= cient than in pre-allocation as done commonly in CGN or even MAP.

 

So, you get ports =E2=80=9Cas you need them=E2=80=9D. This means that yo= u=E2=80=99re, by default, making a better usage of each of the IPv4 address= es.

 

We have d= iscussed this in

 

https://datatracker.ietf.org/do= c/draft-lmhp-v6ops-transition-comparison=

 

Also, it means that yo= u=E2=80=99re not restricted to a given number of ports per subscriber.=

 

Regards,

Jordi=

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

 

 

 

El 7/1/2= 0 15:10, "v6ops en nombre de xiechf@chinatelecom.cn" <v6ops-bounces@ietf.org en nombre de xiechf@chinatelecom.cn> escribi=C3=B3:

 =

 

Hi=EF=BC=8CFernando,

Thank you for your comments.  You mentioned that 464XLAT is= able to save more IPv4 addresses, I think this is based on the comparison = with dual-stack approach, such as NAT44. Have you ever done some quantitati= ve analysis of  how much percentage of IPv4 addesses can be saved= with 464XLAT=EF=BC= =9F Thank you= =EF=BC=81

Best regards

Chongfeng

 <= /span>

 

=

Date:&= nbsp;2020-01-07 00:00

To:&nb= sp;v6ops

<= div>

Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-c= aches **Call for Adoption**

On 06/01/2020 05:3= 5, xiechf@chinatelecom.cn wro= te:

 

2\ Based on my experience, I t= hink the possibility of XLAT to be used in wireline network is very small, = Is there any large-scale ISP who plan to use XLAT for wireline broadband? N= early every IPv6-capable CPE is dual stack, it is very difficult to convinc= e the CPE industry to support XLAT in the forseen future. Another factor th= at we should consider is that the IPTV service of some ISPs is carried in a= seperate layer-two channle, which does not mix with the default Internet a= ccess traffic. 

Although the biggest challenge for 464XLAT adoption in fi= xed broadband ISPs is the lack of CLAT client on most CPEs I don't think th= at would be a major issue to convince CPE industry to have it because techn= ically speaking is a minor component of the firmware and quiet easy to add = de daemon. Sure it takes some time to happen, but it's not a major thing re= ally.
With this happening I bet in the future there is a potential of IS= Ps replacing CGNAT + IPv6 scenarios for 464XLAT for its advantages speciall= y in being able to save more Public IPv4 addresses.

With regards the IPTV service of some ISPs it occur= s inside the ISP backbone and in most cases wouldn't require any kind of tr= anslation on the ISP side.

Re= gards
Fernando Frediani

 

 

 

Date:&n= bsp;2020-01-06 04:56

Subject: Re: [v6ops] draft-palet-v6ops-464x= lat-opt-cdn-caches **Call for Adoption**

<= /div>

Hi Fernand= o,

 

Adding some inputs, below, in-line (->).

<= div>

 

=

=EF=BB=BFEl 4/= 1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" <v6ops-bounces@ietf.org en nombre de adegidio=3D40telecentro.ne= t.ar@dmarc.ietf.org> escribi=C3=B3:

 

=

    Hello = Fernando,

   

    First at all, thanks for y= our support to the work and the document and for taking your time to read a= ll the document.

   

    I will try to answe= r your comments below.

   

    <= /p>

  = ;  Regards,

    Alejandro

   

 &nb= sp;  ----- Mensaje original -----

    > De: "Fe= rnando Gont" <fgont@si6net= works.com>

    > Enviados: Viernes, 3 de Enero 2020 = 20:40:11

    > Asunto: Re: [v6ops] draft-palet-v6ops-464x= lat-opt-cdn-caches **Call for Adoption**

   

  &= nbsp; > Folks,

    &g= t;

    > I've read the document, and have the following = comments:

    >

    > It would seem to= me is that this document has resulted from an

    > oper= ators' concern that deployment of 464xlat might result in

   = ; > unnecessary heavyweight use of the stateful PLAT, leading to scalabi= lity

    > problems or unnecessary money spendings. In th= at sense, I would like the

    > issue to be documented (= even if somehow we don't agree on a workaround).

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    Yes, fr= om one point of view it is correct what you said and in addition to that we= have an unnecessary second translation (NAT64) when customer traffic was t= ranslated to IPv6 (NAT46) and the destination (content) is available in IPv= 6 also, so we could avoid both a bottleneck and a performance impairment. T= hat's why we consider this as an optimization.

 

<= div>

-> I think the doc= ument is doing the work of documenting the problem statement and providing = possible solutions, which the idea of choosing one. We understand that 464X= LAT was not designed having this scenario in mind, but if we can find a goo= d solution, is worth to solve it. Furthermore, if the WG agree that this is= the way to go, we could update with this document 464XLAT (which is an inf= ormational one) and make it to the standards track. As I've already express= ed several times, it is pity that being the transition mechanism that is mo= re used in the world (versus all the others, in terms of number of devices)= , it is not a standard.

   

    <= /p>

  = ;  >

    > So I support the adoption of this doc= ument (or some version of it) --

    > i.e., there's valu= e in documenting the issue itself.

    >

<= /div>

  &nb= sp; > That said, I think that further work is required on the document. = PLease

    > find my review below:

    >= ;

    >

    > **** Some meta comments= ****

    >

    > * Meta: I'd put more= stress on why this "optimization" is important. You

  =   > delve into many other (rather unnecessary) details, but don't elaborate

    > much regarding why this "opt= imization" is important.

 

-> My reading is that the optimizat= ion and the need for it is well described, but definitively will take a loo= k into it and improve it if needed.

 

    Yes, it is tr= ue, maybe the introduction could be simpler and more oriented to show the c= oncrete problem and why we believe this is important.

<= div>

   

&= nbsp;   I don't know if the info is wrong, maybe a specific initi= al summary that indicates it is missing. We can consider it.

=

  &n= bsp;

   

    >

    > = * Meta: It'd be important to note that, according to the Abstract of

 =    > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only = node. In that

    > sense, the behavior you describe is k= ind of "expected", and what you

    > describe = would seem to me more of a mechanism to *opt out of 464xlat*

=

  &n= bsp; > than an optimization to 464XLAT itself.

=

 

-> Yes, I said = that in my first comment. With this optimization, if we are able to find co= nsensus in a good solution, we improve something that was not initially exp= ected to be done by 464XLAT. I don't see the "opt-out" point that= you mention.

 

    Yes, 464XLAT asumes both IPv4 servi= ces and IPv4-only devices also.

    Yes, this is the expecte= d behavior of 464XLAT (and MAP-T also) but from a practical and performance= point of view, maybe, it is not the most optimal path for the end-to-end t= raffic flow. As you said if we avoid the NAT64, technically speaking, the t= raffic will not be going through a 464XLAT/MAP-T scenario.

  &nbs= p; We are not saying that 464XLAT is wrong at all, we are trying to expose = a real problem for IPv6 only network deployments and trying to present some= approaches to solve it (or minimize it)..

   

  =   >

    > * It would seem to me that the cases w= here this issue is more of a

    > concern is essentially= smartboxes (smart TVs) consuming media from large

    > CDNs. If so, this should be spelled out, since this essentially sets t= he

    > context for what options/approaches can be consi= dered acceptable.

    Ok, yes, we can put more effort to exp= lain that.

    

    >

  &= nbsp; >

    >

    > *** Some speci= fic comments: ****

    >

    > * Abstr= act: I'm curious if the term "NAT46" can be confusing, for

 =    > multiple reasons (for instance, it's not specified in RFC= 7915). Just use

    > "SIIT", and the context (= i.e., describe what's on each side of the SIIT

    > devi= ce, and what's the intent).

 

-> Initially we were using the term C= LAT, but then we realized that MAP-T has the same issue, and there it is no= t called CLAT, but NAT46. This is the reason, quite simple, because the opt= imization will also work for MAP-T.

 

    We can review= it if it is confusing.

    The idea on this point was to ta= lk about the NAT46 of CPE (CLAT).

    Yes, RFC7915 talks abo= ut SIIT independently if it is NAT46 or not.

    Regarding &= quot;(IP/ICMP Translation Algorithm) as described by [RFC7915]" it ref= ers just to SIIT.

    As we know, CLAT is a combination of N= AT46 + SIIT because it's an stateless translation from IPv4 to IPv6.

 =    

    >

    > <= /o:p>

 = ;   > * Introduction:

    > It seems to me t= he intro contains too many unnecessary details. e.g.,

<= div>

    &g= t; just talk about the CLAT as an abstract concept. Where/how

  &= nbsp; > (specifically) it is implemented is mostly irrelevant in the con= text of

    > this document.

    Yes, I do= n't know, it could be, as I put above maybe in the introduction we talk abo= ut many specific things and we could talk more about the problem itself.

 &nb= sp; 

    >

    >

=

  &n= bsp; > * Section 4:

    > Is the option where packets= might get to the Cache with *private space*

    > worth = mentioning/describing/discussing?

 

-> When we talked with CDN/cac= he providers, they don't like to use non-GUA (example the NAT64 WKP), so it= is discussed as an option in approach 1.

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    I'm sor= ry I didn't understand it very well.

    What *private space= * are you talking about? IPv4 or IPv6?

    If you are talkin= g about IPv6, CDNs normally have IPv6 GUA.

    If you are ta= lking about customers with private IPv4 reaching public IPv4 destination CD= Ns, yes we could explain it because it is the main scenario we actually som= e content providers offers to ISPs to deliver content from public IPv4 of C= DN to customers with private IPv4 avoiding a CGN platform. That was the fir= st reason to create this document.

   

=

    &= gt;

    >

    > * Section 4.3:

 =    >   One more advantage of this solution is that t= he EAMT pairs doesn't

    >   need to match t= he "real" IPv4/IPv6 addresses available in the A/AAAA<= /p>

  = ;  >   records, as shown in the next example.<= /p>

  = ;  >

    > Please elaborate.

 

-> I thin= k it is clear if you look at the example.

 

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

&= nbsp;   >

    > * Section 5:

=

  &n= bsp; >   If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is= chosen, it can

    >   be complemented to reso= lve this issue, by means of making sure that

    >   IPv6-only d= estinations have one A resource record (even an invalid

    = >   one), despite they aren't actually connected to IPv4.=

&nbs= p;   >

    > Not sure what you mean.

 =

-> I think it is clear if you read the paragraph before that one. Other= wise we could expand the text to make it more obvious.

=

 

  &= nbsp; It's an idea, we offer different ideas (approaches) to try optimize t= he traffic flow.

    Here, the idea is that if the destinati= on is IPv6-only, when we have an IPv4-only device, in a normal case you cou= ld never reach the destination but if you have this optimization your Proxy= DNS could detect that it doesn't have an A record but it has an AAAA recor= d, so you could be connected to the IPv6 destination. Without this, your IP= v4-only device would not be able to get the IPv6-only content.

  =  

    >

    >

   = ; > * Section 5:

    >   In fact, it may bec= ome an incentive for the IPv6 deployment in

    > &n= bsp; Internet services and provides the option to use an IPv4 address<= /o:p>

 = ;   >   (maybe anycast) for the "non-valid"= ; A resource record, that points to

    >   a &= quot;universal" web page (maybe hosted by IETF?) that displays a<= /o:p>

 = ;   >   warning such as "Sorry, you don't IPv6 = support in your operator, so

    >   this servi= ce is not available for you".

    >

<= /div>

  &nb= sp; > Please *no*, for so many different reasons. -- including "the= average

    > user doesn't care about IPv6, and may not = even be aware of what it is".

 

-> It can be a different text = not necessarily mention IPv6 but just "your Internet connection is not= able to access this content, please ask your ISP to upgrade it". Anyw= ay, it is very contentious topic ... This probably will get removed in a ne= w version, or moved to an annex, etc.

 

    Ok, it coul= d be, but remember it is another proposal like the other approaches and the idea is to get these kind of inputs.

    =

 &nbs= p;  >

    >

    >

 &n= bsp;  > * Section 6:

    >   Should we = recommend having A records for IPv6-only services in

    >= ;   Internet?  The A record may point to a "reserved&qu= ot; or "special" IPv4

    >   address= .  A web page IPv4-only hosted by IETF(?) showing "sorry this

&nb= sp;   >   web page/service is only available from IP= v6 enabled operators"?.

    >

<= div>

    &g= t; Please no. This assumes (?) hosts prefer IPv6, but they don't need to.

&= nbsp;   > In which case they would get to such page and have a= not so great

    > WTH(!?) moment.

<= div>

    &g= t;

    >

    >

<= div>

    &g= t; * Section 6:

    >   NAT46/CLAT/DNS-proxy-EA= M approach (Section 4.2) seems the right

    > &nbs= p; solution for optimizing the access to dual-stack services, whether<= /o:p>

 = ;   >   they are located inside or outside the ISP.<= o:p>

=     >

    > It would seem to me that, = actually, Approach #3, when the ISP has no

    > control = on the CDN, or approach #1 (when it does), are the way to go.

  &= nbsp; > Approach #2 seems rather complex, with the consequent opportunit= ies to

    > screw up.

    Approach #1 is= not easy to be implemented because content providers doesn't want to be en= volved on this process despite agreeing it can be an improvement , so the d= on't want to do any change in configuration of their devices / interfaces. = It applies more in case where CDN is controlled by ISP (own CDN), but we wa= nt to define a general solution, we need to consider the normal case of pub= lic / external CDNs.

    Approach #3, as you say, it is when= ISP doesn't have control of the CDN. This is could not be a very scalable = solution because it's not dynamic and any change needs to be propagated to all= CPEs. On the other hand it's a very easy method to make a fast deploy wher= e there are not often changes. I think this is a way where that allow to th= e operator to deploy the solution quickly without depending on complex mech= anisms and where content provider doesn't change DNS records, this is the c= ase of Netflix CDN where A and AAAA records always have the same IPs associ= ated for the same FQDN (for CDN).

    Approach #2, yes, clea= rly it is more complex but it will depends on how much complexity we want t= o give to the process and we need to define very well which cases we want t= o consider.

   

   

    >=

    >

    > * Section 6:<= /p>

  = ;  >   SIIT already has a SHOULD for EAM support.  S= hould 464XLAT be updated

    >   by this docume= nt so the CLAT has a MUST for EAM support?.

    >

 =    > 464xlat employs existing technologies. So I'm not sure yo= u can do a MUST

    > in 464xlat, when it relies on SIIT,= and for SIIT the requirement is a

    > SHOULD.

 &n= bsp;  Yes, what you say is valid, these are questions to see exactly w= hat the community thinks.

   

    > =

&nbs= p;   > Besides, the 464xlat spec does not even employ RFC2119 = language.

    >

    >

<= /div>

  &nb= sp; >

    > * Section 7:

    >

&nb= sp;   > Any solution where you spoof DNS records would play ba= d with DNSsec.

    > This should at least be discussed.

&= nbsp;   >

    >

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

    >

    > Cheers,

  =   > Fernando

    >

    >

<= /div>

  &nb= sp; >

    >

    > On 11/12/19 14:2= 4, Ron Bonica wrote:

    >> Folks,

    = >>

    >> 

    >>

&= nbsp;   >> Each week between now and IETF 107, we will revi= ew and discuss one draft

    >> with an eye towards pr= ogressing it.

    >>

    >> = ;

    >>

    >> This week, plea= se review and comment on

    >> draft-palet-v6ops-464x= lat-opt-cdn-caches.

    >>

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

    >>

    >> When revi= ewing this draft, please indicate whether you think that V6OPS

  =   >> should adopt it a s a work item.

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

    >> 

    >>

 &n= bsp;  >>         &n= bsp;            = ;            &n= bsp;            = ;        Fred and Ron

   = >>

    >> 

    >> <= o:p>

=     >>

    >> Juniper Business U= se Only

    >>

    >>

 &nb= sp;  >> _______________________________________________

 &n= bsp;  >> v6ops mailing list

    >> v6ops@ietf.org

    >>

    >

<= /div>

  &nb= sp; >

    > --

    > Fernando Gont<= o:p>

=     > SI6 Networks

    > e-mail: fgont@si6networks.com

=

  &n= bsp; > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 749= 2

    >

    >

    >=

    >

    > ________________________= _______________________

    > v6ops mailing list

 &n= bsp;  > v6ops@ietf.org

   

 &n= bsp;  _______________________________________________

  &nbs= p; v6ops mailing list

 =   

 

 

 

****************************************= ******

IPv4 is over

Are you ready for the new Internet ?

http://www.theipv6company.com

The IPv6 Company<= o:p>

=  

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 cont= ents of this information, even if partially, including attached files, is s= trictly prohibited and will be considered a criminal offense. If you are no= t 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 offen= se, so you must reply to the original sender to inform about this communica= tion and delete it.

 

 

 

_________________________________= ______________

v6ops mailing list



<= /p>

______________________________________=
_________
v6ops mailing l=
ist
v6ops@ietf.org
https://www.=
ietf.org/mailman/listinfo/v6ops

__________= _____________________________________ v6ops mailing list v6ops@ietf.org htt= ps://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_3661341085_1345769220-- From nobody Wed Jan 8 06:45:46 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F819120114 for ; Wed, 8 Jan 2020 06:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ8GU5Y0_pGU for ; Wed, 8 Jan 2020 06:45:35 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 72B29120044 for ; Wed, 8 Jan 2020 06:45:35 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id d18so2932961qtj.10 for ; Wed, 08 Jan 2020 06:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=idARoa0EyLBm6nzktUo2vhObbX4+Mrksz0mzkzl5QW8=; b=CP0KUSl1z+/qGbgPt8Sd9meabO4fhYDJKP4jk4n7ONWEvA009aecga6Dw8k4a874bm CgtcfSz0KrBQvAfhltEEtMtkvGvVVIIaOMD8ZvauUkMCs6OWPk8XplOajC4armyCLMI6 tncXqS9A9QwaTaA0wSYOJcEM2K/5fpzwZ1YJCbOACbybPlwlbXO9POY2N7vZXmp/CVX2 q5fzRdkOfUVutGd26MEvB6aytWNdA0w05j0b22zlF5bIp3joWKc64/wqXWKdAHo2gx8C ITP+VyciA14TwQ/zJsOSZdjOLLPqYdcgKiP0Derco6W4Lsn+xCVPNNnqhhiCbjfKwOcK BxOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=idARoa0EyLBm6nzktUo2vhObbX4+Mrksz0mzkzl5QW8=; b=Vpa/iF09LvSzCnYRJQzyS84q6weEm+gbIo/W0bGMtZLg9xbF5FFVfMUuf7YDzeSGLq UvcOKHa6Ufa4nUgGn6IoYMUgfE26ttngSUZWFoyqMI/R3yZebEqMGqrUWeMP4yBpxrHE YbEjTKHrjOyk4HhlXssau/K3FvkW/Iz1RHRmZS+yBgbbVTkAgwSv8kf5py3a9LYUmIWd Of3aILsEDRIa6XLEpK3sD0zl68SL5N/dtdJKpltiTfEOh424kkndgJhbYeX35JrCDvxK TChXOo5kIO5Ka5X1h4SUucjcZbEj7A+BL8zjYfXeKDpDcTPgTKxtkNvYxXwCdHUYySRT Sz/A== X-Gm-Message-State: APjAAAVlbSa8srZ7LEIYPLLiWDCuzQcD1WdRhd+5ac1ZWCZF5pZuGUZj 3zg1OdW25TrDPuT0ApGDPlqJi6Q2 X-Google-Smtp-Source: APXvYqxy+njFr3xIIhHFfWpsvg4vSdCPRWyul1XJjwjUeGSeWjlH5mdK4k0jaUACyJ5kJ+PDsc0rUg== X-Received: by 2002:ac8:1851:: with SMTP id n17mr3883141qtk.305.1578494734038; Wed, 08 Jan 2020 06:45:34 -0800 (PST) Received: from [192.168.10.100] ([201.82.45.199]) by smtp.gmail.com with ESMTPSA id y18sm1475821qki.0.2020.01.08.06.45.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 06:45:33 -0800 (PST) To: v6ops@ietf.org References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> From: Fernando Frediani Message-ID: <03db5441-ae0d-7813-7b65-1bfd37a36805@gmail.com> Date: Wed, 8 Jan 2020 11:45:29 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> Content-Type: multipart/alternative; boundary="------------EA8FCC0E478D8FC66514BB06" Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Jan 2020 14:45:42 -0000 This is a multi-part message in MIME format. --------------EA8FCC0E478D8FC66514BB06 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Actually, there is yet another advantage if this proposal passes: - As traffic which originally would be IPv4-only (due to the legacy devices), if it's able to be 'converted' to IPv6 at the CPE for IPv6 supported destinations this means less logging for law enforcement for all the stuff that would connect to the external world via the PLAT IPv4 addresses, meaning less storage, less log indexing and less people's time. Regards Fernando On 08/01/2020 11:11, JORDI PALET MARTINEZ wrote: > > Hi Chongfeng, > > In 464XLAT, the way you allocate ports to customers in the NAT64 is > typically much more efficient than in pre-allocation as done commonly > in CGN or even MAP. > > So, you get ports “as you need themâ€. This means that you’re, by > default, making a better usage of each of the IPv4 addresses. > > We have discussed this in > > https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison > > Also, it means that you’re not restricted to a given number of ports > per subscriber. > > Regards, > > Jordi > > @jordipalet > > El 7/1/20 15:10, "v6ops en nombre de xiechf@chinatelecom.cn > " en nombre de xiechf@chinatelecom.cn > > escribió: > > Hi，Fernando, > > Thank you for your comments.  You mentioned that 464XLAT is able to > save more IPv4 addresses, I think this is based on the comparison with > dual-stack approach, such as NAT44. Have you ever done some > quantitative analysis of  how much percentage of IPv4 addesses can be > saved with 464XLAT？ Thank youï¼ > > Best regards > > Chongfeng > > *From:*Fernando Frediani > > *Date:* 2020-01-07 00:00 > > *To:*v6ops > > *Subject:* Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches > **Call for Adoption** > > On 06/01/2020 05:35, xiechf@chinatelecom.cn > wrote: > > 2\ Based on my experience, I think the possibility of XLAT to > be used in wireline network is very small, Is there any > large-scale ISP who plan to use XLAT for wireline broadband? > Nearly every IPv6-capable CPE is dual stack, it is very > difficult to convince the CPE industry to support XLAT in the > forseen future. Another factor that we should consider is that > the IPTV service of some ISPs is carried in a seperate > layer-two channle, which does not mix with the default > Internet access traffic. > > Although the biggest challenge for 464XLAT adoption in fixed > broadband ISPs is the lack of CLAT client on most CPEs I don't > think that would be a major issue to convince CPE industry to have > it because technically speaking is a minor component of the > firmware and quiet easy to add de daemon. Sure it takes some time > to happen, but it's not a major thing really. > With this happening I bet in the future there is a potential of > ISPs replacing CGNAT + IPv6 scenarios for 464XLAT for its > advantages specially in being able to save more Public IPv4 addresses. > > With regards the IPTV service of some ISPs it occurs inside the > ISP backbone and in most cases wouldn't require any kind of > translation on the ISP side. > > Regards > Fernando Frediani > > *From:*JORDI PALET MARTINEZ > > > *Date:* 2020-01-06 04:56 > > *To:*v6ops@ietf.org list > > *Subject:* Re: [v6ops] > draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** > > Hi Fernando, > > Adding some inputs, below, in-line (->). > > El 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" > adegidio=40telecentro.net.ar@dmarc.ietf.org> > > escribió: > > Hello Fernando, > > First at all, thanks for your support to the work and the > document and for taking your time to read all the document. > > I will try to answer your comments below. > > Regards, > > Alejandro > > ----- Mensaje original ----- > > > De: "Fernando Gont" > > > > Para: "Ron Bonica" > > , > "v6ops@ietf.org list" > > > > Enviados: Viernes, 3 de Enero 2020 20:40:11 > > > Asunto: Re: [v6ops] > draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** > > > Folks, > > > > > > I've read the document, and have the following comments: > > > > > > It would seem to me is that this document has resulted > from an > > > operators' concern that deployment of 464xlat might > result in > > > unnecessary heavyweight use of the stateful PLAT, > leading to scalability > > > problems or unnecessary money spendings. In that sense, > I would like the > > > issue to be documented (even if somehow we don't agree > on a workaround). > > Yes, from one point of view it is correct what you said > and in addition to that we have an unnecessary second > translation (NAT64) when customer traffic was translated > to IPv6 (NAT46) and the destination (content) is available > in IPv6 also, so we could avoid both a bottleneck and a > performance impairment. That's why we consider this as an > optimization. > > -> I think the document is doing the work of documenting > the problem statement and providing possible solutions, > which the idea of choosing one. We understand that 464XLAT > was not designed having this scenario in mind, but if we > can find a good solution, is worth to solve it. > Furthermore, if the WG agree that this is the way to go, > we could update with this document 464XLAT (which is an > informational one) and make it to the standards track. As > I've already expressed several times, it is pity that > being the transition mechanism that is more used in the > world (versus all the others, in terms of number of > devices), it is not a standard. > > > > > > So I support the adoption of this document (or some > version of it) -- > > > i.e., there's value in documenting the issue itself. > > > > > > That said, I think that further work is required on the > document. PLease > > > find my review below: > > > > > > > > > **** Some meta comments **** > > > > > > * Meta: I'd put more stress on why this "optimization" > is important. You > > > delve into many other (rather unnecessary) details, but > don't elaborate > > > much regarding why this "optimization" is important. > > -> My reading is that the optimization and the need for it > is well described, but definitively will take a look into > it and improve it if needed. > > Yes, it is true, maybe the introduction could be simpler > and more oriented to show the concrete problem and why we > believe this is important. > > I don't know if the info is wrong, maybe a specific > initial summary that indicates it is missing. We can > consider it. > > > > > > * Meta: It'd be important to note that, according to the > Abstract of > > > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only > node. In that > > > sense, the behavior you describe is kind of "expected", > and what you > > > describe would seem to me more of a mechanism to *opt > out of 464xlat* > > > than an optimization to 464XLAT itself. > > -> Yes, I said that in my first comment. With this > optimization, if we are able to find consensus in a good > solution, we improve something that was not initially > expected to be done by 464XLAT. I don't see the "opt-out" > point that you mention. > > Yes, 464XLAT asumes both IPv4 services and IPv4-only > devices also. > > Yes, this is the expected behavior of 464XLAT (and MAP-T > also) but from a practical and performance point of view, > maybe, it is not the most optimal path for the end-to-end > traffic flow. As you said if we avoid the NAT64, > technically speaking, the traffic will not be going > through a 464XLAT/MAP-T scenario. > > We are not saying that 464XLAT is wrong at all, we are > trying to expose a real problem for IPv6 only network > deployments and trying to present some approaches to solve > it (or minimize it).. > > > > > > * It would seem to me that the cases where this issue is > more of a > > > concern is essentially smartboxes (smart TVs) consuming > media from large > > > CDNs. If so, this should be spelled out, since this > essentially sets the > > > context for what options/approaches can be considered > acceptable. > > Ok, yes, we can put more effort to explain that. > > > > > > > > > > > > *** Some specific comments: **** > > > > > > * Abstract: I'm curious if the term "NAT46" can be > confusing, for > > > multiple reasons (for instance, it's not specified in > RFC7915). Just use > > > "SIIT", and the context (i.e., describe what's on each > side of the SIIT > > > device, and what's the intent). > > -> Initially we were using the term CLAT, but then we > realized that MAP-T has the same issue, and there it is > not called CLAT, but NAT46. This is the reason, quite > simple, because the optimization will also work for MAP-T. > > We can review it if it is confusing. > > The idea on this point was to talk about the NAT46 of CPE > (CLAT). > > Yes, RFC7915 talks about SIIT independently if it is NAT46 > or not. > > Regarding "(IP/ICMP Translation Algorithm) as described by > [RFC7915]" it refers just to SIIT. > > As we know, CLAT is a combination of NAT46 + SIIT because > it's an stateless translation from IPv4 to IPv6. > > > > > > > > > * Introduction: > > > It seems to me the intro contains too many unnecessary > details. e.g., > > > just talk about the CLAT as an abstract concept. Where/how > > > (specifically) it is implemented is mostly irrelevant in > the context of > > > this document. > > Yes, I don't know, it could be, as I put above maybe in > the introduction we talk about many specific things and we > could talk more about the problem itself. > > > > > > > > > * Section 4: > > > Is the option where packets might get to the Cache with > *private space* > > > worth mentioning/describing/discussing? > > -> When we talked with CDN/cache providers, they don't > like to use non-GUA (example the NAT64 WKP), so it is > discussed as an option in approach 1. > > I'm sorry I didn't understand it very well. > > What *private space* are you talking about? IPv4 or IPv6? > > If you are talking about IPv6, CDNs normally have IPv6 GUA. > > If you are talking about customers with private IPv4 > reaching public IPv4 destination CDNs, yes we could > explain it because it is the main scenario we actually > some content providers offers to ISPs to deliver content > from public IPv4 of CDN to customers with private IPv4 > avoiding a CGN platform. That was the first reason to > create this document. > > > > > > > > > * Section 4.3: > > >   One more advantage of this solution is that the EAMT > pairs doesn't > > >   need to match the "real" IPv4/IPv6 addresses available > in the A/AAAA > > >   records, as shown in the next example. > > > > > > Please elaborate. > > -> I think it is clear if you look at the example. > > > > > > > > > * Section 5: > > >   If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is > chosen, it can > > >   be complemented to resolve this issue, by means of > making sure that > > >   IPv6-only destinations have one A resource record > (even an invalid > > >   one), despite they aren't actually connected to IPv4. > > > > > > Not sure what you mean. > > -> I think it is clear if you read the paragraph before > that one. Otherwise we could expand the text to make it > more obvious. > > It's an idea, we offer different ideas (approaches) to try > optimize the traffic flow. > > Here, the idea is that if the destination is IPv6-only, > when we have an IPv4-only device, in a normal case you > could never reach the destination but if you have this > optimization your Proxy DNS could detect that it doesn't > have an A record but it has an AAAA record, so you could > be connected to the IPv6 destination. Without this, your > IPv4-only device would not be able to get the IPv6-only > content. > > > > > > > > > * Section 5: > > >   In fact, it may become an incentive for the IPv6 > deployment in > > >   Internet services and provides the option to use an > IPv4 address > > >   (maybe anycast) for the "non-valid" A resource record, > that points to > > >   a "universal" web page (maybe hosted by IETF?) that > displays a > > >   warning such as "Sorry, you don't IPv6 support in your > operator, so > > >   this service is not available for you". > > > > > > Please *no*, for so many different reasons. -- including > "the average > > > user doesn't care about IPv6, and may not even be aware > of what it is". > > -> It can be a different text not necessarily mention IPv6 > but just "your Internet connection is not able to access > this content, please ask your ISP to upgrade it". Anyway, > it is very contentious topic ... This probably will get > removed in a new version, or moved to an annex, etc. > > Ok, it could be, but remember it is another proposal like > the other approaches and the idea is to get these kind of > inputs. > > > > > > > > > > > > * Section 6: > > >   Should we recommend having A records for IPv6-only > services in > > >   Internet?  The A record may point to a "reserved" or > "special" IPv4 > > >   address..  A web page IPv4-only hosted by IETF(?) > showing "sorry this > > >   web page/service is only available from IPv6 enabled > operators"?. > > > > > > Please no. This assumes (?) hosts prefer IPv6, but they > don't need to. > > > In which case they would get to such page and have a not > so great > > > WTH(!?) moment. > > > > > > > > > > > > * Section 6: > > >   NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems > the right > > >   solution for optimizing the access to dual-stack > services, whether > > >   they are located inside or outside the ISP. > > > > > > It would seem to me that, actually, Approach #3, when > the ISP has no > > > control on the CDN, or approach #1 (when it does), are > the way to go. > > > Approach #2 seems rather complex, with the consequent > opportunities to > > > screw up. > > Approach #1 is not easy to be implemented because content > providers doesn't want to be envolved on this process > despite agreeing it can be an improvement , so the don't > want to do any change in configuration of their devices / > interfaces. It applies more in case where CDN is > controlled by ISP (own CDN), but we want to define a > general solution, we need to consider the normal case of > public / external CDNs. > > Approach #3, as you say, it is when ISP doesn't have > control of the CDN. This is could not be a very scalable > solution because it's not dynamic and any change needs to > be propagated to all CPEs. On the other hand it's a very > easy method to make a fast deploy where there are not > often changes. I think this is a way where that allow to > the operator to deploy the solution quickly without > depending on complex mechanisms and where content provider > doesn't change DNS records, this is the case of Netflix > CDN where A and AAAA records always have the same IPs > associated for the same FQDN (for CDN). > > Approach #2, yes, clearly it is more complex but it will > depends on how much complexity we want to give to the > process and we need to define very well which cases we > want to consider. > > > > > > > > > * Section 6: > > >   SIIT already has a SHOULD for EAM support.  Should > 464XLAT be updated > > >   by this document so the CLAT has a MUST for EAM support?. > > > > > > 464xlat employs existing technologies. So I'm not sure > you can do a MUST > > > in 464xlat, when it relies on SIIT, and for SIIT the > requirement is a > > > SHOULD. > > Yes, what you say is valid, these are questions to see > exactly what the community thinks. > > > > > > Besides, the 464xlat spec does not even employ RFC2119 > language. > > > > > > > > > > > > * Section 7: > > > > > > Any solution where you spoof DNS records would play bad > with DNSsec. > > > This should at least be discussed. > > > > > > > > > Thanks! > > > > > > Cheers, > > > Fernando > > > > > > > > > > > > > > > On 11/12/19 14:24, Ron Bonica wrote: > > >> Folks, > > >> > > >> > > >> > > >> Each week between now and IETF 107, we will review and > discuss one draft > > >> with an eye towards progressing it. > > >> > > >> > > >> > > >> This week, please review and comment on > > >> draft-palet-v6ops-464xlat-opt-cdn-caches. > > >> > > >> > > >> > > >> When reviewing this draft, please indicate whether you > think that V6OPS > > >> should adopt it a s a work item. > > >> > > >> > > >> > > >>                                                       > Fred and Ron > > >> > > >> > > >> > > >> > > >> Juniper Business Use Only > > >> > > >> > > >> _______________________________________________ > > >> v6ops mailing list > > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > > >> > > > > > > > > > -- > > > Fernando Gont > > > SI6 Networks > > > e-mail: fgont@si6networks.com > > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 > 1D4E 7492 > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > ********************************************** > > 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 > > _______________________________________________ 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 --------------EA8FCC0E478D8FC66514BB06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Actually, there is yet another advantage if this proposal passes:

- As traffic which originally would be IPv4-only (due to the legacy devices), if it's able to be 'converted' to IPv6 at the CPE for IPv6 supported destinations this means less logging for law enforcement for all the stuff that would connect to the external world via the PLAT IPv4 addresses, meaning less storage, less log indexing and less people's time.

Regards
Fernando

On 08/01/2020 11:11, JORDI PALET MARTINEZ wrote:

Hi Chongfeng,

 

In 464XLAT, the way you allocate ports to customers in the NAT64 is typically much more efficient than in pre-allocation as done commonly in CGN or even MAP.

 

So, you get ports “as you need themâ€. This means that you’re, by default, making a better usage of each of the IPv4 addresses.

 

We have discussed this in

 

https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison

 

Also, it means that you’re not restricted to a given number of ports per subscriber.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/1/20 15:10, "v6ops en nombre de xiechf@chinatelecom.cn" <v6ops-bounces@ietf.org en nombre de xiechf@chinatelecom.cn> escribió:

 

 

Hi，Fernando,

Thank you for your comments.  You mentioned that 464XLAT is able to save more IPv4 addresses, I think this is based on the comparison with dual-stack approach, such as NAT44. Have you ever done some quantitative analysis of  how much percentage of IPv4 addesses can be saved with 464XLAT？ Thank youï¼

Best regards

Chongfeng

 

 

Date: 2020-01-07 00:00

To: v6ops

Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

On 06/01/2020 05:35, xiechf@chinatelecom.cn wrote:

 

2\ Based on my experience, I think the possibility of XLAT to be used in wireline network is very small, Is there any large-scale ISP who plan to use XLAT for wireline broadband? Nearly every IPv6-capable CPE is dual stack, it is very difficult to convince the CPE industry to support XLAT in the forseen future. Another factor that we should consider is that the IPTV service of some ISPs is carried in a seperate layer-two channle, which does not mix with the default Internet access traffic. 

Although the biggest challenge for 464XLAT adoption in fixed broadband ISPs is the lack of CLAT client on most CPEs I don't think that would be a major issue to convince CPE industry to have it because technically speaking is a minor component of the firmware and quiet easy to add de daemon. Sure it takes some time to happen, but it's not a major thing really.
With this happening I bet in the future there is a potential of ISPs replacing CGNAT + IPv6 scenarios for 464XLAT for its advantages specially in being able to save more Public IPv4 addresses.

With regards the IPTV service of some ISPs it occurs inside the ISP backbone and in most cases wouldn't require any kind of translation on the ISP side.

Regards
Fernando Frediani

 

 

 

Date: 2020-01-06 04:56

Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

Hi Fernando,

 

Adding some inputs, below, in-line (->).

 

El 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" <v6ops-bounces@ietf.org en nombre de adegidio=40telecentro.net.ar@dmarc.ietf.org> escribió:

 

    Hello Fernando,

   

    First at all, thanks for your support to the work and the document and for taking your time to read all the document.

   

    I will try to answer your comments below.

   

   

    Regards,

    Alejandro

   

    ----- Mensaje original -----

    > De: "Fernando Gont" <fgont@si6networks.com>

    > Enviados: Viernes, 3 de Enero 2020 20:40:11

    > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

   

    > Folks,

    >

    > I've read the document, and have the following comments:

    >

    > It would seem to me is that this document has resulted from an

    > operators' concern that deployment of 464xlat might result in

    > unnecessary heavyweight use of the stateful PLAT, leading to scalability

    > problems or unnecessary money spendings. In that sense, I would like the

    > issue to be documented (even if somehow we don't agree on a workaround).

    Yes, from one point of view it is correct what you said and in addition to that we have an unnecessary second translation (NAT64) when customer traffic was translated to IPv6 (NAT46) and the destination (content) is available in IPv6 also, so we could avoid both a bottleneck and a performance impairment. That's why we consider this as an optimization.

 

-> I think the document is doing the work of documenting the problem statement and providing possible solutions, which the idea of choosing one. We understand that 464XLAT was not designed having this scenario in mind, but if we can find a good solution, is worth to solve it. Furthermore, if the WG agree that this is the way to go, we could update with this document 464XLAT (which is an informational one) and make it to the standards track. As I've already expressed several times, it is pity that being the transition mechanism that is more used in the world (versus all the others, in terms of number of devices), it is not a standard.

   

   

    >

    > So I support the adoption of this document (or some version of it) --

    > i.e., there's value in documenting the issue itself.

    >

    > That said, I think that further work is required on the document. PLease

    > find my review below:

    >

    >

    > **** Some meta comments ****

    >

    > * Meta: I'd put more stress on why this "optimization" is important. You

    > delve into many other (rather unnecessary) details, but don't elaborate

    > much regarding why this "optimization" is important.

 

-> My reading is that the optimization and the need for it is well described, but definitively will take a look into it and improve it if needed.

 

    Yes, it is true, maybe the introduction could be simpler and more oriented to show the concrete problem and why we believe this is important.

   

    I don't know if the info is wrong, maybe a specific initial summary that indicates it is missing. We can consider it.

   

   

    >

    > * Meta: It'd be important to note that, according to the Abstract of

    > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In that

    > sense, the behavior you describe is kind of "expected", and what you

    > describe would seem to me more of a mechanism to *opt out of 464xlat*

    > than an optimization to 464XLAT itself.

 

-> Yes, I said that in my first comment. With this optimization, if we are able to find consensus in a good solution, we improve something that was not initially expected to be done by 464XLAT. I don't see the "opt-out" point that you mention.

 

    Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also.

    Yes, this is the expected behavior of 464XLAT (and MAP-T also) but from a practical and performance point of view, maybe, it is not the most optimal path for the end-to-end traffic flow. As you said if we avoid the NAT64, technically speaking, the traffic will not be going through a 464XLAT/MAP-T scenario.

    We are not saying that 464XLAT is wrong at all, we are trying to expose a real problem for IPv6 only network deployments and trying to present some approaches to solve it (or minimize it)..

   

    >

    > * It would seem to me that the cases where this issue is more of a

    > concern is essentially smartboxes (smart TVs) consuming media from large

    > CDNs. If so, this should be spelled out, since this essentially sets the

    > context for what options/approaches can be considered acceptable.

    Ok, yes, we can put more effort to explain that.

    

    >

    >

    >

    > *** Some specific comments: ****

    >

    > * Abstract: I'm curious if the term "NAT46" can be confusing, for

    > multiple reasons (for instance, it's not specified in RFC7915). Just use

    > "SIIT", and the context (i.e., describe what's on each side of the SIIT

    > device, and what's the intent).

 

-> Initially we were using the term CLAT, but then we realized that MAP-T has the same issue, and there it is not called CLAT, but NAT46. This is the reason, quite simple, because the optimization will also work for MAP-T.

 

    We can review it if it is confusing.

    The idea on this point was to talk about the NAT46 of CPE (CLAT).

    Yes, RFC7915 talks about SIIT independently if it is NAT46 or not.

    Regarding "(IP/ICMP Translation Algorithm) as described by [RFC7915]" it refers just to SIIT.

    As we know, CLAT is a combination of NAT46 + SIIT because it's an stateless translation from IPv4 to IPv6.

    

    >

    >

    > * Introduction:

    > It seems to me the intro contains too many unnecessary details. e.g.,

    > just talk about the CLAT as an abstract concept. Where/how

    > (specifically) it is implemented is mostly irrelevant in the context of

    > this document.

    Yes, I don't know, it could be, as I put above maybe in the introduction we talk about many specific things and we could talk more about the problem itself.

   

    >

    >

    > * Section 4:

    > Is the option where packets might get to the Cache with *private space*

    > worth mentioning/describing/discussing?

 

-> When we talked with CDN/cache providers, they don't like to use non-GUA (example the NAT64 WKP), so it is discussed as an option in approach 1.

 

    I'm sorry I didn't understand it very well.

    What *private space* are you talking about? IPv4 or IPv6?

    If you are talking about IPv6, CDNs normally have IPv6 GUA.

    If you are talking about customers with private IPv4 reaching public IPv4 destination CDNs, yes we could explain it because it is the main scenario we actually some content providers offers to ISPs to deliver content from public IPv4 of CDN to customers with private IPv4 avoiding a CGN platform. That was the first reason to create this document.

   

    >

    >

    > * Section 4.3:

    >   One more advantage of this solution is that the EAMT pairs doesn't

    >   need to match the "real" IPv4/IPv6 addresses available in the A/AAAA

    >   records, as shown in the next example.

    >

    > Please elaborate.

 

-> I think it is clear if you look at the example.

 

    >

    >

    > * Section 5:

    >   If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it can

    >   be complemented to resolve this issue, by means of making sure that

    >   IPv6-only destinations have one A resource record (even an invalid

    >   one), despite they aren't actually connected to IPv4.

    >

    > Not sure what you mean.

 

-> I think it is clear if you read the paragraph before that one. Otherwise we could expand the text to make it more obvious.

 

    It's an idea, we offer different ideas (approaches) to try optimize the traffic flow.

    Here, the idea is that if the destination is IPv6-only, when we have an IPv4-only device, in a normal case you could never reach the destination but if you have this optimization your Proxy DNS could detect that it doesn't have an A record but it has an AAAA record, so you could be connected to the IPv6 destination. Without this, your IPv4-only device would not be able to get the IPv6-only content.

   

    >

    >

    > * Section 5:

    >   In fact, it may become an incentive for the IPv6 deployment in

    >   Internet services and provides the option to use an IPv4 address

    >   (maybe anycast) for the "non-valid" A resource record, that points to

    >   a "universal" web page (maybe hosted by IETF?) that displays a

    >   warning such as "Sorry, you don't IPv6 support in your operator, so

    >   this service is not available for you".

    >

    > Please *no*, for so many different reasons. -- including "the average

    > user doesn't care about IPv6, and may not even be aware of what it is".

 

-> It can be a different text not necessarily mention IPv6 but just "your Internet connection is not able to access this content, please ask your ISP to upgrade it". Anyway, it is very contentious topic ... This probably will get removed in a new version, or moved to an annex, etc.

 

    Ok, it could be, but remember it is another proposal like the other approaches and the idea is to get these kind of inputs.

   

    >

    >

    >

    > * Section 6:

    >   Should we recommend having A records for IPv6-only services in

    >   Internet?  The A record may point to a "reserved" or "special" IPv4

    >   address..  A web page IPv4-only hosted by IETF(?) showing "sorry this

    >   web page/service is only available from IPv6 enabled operators"?.

    >

    > Please no. This assumes (?) hosts prefer IPv6, but they don't need to.

    > In which case they would get to such page and have a not so great

    > WTH(!?) moment.

    >

    >

    >

    > * Section 6:

    >   NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right

    >   solution for optimizing the access to dual-stack services, whether

    >   they are located inside or outside the ISP.

    >

    > It would seem to me that, actually, Approach #3, when the ISP has no

    > control on the CDN, or approach #1 (when it does), are the way to go.

    > Approach #2 seems rather complex, with the consequent opportunities to

    > screw up.

    Approach #1 is not easy to be implemented because content providers doesn't want to be envolved on this process despite agreeing it can be an improvement , so the don't want to do any change in configuration of their devices / interfaces. It applies more in case where CDN is controlled by ISP (own CDN), but we want to define a general solution, we need to consider the normal case of public / external CDNs.

    Approach #3, as you say, it is when ISP doesn't have control of the CDN. This is could not be a very scalable solution because it's not dynamic and any change needs to be propagated to all CPEs. On the other hand it's a very easy method to make a fast deploy where there are not often changes. I think this is a way where that allow to the operator to deploy the solution quickly without depending on complex mechanisms and where content provider doesn't change DNS records, this is the case of Netflix CDN where A and AAAA records always have the same IPs associated for the same FQDN (for CDN).

    Approach #2, yes, clearly it is more complex but it will depends on how much complexity we want to give to the process and we need to define very well which cases we want to consider.

   

   

    >

    >

    > * Section 6:

    >   SIIT already has a SHOULD for EAM support.  Should 464XLAT be updated

    >   by this document so the CLAT has a MUST for EAM support?.

    >

    > 464xlat employs existing technologies. So I'm not sure you can do a MUST

    > in 464xlat, when it relies on SIIT, and for SIIT the requirement is a

    > SHOULD.

    Yes, what you say is valid, these are questions to see exactly what the community thinks.

   

    >

    > Besides, the 464xlat spec does not even employ RFC2119 language.

    >

    >

    >

    > * Section 7:

    >

    > Any solution where you spoof DNS records would play bad with DNSsec.

    > This should at least be discussed.

    >

    >

    > Thanks!

    >

    > Cheers,

    > Fernando

    >

    >

    >

    >

    > On 11/12/19 14:24, Ron Bonica wrote:

    >> Folks,

    >>

    >> 

    >>

    >> Each week between now and IETF 107, we will review and discuss one draft

    >> with an eye towards progressing it.

    >>

    >> 

    >>

    >> This week, please review and comment on

    >> draft-palet-v6ops-464xlat-opt-cdn-caches.

    >>

    >> 

    >>

    >> When reviewing this draft, please indicate whether you think that V6OPS

    >> should adopt it a s a work item.

    >>

    >> 

    >>

    >>                                                       Fred and Ron

    >>

    >> 

    >>

    >>

    >> Juniper Business Use Only

    >>

    >>

    >> _______________________________________________

    >> v6ops mailing list

    >> v6ops@ietf.org

    >>

    >

    >

    > --

    > Fernando Gont

    > SI6 Networks

    > e-mail: fgont@si6networks.com

    > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

    >

    >

    >

    >

    > _______________________________________________

    > v6ops mailing list

    > v6ops@ietf.org

   

    _______________________________________________

    v6ops mailing list

    v6ops@ietf.org

   

 

 

 

**********************************************

IPv4 is over

Are you ready for the new Internet ?

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


**********************************************
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
--------------EA8FCC0E478D8FC66514BB06-- From nobody Thu Jan 9 05:09:29 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34611200C1 for ; Thu, 9 Jan 2020 05:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1ti1Rl_0SFp for ; Thu, 9 Jan 2020 05:09:26 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB7F12001E for ; Thu, 9 Jan 2020 05:09:25 -0800 (PST) Received: from [192.168.0.133] (unknown [181.46.150.232]) (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 D732386B4B; Thu, 9 Jan 2020 14:09:08 +0100 (CET) To: JORDI PALET MARTINEZ , v6ops References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> From: Fernando Gont 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: <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> Date: Thu, 9 Jan 2020 09:46:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 13:09:28 -0000 On 8/1/20 11:11, JORDI PALET MARTINEZ wrote: > Hi Chongfeng, > >   > > In 464XLAT, the way you allocate ports to customers in the NAT64 is > typically much more efficient than in pre-allocation as done commonly in > CGN or even MAP. How do you mitigate the potential of DoS if you don't pre-allocate a range or number of ports to each customer? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 9 06:22:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9584C1200B9 for ; Thu, 9 Jan 2020 06:22:16 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqxrVQfdyDJG for ; Thu, 9 Jan 2020 06:22:15 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 79356120026 for ; Thu, 9 Jan 2020 06:22:15 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id t2so5808419ilq.9 for ; Thu, 09 Jan 2020 06:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1sW2EoanzFSqV1YY1VzqC5b64/EgK2GK8D0T2Vigi4w=; b=htbZG8RT/ZK9ud6q8T3HaG7E6nWTCRgJFVrnQ6vcdwAEv6JY4fk9k+e8wRahhIN9Kk zF73o4ZmIDtmVCuvVvrbYT5jfFYi/cR8VZsj53aISC51h/Bk0vPB0uXorLJfrwkPS33U GUR2sdLJnMwA+5ytytsqTLA9TDEiIEjZh6BxgmKCiWpdxJfl62ArcCndHtGkvMPoWUjC l1mkvGvR45qTZtIt0o8y+HyqevTgqDPXYJPVa7ezM3yC1rEDxFuDXDIeuZShdIXZOatY Ug0XrRr3HyhTfaAuSJl5ZIUFF5gcrbKAMAjEP6/309gbxDLd3N9Y+42EnTPYkMnUqZqa RM8Q== 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=1sW2EoanzFSqV1YY1VzqC5b64/EgK2GK8D0T2Vigi4w=; b=G014TZ28D9zNReLe0eA7vGEHkbhNyLiNdTSa6YktSJ9JH/lFqSpuIXzmxj5znerspw SIErRjNvKdtBVXW+/6Jk1j2NTPgGHIf01dq7iNKjgAqXXaShTybbwVayLquiqLwZEmf4 9uIGl6Z63VCcdkRy84ffM18B1ZYgs9/L+QVgZaVG3EHWui2+85wP/YkSBRtd0mSFbDyB 9uvllwz3ih2kmSncAepX3s44wGpd9MLpVQdR9Ncfv1i/LzQZSVrqHuo379U+Ur+YTH+l y7k/YSVqFtkm3O/hvKGiSjG4XC32YClOLBIEnEm41etc9swtu4ExWLH8P0ka5fXpI5eT WO0w== X-Gm-Message-State: APjAAAWXylhp+mXqXLxqI9j4SB/K0HrmPjuYxYZvvXaRX52+5g+y0Ize Qu77hAeeNZcPIFsu/s60VHSqkgIMDnGLMZCGZST8cA== X-Google-Smtp-Source: APXvYqzXPcknxvZkZ//IYr2VNgEiZlm3L1wTXgSP2EZtJe2M/uRqhuzun9Eeo0Te/2uN3s0kSKwqL/eRi5AUyQL0vsw= X-Received: by 2002:a92:7e0a:: with SMTP id z10mr7542191ilc.190.1578579734808; Thu, 09 Jan 2020 06:22:14 -0800 (PST) MIME-Version: 1.0 References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> In-Reply-To: <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> From: Ca By Date: Thu, 9 Jan 2020 06:22:03 -0800 Message-ID: To: Fernando Gont Cc: JORDI PALET MARTINEZ , v6ops Content-Type: multipart/alternative; boundary="00000000000057cf24059bb5bcbe" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 14:22:17 -0000 --00000000000057cf24059bb5bcbe Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 at 5:09 AM Fernando Gont wrote: > On 8/1/20 11:11, JORDI PALET MARTINEZ wrote: > > Hi Chongfeng, > > > > > > > > In 464XLAT, the way you allocate ports to customers in the NAT64 is > > typically much more efficient than in pre-allocation as done commonly in > > CGN or even MAP. > > How do you mitigate the potential of DoS if you don't pre-allocate a > range or number of ports to each customer? > Same way you do it in NAT44, you set an upper bounds on number of sessions a user can dynamically create. > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000057cf24059bb5bcbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 9, 2020 at 5:09 AM Fernando Gont <fgont@si6networks.com> wrote:
On 8/1/20 11:11, JORDI PALET MARTINEZ wrot= e:
> Hi Chongfeng,
>
> =C2=A0
>
> In 464XLAT, the way you allocate ports to customers in the NAT64 is > typically much more efficient than in pre-allocation as done commonly = in
> CGN or even MAP.

How do you mitigate the potential of DoS if you don't pre-allocate a range or number of ports to each customer?

Same way you do = it in NAT44, you set an upper bounds on number of sessions a user can dynam= ically create.=C2=A0


Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000057cf24059bb5bcbe-- From nobody Thu Jan 9 06:54:29 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D044120059 for ; Thu, 9 Jan 2020 06:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nyBmksqD57uw for ; Thu, 9 Jan 2020 06:54:26 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483C3120019 for ; Thu, 9 Jan 2020 06:54:26 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 47tpzj093sz8tGP; Thu, 9 Jan 2020 15:54:25 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 47tpzh5ybKz1xpF; Thu, 9 Jan 2020 15:54:24 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 9 Jan 2020 15:54:24 +0100 From: To: Ca By , Fernando Gont CC: v6ops , JORDI PALET MARTINEZ Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** Thread-Index: AQHVxvgplyBpZJMP6Ua61fyaAD073afiaaiw Date: Thu, 9 Jan 2020 14:54:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031406805@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031406805OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 14:54:28 -0000 --_000_787AE7BB302AE849A7480A190F8B933031406805OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBZ3JlZSB3aXRoIENhbWVyb24uDQoNClJFUSM0IGFuZCBSRVEjNSBmcm9tIFJG QzY4ODggc2hvdWxkIGJlIGZvbGxvd2VkLiBNb3JlIGRldGFpbHMgYWJvdXQgdGhlc2UgbGltaXRz IGNhbiBhbHNvIGJlIGZvdW5kIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NTEy I3NlY3Rpb24tMi45Lg0KDQpJIGRpc2FncmVlIHdpdGggSm9yZGkgd2hlbiBoZSBzYXlzIHRoYXQg TkFUNjQgaXMgc3BlY2lmaWMgY29tcGFyZWQgdG8gYW55IG90aGVyIENHTiBmbGF2b3Igd2l0aCBy ZWdhcmRzIHRvIHNoYXJlZCBhZGRyZXNzZXMgdXNhZ2UuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBDYSBC eQ0KRW52b3nDqSA6IGpldWRpIDkgamFudmllciAyMDIwIDE1OjIyDQrDgCA6IEZlcm5hbmRvIEdv bnQNCkNjIDogdjZvcHM7IEpPUkRJIFBBTEVUIE1BUlRJTkVaDQpPYmpldCA6IFJlOiBbdjZvcHNd IGRyYWZ0LXBhbGV0LXY2b3BzLTQ2NHhsYXQtb3B0LWNkbi1jYWNoZXMgKipDYWxsIGZvciBBZG9w dGlvbioqDQoNCg0KDQpPbiBUaHUsIEphbiA5LCAyMDIwIGF0IDU6MDkgQU0gRmVybmFuZG8gR29u dCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPG1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20+PiB3 cm90ZToNCk9uIDgvMS8yMCAxMToxMSwgSk9SREkgUEFMRVQgTUFSVElORVogd3JvdGU6DQo+IEhp IENob25nZmVuZywNCj4NCj4NCj4NCj4gSW4gNDY0WExBVCwgdGhlIHdheSB5b3UgYWxsb2NhdGUg cG9ydHMgdG8gY3VzdG9tZXJzIGluIHRoZSBOQVQ2NCBpcw0KPiB0eXBpY2FsbHkgbXVjaCBtb3Jl IGVmZmljaWVudCB0aGFuIGluIHByZS1hbGxvY2F0aW9uIGFzIGRvbmUgY29tbW9ubHkgaW4NCj4g Q0dOIG9yIGV2ZW4gTUFQLg0KDQpIb3cgZG8geW91IG1pdGlnYXRlIHRoZSBwb3RlbnRpYWwgb2Yg RG9TIGlmIHlvdSBkb24ndCBwcmUtYWxsb2NhdGUgYQ0KcmFuZ2Ugb3IgbnVtYmVyIG9mIHBvcnRz IHRvIGVhY2ggY3VzdG9tZXI/DQoNClNhbWUgd2F5IHlvdSBkbyBpdCBpbiBOQVQ0NCwgeW91IHNl dCBhbiB1cHBlciBib3VuZHMgb24gbnVtYmVyIG9mIHNlc3Npb25zIGEgdXNlciBjYW4gZHluYW1p Y2FsbHkgY3JlYXRlLg0KDQoNCg0KVGhhbmtzLA0KLS0NCkZlcm5hbmRvIEdvbnQNClNJNiBOZXR3 b3Jrcw0KZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb208bWFpbHRvOmZnb250QHNpNm5ldHdv cmtzLmNvbT4NClBHUCBGaW5nZXJwcmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQg QUUyNSAwRDU1IDFENEUgNzQ5Mg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxt YWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQo= --_000_787AE7BB302AE849A7480A190F8B933031406805OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFs bCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ3JlZSB3aXRo IENhbWVyb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJFUSM0IGFuZCBSRVEjNSBmcm9tIFJGQzY4ODggc2hvdWxkIGJlIGZvbGxvd2Vk LiBNb3JlIGRldGFpbHMgYWJvdXQgdGhlc2UgbGltaXRzIGNhbiBhbHNvIGJlIGZvdW5kIGluDQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODUxMiNzZWN0aW9uLTIuOSI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg1MTIjc2VjdGlvbi0yLjk8L2E+Lg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRp c2FncmVlIHdpdGggSm9yZGkgd2hlbiBoZSBzYXlzIHRoYXQgTkFUNjQgaXMgc3BlY2lmaWMgY29t cGFyZWQgdG8gYW55IG90aGVyIENHTiBmbGF2b3Igd2l0aCByZWdhcmRzIHRvIHNoYXJlZCBhZGRy ZXNzZXMgdXNhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNo ZWVycywmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g djZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwv Yj4gQ2EgQnk8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgOSBqYW52aWVyIDIwMjAg MTU6MjI8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEZlcm5hbmRvIEdvbnQ8YnI+DQo8Yj5DYyZuYnNw Ozo8L2I+IHY2b3BzOyBKT1JESSBQQUxFVCBNQVJUSU5FWjxicj4NCjxiPk9iamV0Jm5ic3A7Ojwv Yj4gUmU6IFt2Nm9wc10gZHJhZnQtcGFsZXQtdjZvcHMtNDY0eGxhdC1vcHQtY2RuLWNhY2hlcyAq KkNhbGwgZm9yIEFkb3B0aW9uKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gOSwgMjAyMCBhdCA1OjA5IEFNIEZlcm5h bmRvIEdvbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20iPmZnb250 QHNpNm5ldHdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOC8xLzIwIDExOjExLCBKT1JESSBQ QUxFVCBNQVJUSU5FWiB3cm90ZTo8YnI+DQomZ3Q7IEhpIENob25nZmVuZyw8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIDQ2NFhMQVQsIHRoZSB3YXkg eW91IGFsbG9jYXRlIHBvcnRzIHRvIGN1c3RvbWVycyBpbiB0aGUgTkFUNjQgaXM8YnI+DQomZ3Q7 IHR5cGljYWxseSBtdWNoIG1vcmUgZWZmaWNpZW50IHRoYW4gaW4gcHJlLWFsbG9jYXRpb24gYXMg ZG9uZSBjb21tb25seSBpbjxicj4NCiZndDsgQ0dOIG9yIGV2ZW4gTUFQLjxicj4NCjxicj4NCkhv dyBkbyB5b3UgbWl0aWdhdGUgdGhlIHBvdGVudGlhbCBvZiBEb1MgaWYgeW91IGRvbid0IHByZS1h bGxvY2F0ZSBhPGJyPg0KcmFuZ2Ugb3IgbnVtYmVyIG9mIHBvcnRzIHRvIGVhY2ggY3VzdG9tZXI/ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TYW1lIHdheSB5b3UgZG8gaXQgaW4gTkFUNDQsIHlvdSBzZXQgYW4gdXBwZXIgYm91bmRz IG9uIG51bWJlciBvZiBzZXNzaW9ucyBhIHVzZXIgY2FuIGR5bmFtaWNhbGx5IGNyZWF0ZS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpUaGFua3MsPGJyPg0KLS0gPGJyPg0KRmVybmFuZG8gR29udDxicj4NClNJ NiBOZXR3b3Jrczxicj4NCmUtbWFpbDogPGEgaHJlZj0ibWFpbHRvOmZnb250QHNpNm5ldHdvcmtz LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZnb250QHNpNm5ldHdvcmtzLmNvbTwvYT48YnI+DQpQR1Ag RmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZCMSBFM0M0IEFFMjUgMEQ1NSAxRDRF IDc0OTI8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933031406805OPEXCAUBMA2corp_-- From nobody Thu Jan 9 07:14:20 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31712120019 for ; Thu, 9 Jan 2020 07:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 if883fh11MQY for ; Thu, 9 Jan 2020 07:14:13 -0800 (PST) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6984D1200FE for ; Thu, 9 Jan 2020 07:14:13 -0800 (PST) Received: from [192.168.1.135] (host-79-121-42-199.kabelnet.hu [79.121.42.199]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 009FE1IZ001359 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 9 Jan 2020 16:14:07 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-199.kabelnet.hu [79.121.42.199] claimed to be [192.168.1.135] To: v6ops@ietf.org References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> <787AE7BB302AE849A7480A190F8B933031406805@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Thu, 9 Jan 2020 16:13:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933031406805@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------E8E684E03A392420171A6CB8" Content-Language: hu X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.199; helo=[192.168.1.135]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 15:14:18 -0000 This is a multi-part message in MIME format. --------------E8E684E03A392420171A6CB8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 1/9/2020 3:54 PM keltezéssel, mohamed.boucadair@orange.com írta: > > Hi all, > > Agree with Cameron. > > REQ#4 and REQ#5 from RFC6888 should be followed. More details about > these limits can also be found in > https://tools.ietf.org/html/rfc8512#section-2.9. > > I disagree with Jordi when he says that NAT64 is specific compared to > any other CGN flavor with regards to shared addresses usage. > Our draft https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-04 states that 464XLAT, DS-Lite and NAT444 are all more efficient in IPv4 address sharing than MAP-T/E or Lw4o6: Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can therefore be much more efficient in terms of port allocation and thus public IP address saving. The price is the stateful operation in the service provider network, which allegedly does not scale up well. It should be noticed that in many cases, all those factors may depend on how it is actually implemented. Gábor > Cheers, > > Med > > *De :*v6ops [mailto:v6ops-bounces@ietf.org] *De la part de* Ca By > *Envoyé :* jeudi 9 janvier 2020 15:22 > *À :* Fernando Gont > *Cc :* v6ops; JORDI PALET MARTINEZ > *Objet :* Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call > for Adoption** > > On Thu, Jan 9, 2020 at 5:09 AM Fernando Gont > wrote: > > On 8/1/20 11:11, JORDI PALET MARTINEZ wrote: > > Hi Chongfeng, > > > > > > > > In 464XLAT, the way you allocate ports to customers in the NAT64 is > > typically much more efficient than in pre-allocation as done > commonly in > > CGN or even MAP. > > How do you mitigate the potential of DoS if you don't pre-allocate a > range or number of ports to each customer? > > Same way you do it in NAT44, you set an upper bounds on number of > sessions a user can dynamically create. > > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > 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 --------------E8E684E03A392420171A6CB8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

1/9/2020 3:54 PM keltezéssel, mohamed.boucadair@orange.com írta:

Hi all,

 

Agree with Cameron.

 

REQ#4 and REQ#5 from RFC6888 should be followed. More details about these limits can also be found in https://tools.ietf.org/html/rfc8512#section-2.9.

 

I disagree with Jordi when he says that NAT64 is specific compared to any other CGN flavor with regards to shared addresses usage.


Our draft https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-04 states that 464XLAT, DS-Lite and NAT444 are all more efficient in IPv4 address sharing than MAP-T/E or Lw4o6:

   Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can
   therefore be much more efficient in terms of port allocation and thus
   public IP address saving.  The price is the stateful operation in the
   service provider network, which allegedly does not scale up well.  It
   should be noticed that in many cases, all those factors may depend on
   how it is actually implemented.

Gábor



 

Cheers, 

Med

 

De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ca By
Envoyé : jeudi 9 janvier 2020 15:22
À : Fernando Gont
Cc : v6ops; JORDI PALET MARTINEZ
Objet : Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

 

 

 

On Thu, Jan 9, 2020 at 5:09 AM Fernando Gont <fgont@si6networks.com> wrote:

On 8/1/20 11:11, JORDI PALET MARTINEZ wrote:
> Hi Chongfeng,
>
>  
>
> In 464XLAT, the way you allocate ports to customers in the NAT64 is
> typically much more efficient than in pre-allocation as done commonly in
> CGN or even MAP.

How do you mitigate the potential of DoS if you don't pre-allocate a
range or number of ports to each customer?

 

Same way you do it in NAT44, you set an upper bounds on number of sessions a user can dynamically create. 

 

 


Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
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

--------------E8E684E03A392420171A6CB8-- From nobody Thu Jan 9 09:40:57 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1129A1200DB for ; Thu, 9 Jan 2020 09:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaXKOoiawi_d for ; Thu, 9 Jan 2020 09:40:54 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767321200B5 for ; Thu, 9 Jan 2020 09:40:54 -0800 (PST) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 993184E11A79; Thu, 9 Jan 2020 17:40:53 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 3456127CC8CC; Thu, 9 Jan 2020 18:40:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: otroan@employees.org In-Reply-To: Date: Thu, 9 Jan 2020 18:40:50 +0100 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <44E339CD-DB62-40C1-951B-E6C8132D13F1@employees.org> References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> <787AE7BB302AE849A7480A190F8B933031406805@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: =?utf-8?Q?Lencse_G=C3=A1bor?= X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 17:40:56 -0000 > Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can > therefore be much more efficient in terms of port allocation and = thus > public IP address saving. The price is the stateful operation in = the > service provider network, which allegedly does not scale up well. = It > should be noticed that in many cases, all those factors may depend = on > how it is actually implemented. >=20 Not allegedly. The two mechanism-types do have different scaling properties. The CGN type are pets (scale with sharding + HA mechanisms), the = stateless mechanisms behave like cattle. I.e. you just add more = instances. Cheers, Ole= From nobody Thu Jan 9 11:04:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897B912008A for ; Thu, 9 Jan 2020 11:04:02 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWEVF0fmkv8G for ; Thu, 9 Jan 2020 11:04:01 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2746E120108 for ; Thu, 9 Jan 2020 11:04:01 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id h8so8345462iob.2 for ; Thu, 09 Jan 2020 11:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ME5OIgD0JxN01ttifo1dQtdNJ/Acm08ZgpdjEdHK/oE=; b=P4K/W6Pi8oLHKCPC6zjABeMllMpamuLYs/GRFdB1nnE9f3KAo1k2fLydaaNMRKRUXI dKxYj0uFPAZrTgwkjAXKuR+i+PX2r4UOJ5VFpFKHcOHEr76NHh3nQh9UrOEsMSF+f0pc rMfMSi+ukJ/KNB09ej7Su+MgqAaBtv4+EsoDreyOWDCT37AVv0Ji9lT1hEWYhDYTjjgN i1kGBU25VvhsmXKWZ4sB/PkbBkfqrUdWZXaVaq6+oNGnhX4rluzNN0MiaFwYfMU4Nriy ihzNsNRfK4kCX0DCcWK1Y+Qb/i1KdwA1pphrh8qSz1eJW03UvhyNf130zTAsfdeIZqMb QQrQ== 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=ME5OIgD0JxN01ttifo1dQtdNJ/Acm08ZgpdjEdHK/oE=; b=BIRcWVBBmstA3E0g1VNvgMEtJHSanJRFznmgpZgCRhEA1m+y+nMB7jPvH/t4NKKuM/ D95y/gGqftu3OpnPhK2B1ZFos8qkR3lMU9kIonKKIkhskk1Doa8JpAnXOhcBXilVArk2 L2mh7mxpLvMi9/eTnVmf5Mkl3lE/yXJvDxT7XCWcb46S91/4WCnndwRkUU+koGHGfdk0 hwGG30W/cida3QdIlPbGXYC51a7nMw/0lM7HzcOcttinwDnGITnhqxnPE9o0z891NSdf 8wZiwSQBugXMfSxn4scY7mosoGu2Cr1pliAWyiy+0B+GXJV6fxd0DOrseiKH+r/CHYD0 Tx2A== X-Gm-Message-State: APjAAAVZLH5i7adE7R4NIasOxu65VFQDHKY+OIK4OlScZSnU3YfBCOsB A3WpwEk+188t8B9H+ZKFrKnGCsSxhNuQfxmDQz8atg== X-Google-Smtp-Source: APXvYqzzTIRd2OfYby8QPP1eOinTjraITuFzCkYAAGj1y/M6PI4yCDYs7XPbkWz3xOCvjhTbwCVbyFJDtRxCWDbYPPU= X-Received: by 2002:a02:b703:: with SMTP id g3mr10323486jam.101.1578596640454; Thu, 09 Jan 2020 11:04:00 -0800 (PST) MIME-Version: 1.0 References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> <787AE7BB302AE849A7480A190F8B933031406805@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <44E339CD-DB62-40C1-951B-E6C8132D13F1@employees.org> In-Reply-To: <44E339CD-DB62-40C1-951B-E6C8132D13F1@employees.org> From: Ca By Date: Thu, 9 Jan 2020 11:03:49 -0800 Message-ID: To: otroan@employees.org Cc: =?UTF-8?Q?Lencse_G=C3=A1bor?= , v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000ff7c9d059bb9ab43" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 19:04:03 -0000 --000000000000ff7c9d059bb9ab43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 9:41 AM wrote: > > Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can > > therefore be much more efficient in terms of port allocation and thu= s > > public IP address saving. The price is the stateful operation in th= e > > service provider network, which allegedly does not scale up well. I= t > > should be noticed that in many cases, all those factors may depend o= n > > how it is actually implemented. > > > > Not allegedly. > The two mechanism-types do have different scaling properties. > The CGN type are pets (scale with sharding + HA mechanisms), the stateles= s > mechanisms behave like cattle. I.e. you just add more instances. > > Cheers, > Ole eh, i don=E2=80=99t believe there is a meaningful scaling function differen= ce. I don=E2=80=99t know the details of how MAP works, the domains and dhcp depen= dencies always seemed like a Rube Goldberg machine, but for 464xlat, if you think of DNS64 being an anycast and / or PREF64 as anycast... you just add more to scale horizontally. Yes, each NAT64 needs a unique ipv4 pool, but it=E2= =80=99s not an artisanal craft. A stateful NAT44 / NAT64 can also scale beyond 65k sessions / ports per ipv4 using a full 5-tuple... so if we are talking about pushing ipv4 efficiency, this cannot be beat. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000ff7c9d059bb9ab43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 9, 2020 at 9:41 AM <otroan@employees.org> wrote:
>=C2=A0 =C2=A0 Stateful technologies, 464XLAT and DS-Li= te (and also NAT444) can
>=C2=A0 =C2=A0 therefore be much more efficient in terms of port allocat= ion and thus
>=C2=A0 =C2=A0 public IP address saving.=C2=A0 The price is the stateful= operation in the
>=C2=A0 =C2=A0 service provider network, which allegedly does not scale = up well.=C2=A0 It
>=C2=A0 =C2=A0 should be noticed that in many cases, all those factors m= ay depend on
>=C2=A0 =C2=A0 how it is actually implemented.
>

Not allegedly.
The two mechanism-types do have different scaling properties.
The CGN type are pets (scale with sharding + HA mechanisms), the stateless = mechanisms behave like cattle. I.e. you just add more instances.

Cheers,
Ole

eh, i don=E2= =80=99t believe there is a meaningful scaling function difference.=C2=A0 I = don=E2=80=99t know the details of how MAP works, the domains and dhcp depen= dencies always seemed like a Rube Goldberg machine, =C2=A0but for 464xlat, = if you think of DNS64 being an anycast and / or PREF64 as anycast... you ju= st add more to scale horizontally.=C2=A0 Yes, each NAT64 needs a unique ipv= 4 pool, but it=E2=80=99s not an artisanal craft.=C2=A0

A stateful NAT44 / NAT64 can also scale beyo= nd 65k sessions / ports per ipv4 using a full 5-tuple... so if we are talki= ng about pushing ipv4 efficiency, this cannot be beat.=C2=A0



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000ff7c9d059bb9ab43-- From nobody Thu Jan 9 11:22:36 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729AD12011F for ; Thu, 9 Jan 2020 11:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC1IfhPx2BWN for ; Thu, 9 Jan 2020 11:22:32 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF23120123 for ; Thu, 9 Jan 2020 11:22:32 -0800 (PST) Received: from [IPv6:2a01:79d:53aa:d30:d858:cb2e:9abb:2485] (unknown [IPv6:2a01:79d:53aa:d30:d858:cb2e:9abb:2485]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 4E5784E12701; Thu, 9 Jan 2020 19:22:31 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-D2799B3F-812F-4DB9-96E2-0987AAFFA1FB Content-Transfer-Encoding: 7bit From: Ole Troan Mime-Version: 1.0 (1.0) Date: Thu, 9 Jan 2020 20:22:29 +0100 Message-Id: References: Cc: =?utf-8?Q?Lencse_G=C3=A1bor?= , v6ops@ietf.org In-Reply-To: To: Ca By X-Mailer: iPhone Mail (17D5026c) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 19:22:34 -0000 --Apple-Mail-D2799B3F-812F-4DB9-96E2-0987AAFFA1FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 9 Jan 2020, at 20:04, Ca By wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Thu, Jan 9, 2020 at 9:41 AM wrote: >> > Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can >> > therefore be much more efficient in terms of port allocation and thu= s >> > public IP address saving. The price is the stateful operation in th= e >> > service provider network, which allegedly does not scale up well. I= t >> > should be noticed that in many cases, all those factors may depend o= n >> > how it is actually implemented. >> >=20 >>=20 >> Not allegedly. >> The two mechanism-types do have different scaling properties. >> The CGN type are pets (scale with sharding + HA mechanisms), the stateles= s mechanisms behave like cattle. I.e. you just add more instances. >>=20 >> Cheers, >> Ole >=20 > eh, i don=E2=80=99t believe there is a meaningful scaling function differe= nce. I don=E2=80=99t know the details of how MAP works, the domains and dhc= p dependencies always seemed like a Rube Goldberg machine, but for 464xlat,= if you think of DNS64 being an anycast and / or PREF64 as anycast... you ju= st add more to scale horizontally. Yes, each NAT64 needs a unique ipv4 pool= , but it=E2=80=99s not an artisanal craft.=20 >=20 > A stateful NAT44 / NAT64 can also scale beyond 65k sessions / ports per ip= v4 using a full 5-tuple... so if we are talking about pushing ipv4 efficienc= y, this cannot be beat.=20 All solutions have stateful NATs. It=E2=80=99s just a question if you have o= ne, two or three (in this case one is stateless though). In a MAP solution t= he CPE NAT can also operate in endpoint dependent mode.=20 It will not be able to utilize the IPv4 as efficiently as the CGN solutions.= =20 Where the CGN solutions are hard to scale has to do with robustness. Avoidin= g a single point of failure requires HA solutions (session synchronization) a= nd sharding of the state space. Whatever you think, that=E2=80=99s a lot har= der to do than a stateless solution. I have written code for both.=20 Cheers=20 Ole >=20 >=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-D2799B3F-812F-4DB9-96E2-0987AAFFA1FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 9 Jan 2020, at 20:04, Ca By <cb.list6@g= mail.com> wrote:

=EF=BB=BF


On Thu, Jan 9, 2020 at 9:41 AM <otroan@employees.org> wrote:
>    Stateful technologies, 46= 4XLAT and DS-Lite (and also NAT444) can
>    therefore be much more efficient in terms of port allocati= on and thus
>    public IP address saving.  The price is the stateful o= peration in the
>    service provider network, which allegedly does not scale u= p well.  It
>    should be noticed that in many cases, all those factors ma= y depend on
>    how it is actually implemented.
>

Not allegedly.
The two mechanism-types do have different scaling properties.
The CGN type are pets (scale with sharding + HA mechanisms), the stateless m= echanisms behave like cattle. I.e. you just add more instances.

Cheers,
Ole

eh, i don=E2=80= =99t believe there is a meaningful scaling function difference.  I don=E2= =80=99t know the details of how MAP works, the domains and dhcp dependencies= always seemed like a Rube Goldberg machine,  but for 464xlat, if you t= hink of DNS64 being an anycast and / or PREF64 as anycast... you just add mo= re to scale horizontally.  Yes, each NAT64 needs a unique ipv4 pool, bu= t it=E2=80=99s not an artisanal craft. 

A stateful NAT44 / NAT64 can also scale beyond 65k sessi= ons / ports per ipv4 using a full 5-tuple... so if we are talking about push= ing ipv4 efficiency, this cannot be beat. 

All solutions have stateful NATs. It=E2=80=99s just a= question if you have one, two or three (in this case one is stateless thoug= h).  In a MAP solution the CPE NAT can also operate in endpoint depende= nt mode. 

It will not be able to utilize the IPv4 as= efficiently as the CGN solutions. 

Where the C= GN solutions are hard to scale has to do with robustness. Avoiding a single p= oint of failure requires HA solutions (session synchronization) and sharding= of the state space. Whatever you think, that=E2=80=99s a lot harder to do t= han a stateless solution. I have written code for both. 

=
Cheers 
Ole


=



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
= --Apple-Mail-D2799B3F-812F-4DB9-96E2-0987AAFFA1FB-- From nobody Thu Jan 9 12:06:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823F1207FB for ; Thu, 9 Jan 2020 12:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBs7LrfZ-zD4 for ; Thu, 9 Jan 2020 12:06:33 -0800 (PST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 3072D120047 for ; Thu, 9 Jan 2020 12:06:33 -0800 (PST) Received: by mail-wr1-f43.google.com with SMTP id j42so8704000wrj.12 for ; Thu, 09 Jan 2020 12:06:33 -0800 (PST) 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=asA2LdLtS3hDfmQy07qapvt9+aU0J4Mgl8WhEhiC3jA=; b=IFnIMNF6JmGEqJQWmom5qeEsZtfBr5+pwuGJvYF+FzEJF7RHHn1gduEcK5HaI+qPwS /PyNHwRk4zUCOBTn6Crda0aupYxdKao6xm/5ynrWEWGVHnGFU8OccCXksmLdMpB/jCdL 4COk/gzNX7Kx4JMIk8H6qrRNfSqDqWJrRhTUQbYp5fD9Bm5Z/DeRWO0jPhEnfOj8NjUS uBDoyCX0Oueai7yiqdl8SqKBw5mOFWBCpoMWnnsXir2wYrZMkJ5z7hFlAhTFBff+6boq r6SgJoRwU+5mxoqkHEpaJ2Fr2MU8wD3naYPaM7L4/F/eEuCCYXiuPmxHKunA0Kw1oDQ+ e1hQ== X-Gm-Message-State: APjAAAUYo4rsbkipInZc2zgWya6KuRoqXeJCDeE6uyO42Kk0L2B/QELw yeD1ql69fRrZyuXTWtenv4QzA24ImiqgGbZZoZJjdxH3 X-Google-Smtp-Source: APXvYqzoXt7R5irms54VdJAu6iTvm28YsfUY99kgQFnoM79cGG1qqnrShkbK2ZD+4KXTZs1rBJYgl46S9maLUXaeR/k= X-Received: by 2002:a05:6000:149:: with SMTP id r9mr12622297wrx.147.1578600391487; Thu, 09 Jan 2020 12:06:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Nygren Date: Thu, 9 Jan 2020 15:06:19 -0500 Message-ID: To: Ron Bonica Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000093b8cf059bba8ba7" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 20:06:35 -0000 --00000000000093b8cf059bba8ba7 Content-Type: text/plain; charset="UTF-8" While I'm very supportive of 464xlat as a transition technology, and while I was very optimistic about this approach at first (and may even have suggested some of the proposals included in the draft), on subsequent reflections I continue to have significant concerns about the fragility of this approach. Implementing this in a way that works well with a generic CDN (ie, one not managed by the operator) will require a significant amount of state and complexity in CPE devices. It only will take one or two bad CPE implementations to result in CDNs being forced to switch content to IPv4-only to address user complaints, which would undo what this is trying to achieve. In particular, the fundamental issue is that the RR sets returned for A and AAAA records from many CDNs are not 1:1 and also change frequently during the lifetime of connections. As such, I continue to have serious reservations about trying to move this forwards as anything other than Experimental. If we do move forward, the DNS-based approach needs to be comfortable moving lots more state into the CPE than I recall seeing in the last version of this that I read. In particular, if DNS sees changes to {A,AAAA} pairings, it is critical to only apply those to future connections and not break existing connections, meaning that CPEs need to keep these rewrite rules associated with stateful connection tracking. With the use-case for this being IPv4-only devices, a question may be whether it is better to focus on trying to get those devices to implement native IPv6 support while handling them via a CLAT in the CPE for the time-being. Alternately, lw4o6 addresses the "offload stateful NAT off of the CPE" in a much less fragile way. Erik On Wed, Dec 11, 2019 at 2:25 PM Ron Bonica wrote: > Folks, > > > > Each week between now and IETF 107, we will review and discuss one draft > with an eye towards progressing it. > > > > This week, please review and comment on > draft-palet-v6ops-464xlat-opt-cdn-caches. > > > > When reviewing this draft, please indicate whether you think that V6OPS > should adopt it a s a work item. > > > > Fred and Ron > > > > Juniper Business Use Only > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000093b8cf059bba8ba7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I'm very supportive of 464xlat as a transition technol= ogy, and while I was very optimistic about this approach
at first (and = may even have suggested some of the proposals included in the draft), on su= bsequent
reflections I continue to have significant concerns about the fragi= lity of this approach.
Implementing this in a way that works well with a= generic CDN=C2=A0 (ie, one not managed
by the operator) will require a sign= ificant amount of state and complexity in CPE devices.
It only will take one= or two bad CPE implementations to result in CDNs being forced to switch
con= tent to IPv4-only to address user complaints, which would undo what this
is trying to achieve.

In particular, the fundamental issue is that the= RR sets returned for A and AAAA records
from many CDNs are not 1:1 and also= change frequently during the lifetime of connections.

As such, I c= ontinue to have serious reservations about trying to move this forwards
as a= nything other than Experimental.=C2=A0 If we do move forward, the DNS-based= approach
needs to be comfortable moving lots more state into the CPE than I= recall seeing
in the last version of this that I read.=C2=A0=C2=A0 In parti= cular, if DNS sees changes to {A,AAAA}
pairings, it is critical to only= apply those to future connections and not break existing
connections, = meaning that CPEs need to keep these rewrite rules associated
with stateful = connection tracking.

With the use-case for this being IPv4-only de= vices, a question may be whether
it is better to focus on tryin= g to get those devices to implement native IPv6 support
while h= andling them via a CLAT in the CPE for the time-being.=C2=A0 Alternately, l= w4o6
addresses the "offload stateful NAT off of the CPE&qu= ot; in a much less fragile way.

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






On Wed, Dec 11, 2019 at 2:25 PM Ron Bonica <rbonica= =3D40juniper.net@dmarc.ietf= .org> wrote:

Folks,

=C2=A0

Each week between now and IETF 107, we will review and discuss one draft= with an eye towards progressing it.

=C2=A0

This week, please review and comment on draft-palet-= v6ops-464xlat-opt-cdn-caches.

=C2=A0

When reviewing this draft, please indicate whether y= ou think that V6OPS should adopt it a s a work item.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fred and Ron

=C2=A0


Juniper Business Use Only

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000093b8cf059bba8ba7-- From nobody Thu Jan 9 12:34:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7F1202A0 for ; Thu, 9 Jan 2020 12:34:15 -0800 (PST) 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, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FRkD_SqnbQH for ; Thu, 9 Jan 2020 12:34:12 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FC8120047 for ; Thu, 9 Jan 2020 12:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1578602049; x=1579206849; 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=E047NBOxtVGP8GmAIiIVUyLUbj8YWxyBeL CcgS0dWbI=; b=VUHWLPkMAcjuW0hu8qedgfPgl1HpD3XRQRp8QsELQLg3DQzwsH rnHN+vs2gBMjS9kNzijrXirnT3Y+m590aYeZJsPgyuhI5lYW7y8Jtvmr6WUnPtn/ CjooZtoUGXPAWSkXh1KE54pLgNX0+3Rqco5GUgwMPqwRRtln2UwyxXTyw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 09 Jan 2020 21:34:09 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 09 Jan 2020 21:34:08 +0100 Received: from [10.192.0.137] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000021910.msg for ; Thu, 09 Jan 2020 21:34:06 +0100 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.192.0.137] X-MDArrival-Date: Thu, 09 Jan 2020 21:34:06 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1277e0d723=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Thu, 09 Jan 2020 21:33:51 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <24B0BCD2-A8E8-4188-9C74-4518E3ED57B0@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3661450439_1707274075" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2020 20:34:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3661450439_1707274075 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Ole, =20 Even if I could (partially) agree with your view regarding the single-point= -of-failure, at the end the problem is that every network is a different an= imal. =20 There are CapEx and OpEx impacts that may be different when you need to del= iver IPv6-only for both a cellular and a broadband network (in the same ope= rator). And having a single transition is very relevant. =20 We are more often in a world were subscribers have a hybrid/multihomed CE, = with (for example) GPON and a backup link via 3/4/5G. Again, because in cel= lular the only choice is 464XLAT, it becomes much easier (and cheaper) to u= se also 464XLAT in the main broadband link. =20 Regards, Jordi @jordipalet =20 =20 =20 El 9/1/20 20:22, "v6ops en nombre de Ole Troan" escribi=C3=B3: =20 =20 On 9 Jan 2020, at 20:04, Ca By wrote: =EF=BB=BF =20 =20 On Thu, Jan 9, 2020 at 9:41 AM wrote: > Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can > therefore be much more efficient in terms of port allocation and thus > public IP address saving. The price is the stateful operation in the > service provider network, which allegedly does not scale up well. It > should be noticed that in many cases, all those factors may depend on > how it is actually implemented. >=20 Not allegedly. The two mechanism-types do have different scaling properties. The CGN type are pets (scale with sharding + HA mechanisms), the stateless = mechanisms behave like cattle. I.e. you just add more instances. Cheers, Ole =20 eh, i don=E2=80=99t believe there is a meaningful scaling function differen= ce. I don=E2=80=99t know the details of how MAP works, the domains and dhc= p dependencies always seemed like a Rube Goldberg machine, but for 464xlat= , if you think of DNS64 being an anycast and / or PREF64 as anycast... you = just add more to scale horizontally. Yes, each NAT64 needs a unique ipv4 p= ool, but it=E2=80=99s not an artisanal craft.=20 =20 A stateful NAT44 / NAT64 can also scale beyond 65k sessions / ports per ipv= 4 using a full 5-tuple... so if we are talking about pushing ipv4 efficienc= y, this cannot be beat.=20 =20 All solutions have stateful NATs. It=E2=80=99s just a question if you have = one, two or three (in this case one is stateless though). In a MAP solutio= n the CPE NAT can also operate in endpoint dependent mode.=20 =20 It will not be able to utilize the IPv4 as efficiently as the CGN solutions= .=20 =20 Where the CGN solutions are hard to scale has to do with robustness. Avoidi= ng a single point of failure requires HA solutions (session synchronization= ) and sharding of the state space. Whatever you think, that=E2=80=99s a lot= harder to do than a stateless solution. I have written code for both.=20 =20 Cheers=20 Ole =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3661450439_1707274075 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Ole,

 

Even if I could (partial= ly) agree with your view regarding the single-point-of-failure, at the end = the problem is that every network is a different animal.<= /p>

 

There = are CapEx and OpEx impacts that may be different when you need to deliver I= Pv6-only for both a cellular and a broadband network (in the same operator)= . And having a single transition is very relevant.

 

We are more = often in a world were subscribers have a hybrid/multihomed CE, with (for ex= ample) GPON and a backup link via 3/4/5G. Again, because in cellular the on= ly choice is 464XLAT, it becomes much easier (and cheaper) to use also 464X= LAT in the main broadband link.

<= span lang=3DEN-US style=3D'font-size:12.0pt;mso-fareast-language:EN-US'> 

Regards,

Jordi<= /p>

@jordipale= t

=  

 <= /o:p>

 

El 9/1/20 20:22, "v6op= s en nombre de Ole Troan" <v6ops-bounces@ietf.org en nombre de otroan@employees.org> escribi=C3=B3:

 <= /p>

 =


=

On 9 Jan 2020, at 20:04, Ca By <c= b.list6@gmail.com> wrote:

=EF=BB=BF

 

 

On Thu, Jan 9, 2020 at 9:41 AM &= lt;otroan@employees.org> wro= te:

>    Statef= ul technologies, 464XLAT and DS-Lite (and also NAT444) can
>  &n= bsp; therefore be much more efficient in terms of port allocation and thus<= br>>    public IP address saving.  The price is the stateful operation in the
>    service p= rovider network, which allegedly does not scale up well.  It
>&n= bsp;   should be noticed that in many cases, all those factors may dep= end on
>    how it is actually implemented.
>
Not allegedly.
The two mechanism-types do have different scaling proper= ties.
The CGN type are pets (scale with sharding + HA mechanisms), the s= tateless mechanisms behave like cattle. I.e. you just add more instances.
Cheers,
Ole

 

eh, i don=E2=80=99t believe there is a m= eaningful scaling function difference.  I don=E2=80=99t know the detai= ls of how MAP works, the domains and dhcp dependencies always seemed like a= Rube Goldberg machine,  but for 464xlat, if you think of DNS64 being = an anycast and / or PREF64 as anycast... you just add more to scale horizon= tally.  Yes, each NAT64 needs a unique ipv4 pool, but it=E2=80=99s not= an artisanal craft. 

 

A stateful NAT44 / NAT64 can also scale b= eyond 65k sessions / ports per ipv4 using a full 5-tuple... so if we are ta= lking about pushing ipv4 efficiency, this cannot be beat. <= /p>

 

All solutions have stateful NATs. It=E2=80=99s just= a question if you have one, two or three (in this case one is stateless th= ough).  In a MAP solution the CPE NAT can also operate in endpoint dep= endent mode. 

 

It will not be able to utilize the IPv4 as efficiently = as the CGN solutions. 

 

Where the CGN solutions are hard to scal= e has to do with robustness. Avoiding a single point of failure requires HA= solutions (session synchronization) and sharding of the state space. Whate= ver you think, that=E2=80=99s a lot harder to do than a stateless solution.= I have written code for both. 

 

Cheers 

Ole

=

 

 


 

 


______________= _________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.o= rg/mailman/listinfo/v6ops

=

= _______________________________________________ v6ops mailing list v6ops@ie= tf.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_3661450439_1707274075-- From nobody Fri Jan 10 00:35:27 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C370C1207FE for ; Fri, 10 Jan 2020 00:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.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 XEK2s8fO7z03 for ; Fri, 10 Jan 2020 00:35:23 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67C1207FD for ; Fri, 10 Jan 2020 00:35:23 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 00A8ZK6a015598 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 00:35:20 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 00A8ZK6a015598 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1578645320; bh=NLz/UUyFKyHKYB+/pAg627UTw1/W0UJwzj1OqFnd5m8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=I/uHYHFK2XzTkPG6iVB1rUZpb2BuEsdLEyFr2BuNTW0qoF+oz/h7tE12sq+Z8wNUx 8F8/PjOK+LRuVfQX1wUKuqvThxi9eAWZ50lhMwoGxfAuttXIb2+7C9lwL4ZB/Q4wQL A4AohhNBheZ2AZavl8lNQZ9Gdxpin4lyGKDCEbjg= From: Owen DeLong Message-Id: <750A62E1-D0D5-4079-95EB-0B48DF8FC03C@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E6D011CD-5EDE-404B-B6EE-F24A3795CDB7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 10 Jan 2020 00:35:20 -0800 In-Reply-To: Cc: "v6ops@ietf.org" To: Ron Bonica References: X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Jan 2020 00:35:20 -0800 (PST) Archived-At: Subject: Re: [v6ops] draft-gont-v6ops-slaac-renum **Call for adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jan 2020 08:35:26 -0000 --Apple-Mail=_E6D011CD-5EDE-404B-B6EE-F24A3795CDB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support working group adoption of this draft. I have already commented on it previously and I believe my comments have = been properly addressed by the authors. Owen > On Jan 4, 2020, at 14:56 , Ron Bonica = wrote: >=20 > Folks, > =20 > Each week between now and IETF 107, we will review and discuss one = draft with an eye towards progressing it. > =20 > This week, please review and comment on draft-gont-v6ops-slaac-renum. > =20 > When reviewing this draft, please indicate whether you think that = V6OPS should adopt it a s a work item. > =20 > Fred and Ron > =20 >=20 > Juniper Business Use Only > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_E6D011CD-5EDE-404B-B6EE-F24A3795CDB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = support working group adoption of this draft.

I have already commented on it = previously and I believe my comments have been properly addressed by the = authors.

Owen


On Jan = 4, 2020, at 14:56 , Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> = wrote:

Folks,
 
Each week = between now and IETF 107, we will review and discuss one draft with an = eye towards progressing it.
 
This week, please review and comment on = draft-gont-v6ops-slaac-renum.
 
When reviewing this draft, please = indicate whether you think that V6OPS should adopt it a s a work = item.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;      Fred and Ron
 

Juniper Business Use Only
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_E6D011CD-5EDE-404B-B6EE-F24A3795CDB7-- From nobody Fri Jan 10 08:41:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C7B12025D for ; Fri, 10 Jan 2020 08:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz4Du-iW8Km1 for ; Fri, 10 Jan 2020 08:41:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6427512091A for ; Fri, 10 Jan 2020 08:41:37 -0800 (PST) Received: from [192.168.0.3] (unknown [181.44.129.9]) (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 A044A86AFC; Fri, 10 Jan 2020 17:41:31 +0100 (CET) To: Ca By Cc: JORDI PALET MARTINEZ , v6ops References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> From: Fernando Gont Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 9 Jan 2020 11:29:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:41:39 -0000 On 9/1/20 11:22, Ca By wrote: > > > On Thu, Jan 9, 2020 at 5:09 AM Fernando Gont > wrote: > > On 8/1/20 11:11, JORDI PALET MARTINEZ wrote: > > Hi Chongfeng, > > > >   > > > > In 464XLAT, the way you allocate ports to customers in the NAT64 is > > typically much more efficient than in pre-allocation as done > commonly in > > CGN or even MAP. > > How do you mitigate the potential of DoS if you don't pre-allocate a > range or number of ports to each customer? > > > Same way you do it in NAT44, you set an upper bounds on number of > sessions a user can dynamically create. That's the point. WHy would efficiency be different, then? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 10 09:17:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9CD120A87 for ; Fri, 10 Jan 2020 09:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWLzmCBFmq7C for ; Fri, 10 Jan 2020 09:16:58 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CAF1209E1 for ; Fri, 10 Jan 2020 09:16:58 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id x1so2859865iop.7 for ; Fri, 10 Jan 2020 09:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qYC/UCjRx43Hyh6WFbAP9hP5wD7jeWiQFIoQNRv09XA=; b=ms9oySj6fB5LEjFObFUSEnURMpbhOfqsFkGCbYhWtjup8ixYD5pQurgpOLjGcoYr/0 VRSnD8ChNSAFb//FmElC879FK25/vjD19PmPY8gyVece4hlETXHoDuCGcxOc5pG7OkVM 4qkW4djSo/UV6PaG40XsFxr56QWS17LeSt2mtR0I6jLVVK541w3tFmTz3r9fTG4LQMJ/ xYmiMmj01/mpTLOm3LSPIgIyg/Cfr1qUlF6+olZI7eOkMKaDdQvWCvNSXMEzh01SO7Z+ /oW7mykSKD7pM79FDGSICRD0cMXv+Uy5RfeO6FTGzn+DTG020EuUP/BFxAHd3k9XxYtZ 2uXg== 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=qYC/UCjRx43Hyh6WFbAP9hP5wD7jeWiQFIoQNRv09XA=; b=hrp+1372ONCpHWnZtUMHdGHA1GpofTPAhIYIoxKPVwO8Zowq+nuXE79O2kJbDup6Gw bs1iDHnpxSOlr5W52t/vhZAxopFQRu804qOw6JdXFyfna4wcspKoxXr0OSoC080q1zd9 BlOf4YDf11cXt9Si4o63LRqgeUYnmHBxaqlinI+ugtPQiudpXc/Y98SrvlNl+4VvqY60 131+NTdIAFtoQ7HOnxNFN7KXinigExHC1/FIMpeWzfNzPU29yLaHHR2quQ7qJU1X0Sm2 flEqpuhXqh2TOA5PlWZ/PvUkmVR8i+UR8vEuxYH/7qmducTXUY1YqPeHqhgWJJo5erv1 sltw== X-Gm-Message-State: APjAAAUNeNFiTXEHA5qQHsSKw2/RfOaR1BmZCFuVOVCkJHnjYxozVcD7 bAMKy19hNb0oi5FKLw25dvC7XdvIBG0QeRqW00YJDg== X-Google-Smtp-Source: APXvYqz/f/zQEnEQrSY+Girytef5sMvfEQ7mJOKmpTlfJL6EhqxL+m7wXWDmhzuephHRqyTAtAmYtT0CZ8QVCP5cSjM= X-Received: by 2002:a6b:a0a:: with SMTP id z10mr3194884ioi.190.1578676617886; Fri, 10 Jan 2020 09:16:57 -0800 (PST) MIME-Version: 1.0 References: <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es> <740e446e-a7f1-1b35-764d-98b26644fa01@si6networks.com> In-Reply-To: From: Ca By Date: Fri, 10 Jan 2020 09:16:46 -0800 Message-ID: To: Fernando Gont Cc: JORDI PALET MARTINEZ , v6ops Content-Type: multipart/alternative; boundary="000000000000064313059bcc4b14" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jan 2020 17:17:00 -0000 --000000000000064313059bcc4b14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 10, 2020 at 8:41 AM Fernando Gont wrote= : > On 9/1/20 11:22, Ca By wrote: > > > > > > On Thu, Jan 9, 2020 at 5:09 AM Fernando Gont > > wrote: > > > > On 8/1/20 11:11, JORDI PALET MARTINEZ wrote: > > > Hi Chongfeng, > > > > > > > > > > > > In 464XLAT, the way you allocate ports to customers in the NAT64 = is > > > typically much more efficient than in pre-allocation as done > > commonly in > > > CGN or even MAP. > > > > How do you mitigate the potential of DoS if you don't pre-allocate = a > > range or number of ports to each customer? > > > > > > Same way you do it in NAT44, you set an upper bounds on number of > > sessions a user can dynamically create. > > That's the point. WHy would efficiency be different, then? > I can limit each subscriber to some number of dynamic ports. I can use 1 scarce public ipv4 to support, let=E2=80=99s say, 1,000 subscri= ber giving each sub 3,000 ports. In the worst case, this is 3,000,000 ports that can be demanded. Because of 5 tuple overloading of a single ip in a NAT pool, it not a technical challenge This is an efficiency of public ipv4 use that can only be achieved with a centralized stateful NAT. The above scenario is an extreme, but it is an example of maximum efficiency. > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --000000000000064313059bcc4b14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 10, 2020 at 8:41 AM Fernando Gont <fgont@si6networks.com> wrote:
<= /div>
On 9/1/20 11:22, Ca By wrote:
>
>
> On Thu, Jan 9, 2020 at 5:09 AM Fernando Gont <fgont@si6networks.com
> <mailto:= fgont@si6networks.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 8/1/20 11:11, JORDI PALET MARTINEZ wrote:
>=C2=A0 =C2=A0 =C2=A0> Hi Chongfeng,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> =C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> In 464XLAT, the way you allocate ports to cust= omers in the NAT64 is
>=C2=A0 =C2=A0 =C2=A0> typically much more efficient than in pre-allo= cation as done
>=C2=A0 =C2=A0 =C2=A0commonly in
>=C2=A0 =C2=A0 =C2=A0> CGN or even MAP.
>
>=C2=A0 =C2=A0 =C2=A0How do you mitigate the potential of DoS if you don= 't pre-allocate a
>=C2=A0 =C2=A0 =C2=A0range or number of ports to each customer?
>
>
> Same way you do it in NAT44, you set an upper bounds on number of
> sessions a user can dynamically create.

That's the point. WHy would efficiency be different, then?

I can limit each= subscriber to some number of dynamic ports.=C2=A0
<= br>
I can use 1 scarce public ipv4 to support, let= =E2=80=99s say, 1,000 subscriber giving each sub 3,000 ports. In the worst = case, this is 3,000,000 ports that can be demanded.=C2=A0

Because of 5 tuple overloading of a singl= e ip in a NAT pool, it not a technical challenge=C2=A0
=C2=A0
This is an efficiency of public ipv4 use t= hat can only be achieved with a centralized stateful NAT.=C2=A0

The above scenario is an extreme, b= ut it is an example of maximum efficiency.=C2=A0

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--000000000000064313059bcc4b14-- From nobody Sun Jan 12 15:18:25 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27523120074 for ; Sun, 12 Jan 2020 15:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=lnIfTfOX; dkim=pass (1024-bit key) header.d=juniper.net header.b=aC4eOvTr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNDuA_hVWSIg for ; Sun, 12 Jan 2020 15:18:22 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4431E120045 for ; Sun, 12 Jan 2020 15:18:22 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00CNGx2L023697 for ; Sun, 12 Jan 2020 15:18:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=3UZdW7l7N4Ur9F8Whk9E4jv9anCsoZxXx2CIYAcklAs=; b=lnIfTfOXrC/Eof6Hgzf4Y/DBe5ihcA8wjPg80Sx3S7nXNSO8Yvs4r1oe2fIzF91aRkdR sKgZ7IMjjYWt35giY0QH03hsRDyCx5TDMLf7mn+/n1M3MXO8h0zB7scSYA3W+q6UswX7 yDhk5yWh3aeVGurM+dPuXcDMoO5nZNRagCHsfNi/JP3nMvhzTOeM1zAFKFkgWg4ZNpFg Maya6VzxNgdL3Ok1NjA3aMBp1W5amIaO2OSmtjeP4mfBAYTjM/5XvOVUvkp2zR5o5kW2 xNWkaGuqV5G0lmxKsMKGwdSSqGq7fKh0dNsHZE4MyPpn2XV3XUECX41tzZoJOhQwjAUh rQ== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2056.outbound.protection.outlook.com [104.47.36.56]) by mx0a-00273201.pphosted.com with ESMTP id 2xfd739p8k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 12 Jan 2020 15:18:21 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J/uFM4/dwwnEv3OacMosf+F1HY5CPbsx7ivgseh9FjY9mZ3QnlozhQwYXcS83Wg52dCQnsj/3/457EwY04yTEuKpaUP76GkJY2sI1D0jZC8HnL9Ix3WkGxSaTiu8TxREvnnPpONM9uOHzYgtf/eXhlO/48fQs8DizZ1H1an+gmD4SMnQHJF6L3KxTpOFZgHMR6Uz/2+LPSlx0YThEpmdk/vXLQwRBBYsX2jLIA0lHS3Xu+gaBk9iRGAvy4M6f1QPWTQzFu92w8DeulNH3IOivFE2czFPWYXHNaJJg3V98M7iXTY3xd7tw/OWkTqh4uvn3jZOn6yu8IyeymplJFX6JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3UZdW7l7N4Ur9F8Whk9E4jv9anCsoZxXx2CIYAcklAs=; b=YO159roJFHEIahe6/COtjAw2AT3p5HwdZaNEqJmYyJLuSs2WkOHlJg04thd0KA1/ZGRmHJHc7wMlxEkrpPaI0NL7o73HM1+cUbRJlWom7s9a5wC7LHn7Rerx6z5FTiREbNSO6/VhR7HDkSyAvPfyVPaxUAPZipxlMFbc/hoXAqBZEacAfM31IE9Y2NKAx/0wW0xthVUw9cO3t7AvA36kpzqzb/6hLNXYjJYtWbA7QI9uyGWjQMpZB26IsOOe5ndwxD4wegzUIaQh4OGrzoHTmOeZexd+lDivxvXveD42V84nDiqAXw7hLIHS9DlcMcFqFPBZX57FjhP4pgRubD7nhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3UZdW7l7N4Ur9F8Whk9E4jv9anCsoZxXx2CIYAcklAs=; b=aC4eOvTrGBP/Gb2sJ0gr+zJ+ajOajSHZlYTF6qOs97gpw4+KHmI6wl6j54c9mHhIG9UUN2E/WZfPAkDdU9mLlmlshe4D2oDDKAG0xLsdcp+rSKqAqvOQ+8LvklIN0IYkmDkk/IwOIUvNcE/JwcPNfU5ktUt9KkU1dxR34VMBAF8= Received: from BN7PR05MB3938.namprd05.prod.outlook.com (52.132.216.30) by BN7PR05MB5732.namprd05.prod.outlook.com (20.176.28.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.12; Sun, 12 Jan 2020 23:18:19 +0000 Received: from BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864]) by BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864%5]) with mapi id 15.20.2644.015; Sun, 12 Jan 2020 23:18:19 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-gont-v6ops-cpe-slaac-renum **Call for Adoption** Thread-Index: AdXJnoKfEjg7tAscR/uOy377VLjhYQ== Content-Class: Date: Sun, 12 Jan 2020 23:18:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-01-12T23:18:15.2477574Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=bfa70aec-cf2d-4ceb-9530-b71ae57ca72d; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.3.2.8 dlp-reaction: no-action x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fe7391c9-e73e-43c5-b242-08d797b5b626 x-ms-traffictypediagnostic: BN7PR05MB5732: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2887; x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(136003)(376002)(346002)(396003)(366004)(189003)(199004)(7696005)(186003)(6916009)(478600001)(66446008)(8936002)(6506007)(76116006)(66556008)(64756008)(66476007)(55016002)(66946007)(81156014)(81166006)(52536014)(8676002)(26005)(316002)(5660300002)(9686003)(86362001)(2906002)(33656002)(4744005)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB5732; H:BN7PR05MB3938.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YIp6FsUL/MCGvAgBbHMCJDn48GSt8qquC8QwAj5lG2MIdst2vzqMuVyUqaZyPmng9gORDEvuaaQ61m16aF7ki1yvqoBw7gmyodD/JMHu1RYwFbr3afAlgmwen/sg7siInop95nBf/gczDA1OBHQABJvV5am5tYHvaAnv59Vtss85zH8sumTXHJpI2P7qqEqXviN1W21lUPXXAAWlPR0cMJvJQW258lrEh9EWNGI1IKiwfvLJj5eLJlrCnNtzVULui3pCuo9oQ9ENmZfN8yw0H4hN+GKPm9+HmHiprHvs++c3THAg4jDb0p4i4VGcYj6vvbQKHJRKDSQVa1T4cAdBWVE1lfoQO2dPgdMpRvPge4GYolmgKM/AsXuRYF5kyOGPi6wHlvi67z2sUd7DM6McqkFkGC1kWTroZqYj+6z0H/1a1A71n9fueyU4vXjyyOtm x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR05MB3938CECFE3021577A57783D2AE3A0BN7PR05MB3938namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: fe7391c9-e73e-43c5-b242-08d797b5b626 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2020 23:18:19.5209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mI8l0v34q6D8WJieFyfHIY+exL0FYikoYVxzoocWiGXoY790ekjmLzcFVGfywQTN7oPzWgU2T+K7XTlnfrXR5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB5732 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-12_10:2020-01-10, 2020-01-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 spamscore=0 phishscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 clxscore=1015 suspectscore=0 malwarescore=0 mlxlogscore=730 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001120220 Archived-At: Subject: [v6ops] draft-gont-v6ops-cpe-slaac-renum **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2020 23:18:24 -0000 --_000_BN7PR05MB3938CECFE3021577A57783D2AE3A0BN7PR05MB3938namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Each week between now and IETF 107, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-gont-v6ops-cpe-slaac-renum. When reviewing this draft, please indicate whether you think that V6OPS sho= uld adopt it a s a work item. Fred and Ron Juniper Business Use Only --_000_BN7PR05MB3938CECFE3021577A57783D2AE3A0BN7PR05MB3938namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Each week between now and IETF 107, we will revie= w and discuss one draft with an eye towards progressing it.

 

This week, please review and comment on draft-gont-v= 6ops-cpe-slaac-renum.

 

When reviewing this draft, please indicate whether y= ou think that V6OPS should adopt it a s a work item.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Fred and Ron

 


Juniper Business= Use Only

--_000_BN7PR05MB3938CECFE3021577A57783D2AE3A0BN7PR05MB3938namp_-- From nobody Sun Jan 12 17:01:29 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4E0120045 for ; Sun, 12 Jan 2020 17:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjXBrcHEuNEY for ; Sun, 12 Jan 2020 17:01:26 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089D412001E for ; Sun, 12 Jan 2020 17:01:26 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id t129so7120332qke.10 for ; Sun, 12 Jan 2020 17:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=qpAt5iJX/kEOrBvnBX9vnBrW8ONHU5ONbEdiINUFUYQ=; b=cNqB70b9EDrqNY7I6BtSWFc7a6rRfL7/azgwvibdFq4Oi63y3vMgvDw7sBCT+kR/Hg EaBpZUS4/v3YtzLg5ECIk/F59pUhhODs3/IA9vNjIJf8cxKVhVmSooTltEhIEvmZNHhl cS2QZyh6wJpTUJe7mk0ugPgvxdPxgqKHeEQ5xkOGx+pPZMchg3yU57/y3/vCBTFmeext VQhPTlo6147UMSKFxbASOycRhrLM3KA9TPrnLujkLIJ2S6Qp7XoYdLNqM3F3egMpuGW6 844ST0tENyljutftQIcb/hwCjDskxq5SwItkORWvtuayCm5gondbeaSD6+T+tNvSSyR6 hr8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=qpAt5iJX/kEOrBvnBX9vnBrW8ONHU5ONbEdiINUFUYQ=; b=oMe0D1HmPK5KaUDIhr217QcxCN6fbieZvnLjCnqzYr43FcYAmJgHfgpZPJv5jfTerH aYH0zwpFNQBeENjsFI8GbyahRxpLjxmDQFscp/IpMJIZZSJTWX4zQNJVRy6L6nY9s4Nx P01JvwV6vbH7CdMIIYmqDds8ThRhnSHSCP59wkn6bkc12soC1lmPUq7SASDDDHJhWLk8 5RoI8dPSseDt+JOvVajlEQs4Dcl8oEX6T4deb/3SeLr5H6koWF/yhdhiwHfHwHuayNrQ uwcK+RRsfzWlleB+ED4BZyxZn1tktYj6aZi3OTCCToaOcezUTCD4fwRjxkz5fsi2n8zl I5tw== X-Gm-Message-State: APjAAAW1Q1H4omhIASLgyvdESON9zdCBjXa46BDLTBNUTh/kMxSrB3iw /JeNoLw2En1yhwWcuWzG4Mt3O1ez X-Google-Smtp-Source: APXvYqxgCRVFTR2aqBgCvV99c7H55Zf9yubWzkF5N0/4qpuye8hfBhztyqXNo+6F2JEkwqBZAotCKA== X-Received: by 2002:a05:620a:2041:: with SMTP id d1mr14142401qka.113.1578877284677; Sun, 12 Jan 2020 17:01:24 -0800 (PST) Received: from ?IPv6:2804:368:9:8000:595b:91be:be4e:62d9? ([2804:368:9:8000:595b:91be:be4e:62d9]) by smtp.gmail.com with ESMTPSA id e21sm4285146qkm.55.2020.01.12.17.01.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jan 2020 17:01:23 -0800 (PST) To: v6ops@ietf.org References: From: Fernando Frediani Message-ID: <7c69bc2c-07e1-547b-6412-bbda37b8a182@gmail.com> Date: Sun, 12 Jan 2020 22:01:19 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2487734A717D2AEFE896EA96" Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-gont-v6ops-cpe-slaac-renum **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jan 2020 01:01:28 -0000 This is a multi-part message in MIME format. --------------2487734A717D2AEFE896EA96 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I have reviewed this draft and I support it to be adopted. This is a real operational problem among ISPs where the CPE somehow looses connectivity and devices behind  it keep trying to navigate via IPv6 which in turn gives a false sensation of slowness or connectivity problems. In some cases unsuspecting operators don't know how to diagnose and just disable IPv6 which causes a even bigger damage to the its adoption. Therefore I believe this issue should be worked and addressed. Regards Fernando On 12/01/2020 20:18, Ron Bonica wrote: > > Folks, > > Each week between now and IETF 107, we will review and discuss one > draft with an eye towards progressing it. > > This week, please review and comment on draft-gont-v6ops-cpe-slaac-renum. > > When reviewing this draft, please indicate whether you think that > V6OPS should adopt it a s a work item. > > Fred and Ron > > > Juniper Business Use Only > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------2487734A717D2AEFE896EA96 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I have reviewed this draft and I support it to be adopted.

This is a real operational problem among ISPs where the CPE somehow looses connectivity and devices behind  it keep trying to navigate via IPv6 which in turn gives a false sensation of slowness or connectivity problems. In some cases unsuspecting operators don't know how to diagnose and just disable IPv6 which causes a even bigger damage to the its adoption.
Therefore I believe this issue should be worked and addressed.

Regards
Fernando

On 12/01/2020 20:18, Ron Bonica wrote:

Folks,

 

Each week between now and IETF 107, we will review and discuss one draft with an eye towards progressing it.

 

This week, please review and comment on draft-gont-v6ops-cpe-slaac-renum.

 

When reviewing this draft, please indicate whether you think that V6OPS should adopt it a s a work item.

 

                                                      Fred and Ron

 


Juniper Business Use Only


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------2487734A717D2AEFE896EA96-- From nobody Tue Jan 14 10:28:05 2020 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 DE1AC120B94; Tue, 14 Jan 2020 10:27:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <157902647977.7864.3317941757970694680@ietfa.amsl.com> Date: Tue, 14 Jan 2020 10:27:59 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-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: Tue, 14 Jan 2020 18:28:00 -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 : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-00.txt Pages : 18 Date : 2020-01-14 Abstract: This document proposes possible solutions to avoid certain drawbacks of IP/ICMP Translation Algorithm (SIIT) when the destinations are already available with IPv6. When SIIT is used as a stateless NAT46 and IPv4-only devices or applications initiate traffic flows to dual- stack services (in the operator network or Internet), those flows will be translated back to IPv4 by a NAT64. Avoiding this dual- translation will significantly reduce the usage of the NAT64 and the relevant logging, which may be a high impact when traffic flows are towards CDNs, caches or similar resources. This is the case for 464XLAT and MAP-T. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-00 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-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 Wed Jan 15 14:38:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF13B120639 for ; Wed, 15 Jan 2020 14:38:41 -0800 (PST) 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, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgdBPV_T-Pxw for ; Wed, 15 Jan 2020 14:38:38 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B9512010C for ; Wed, 15 Jan 2020 14:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1579127910; x=1579732710; 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=qCFcs0w4WLt1cRRh5um5QqQNdnQyr3zWHj jRM/MNGnM=; b=AXBmbDM6R4sjO66mkSSO+ikwrnWDBC3deWfGTD92TSbz6zTobV XjZRjSLEMYp1h/lgQstSZDahtboXxwCcsrBIBrBdLBZCoLAtlmbgDfzbqJlKcr0g yVAwhCxEGrbUOP61+pVOTYG89YRon4upWn59b3tjH1aieTniY1BgMz8wM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 15 Jan 2020 23:38:30 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 15 Jan 2020 23:38:30 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000029979.msg for ; Wed, 15 Jan 2020 23:38:29 +0100 X-MDRemoteIP: 2001:470:1f09:495:f04a:6e03:8241:9921 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Wed, 15 Jan 2020 23:38:29 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1283c99f22=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Wed, 15 Jan 2020 23:38:25 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <4B73F334-E0B2-4302-AF5F-8267108ECDCE@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3661976305_1126600156" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Jan 2020 22:38:42 -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_3661976305_1126600156 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Erik, =20 =20 El 9/1/20 21:07, "v6ops en nombre de Erik Nygren" escribi=C3=B3: =20 While I'm very supportive of 464xlat as a transition technology, and while = I was very optimistic about this approach=20 at first (and may even have suggested some of the proposals included in the= draft), on subsequent reflections I continue to have significant concerns about the fragility of = this approach. =20 CPEs have already state with IPv4, and what we are suggesting is just more = of the same (as you said, thanks in part to your suggestions!). =20 Implementing this in a way that works well with a generic CDN (ie, one not= managed by the operator) will require a significant amount of state and complexity = in CPE devices. It only will take one or two bad CPE implementations to result in CDNs bein= g forced to switch content to IPv4-only to address user complaints, which would undo what this= =20 is trying to achieve. =20 I=E2=80=99m for not breaking anything, of course, it could not be smart to = get an RFC from something that we know that breaks things. =20 In particular, the fundamental issue is that the RR sets returned for A and= AAAA records from many CDNs are not 1:1 and also change frequently during the lifetime o= f connections. =20 No doubt, that I will review as many times as needed, all the possible =E2= =80=9Cflows=E2=80=9D and interactions to make sure that the text in the doc= ument is working and not breaking anything. =20 As such, I continue to have serious reservations about trying to move this = forwards as anything other than Experimental. If we do move forward, the DNS-based = approach =20 You=E2=80=99re right that a single CPE implementation will be bad. But, how= that is different from any other RFC? =20 needs to be comfortable moving lots more state into the CPE than I recall s= eeing in the last version of this that I read. In particular, if DNS sees chang= es to {A,AAAA}=20 pairings, it is critical to only apply those to future connections and not = break existing=20 connections, meaning that CPEs need to keep these rewrite rules associated with stateful connection tracking. =20 This is what we have now in the document. I can extend the text to make sur= e it is clear enough and helps implementors in understanding all your point= s. =20 With the use-case for this being IPv4-only devices, a question may be wheth= er it is better to focus on trying to get those devices to implement native IP= v6 support =20 I will agree on that, but when you ask for vendors of those devices if they= will upgrade them to support IPv6, the response is =E2=80=9Cbuy a new Smar= TV=E2=80=9D. Not everyone can buy a new SmartTV every few years =E2=80=A6 a= nd what about devices that are still in use and the manufacturer is no long= er there? =20 while handling them via a CLAT in the CPE for the time-being. Alternately,= lw4o6 addresses the "offload stateful NAT off of the CPE" in a much less fragile = way. =20 The point here is that only 464XLAT is supported in mobile, and as a conseq= uence, in many cases, and especially in operators that want to have a singl= e mechanism for all their access networks, other transition mechanisms aren= =E2=80=99t a solution. =20 Erik =20 =20 =20 =20 =20 =20 On Wed, Dec 11, 2019 at 2:25 PM Ron Bonica wrote: Folks, =20 Each week between now and IETF 107, we will review and discuss one draft wi= th an eye towards progressing it. =20 This week, please review and comment on draft-palet-v6ops-464xlat-opt-cdn-c= aches. =20 When reviewing this draft, please indicate whether you think that V6OPS sho= uld adopt it a s a work item. =20 Fred and Ron =20 =20 Juniper Business Use Only _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3661976305_1126600156 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Erik,

 

 

El 9/1/20 = 21:07, "v6ops en nombre de Erik Nygren" <v6ops-bounces@ietf.org en nombre de erik+ietf@nygren.org> escribi=C3=B3:<= /o:p>

 

While I'm very= supportive of 464xlat as a transition technology, and while I was very opt= imistic about this approach

at first (and may even have suggested some of the proposals includ= ed in the draft), on subsequent

reflections I continue to have significant concerns about the f= ragility of this approach.

 <= /o:p>

CPEs have already state with IPv4, and what we are sugg= esting is just more of the same (as you said, thanks in part to your sugges= tions!).

 

Implementing this in a way that works well with a generic CDN&nb= sp; (ie, one not managed

by the operator) will require a significant amount of state and comple= xity in CPE devices.

It only will take one or two bad CPE implementations to result in CDNs bei= ng forced to switch

= content to IPv4-only to address user complaints, which would undo what this=

is trying to achie= ve.

 

I=E2=80=99m for not breaking anything, of course, it could = not be smart to get an RFC from something that we know that breaks things.<= o:p>

 

In particular, the fundamental issue is that the R= R sets returned for A and AAAA records

from many CDNs are not 1:1 and also change frequently du= ring the lifetime of connections.

 

No doubt, that I will review as many ti= mes as needed, all the possible =E2=80=9Cflows=E2=80=9D and interactions to make sure that the text in the document is working and not break= ing anything.

 

As such, I continue to have serious reservations about tryin= g to move this forwards

as anything other than Experimental.  If we do move forward, the D= NS-based approach

 

You=E2=80=99re right that a single CPE implem= entation will be bad. But, how that is different from any other RFC?

 

need= s to be comfortable moving lots more state into the CPE than I recall seein= g

in the last versio= n of this that I read.   In particular, if DNS sees changes to {A= ,AAAA}

pairings, it= is critical to only apply those to future connections and not break existi= ng

connections, mea= ning that CPEs need to keep these rewrite rules associated

with stateful connection tracking.

 

T= his is what we have now in the document. I can extend the text to make sure= it is clear enough and helps implementors in understanding all your points= .

 

With th= e use-case for this being IPv4-only devices, a question may be whether

it is better to focus on trying to get= those devices to implement native IPv6 support

 

I will agree = on that, but when you ask for vendors of those devices if they will upgrade= them to support IPv6, the response is =E2=80=9Cbuy a new SmarTV=E2=80=9D. = Not everyone can buy a new SmartTV every few years =E2=80=A6 and what about= devices that are still in use and the manufacturer is no longer there?

 =

while ha= ndling them via a CLAT in the CPE for the time-being.  <= span class=3Dgmaildefault>A= lternately, lw4o6

addresses the "offload stateful= NAT off of the CPE" in a much less fragile way.

&n= bsp;

The point here is that only 464XLAT is supported in mobile, and as a = consequence, in many cases, and especially in operators that want to have a= single mechanism for all their access networks, other transition mechanism= s aren=E2=80=99t a solution.

 

 =        Erik<= /o:p>

=  

 

 <= /span>

 

 

 

On Wed, Dec 11, 2019 at= 2:25 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf..org> wrote:

Folks,

 

Each week between now and IETF 1= 07, we will review and discuss one draft with an eye towards progressing it= .

&= nbsp;

Thi= s week, please review and comment on draft-palet-v6ops-464xlat-opt-cdn-cach= es.

 = ;

When re= viewing this draft, please indicate whether you think that V6OPS should ado= pt it a s a work item.

 

          &nb= sp;            =             &nb= sp;            =       Fred and Ron

 

 

Juniper B= usiness Use Only

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

_________________= ______________________________ v6ops mailing list v6ops@ietf.org https://ww= w.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_3661976305_1126600156-- From nobody Wed Jan 15 14:56:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7791208AC for ; Wed, 15 Jan 2020 14:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6OjyC4ido9P for ; Wed, 15 Jan 2020 14:56:04 -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 76A8D120639 for ; Wed, 15 Jan 2020 14:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1579128961; x=1579733761; 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=hDO1aRCW OwzM1YbncYELdLh+7mHREHOHW7XGVgUDeF4=; b=gjD0W5QBiXvKIMpQv4cBgFwJ RikBJlIq5h6vOrWDgSUg7ABJ88482iS0+Sxxv0rNDuxrhfKtR8Ds48jiWPyd47FK 0gFCz5Dsxx/IKpLcebt5ZP4q95ZKakNz1X6V5OzXl5ijFO4KwoNM8SbtJ4S3U64H Xa4NhprdXc1O6Ng8hy4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 15 Jan 2020 23:56:01 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 15 Jan 2020 23:56:01 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000029992.msg for ; Wed, 15 Jan 2020 23:56:00 +0100 X-MDRemoteIP: 2001:470:1f09:495:f04a:6e03:8241:9921 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Wed, 15 Jan 2020 23:56:00 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1283c99f22=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Wed, 15 Jan 2020 23:55:59 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <26BA5BBF-B8D3-4BA3-8F4E-C8322D12B334@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-00.txt References: <157902647977.7864.3317941757970694680@ietfa.amsl.com> In-Reply-To: <157902647977.7864.3317941757970694680@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-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, 15 Jan 2020 22:56:06 -0000 Hi all, I this version we have tried to reword some text and respond to the inputs = from Chongfeng, Fernando (Gont) and Fernando (Frediani). https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization So please, let's us know if you still think anything is missing and of cour= se, any further inputs welcome! Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 14/1/20 19:28, "v6ops-bounces@ietf.org en nombre de internet-dr= afts@ietf.org" escribi=C3=B3: =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 : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-00.txt Pages : 18 Date : 2020-01-14 =20 Abstract: This document proposes possible solutions to avoid certain drawbacks of IP/ICMP Translation Algorithm (SIIT) when the destinations are already available with IPv6. When SIIT is used as a stateless NAT46 and IPv4-only devices or applications initiate traffic flows to dual= - stack services (in the operator network or Internet), those flows will be translated back to IPv4 by a NAT64. Avoiding this dual- translation will significantly reduce the usage of the NAT64 and the relevant logging, which may be a high impact when traffic flows are towards CDNs, caches or similar resources. This is the case for 464XLAT and MAP-T. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-00 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimiza= tion-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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Jan 17 11:22:45 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6779F1200CD for ; Fri, 17 Jan 2020 11:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjpkeBMPKGMX for ; Fri, 17 Jan 2020 11:22:39 -0800 (PST) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 85CF31200A4 for ; Fri, 17 Jan 2020 11:22:39 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id r67so3567330pjb.0 for ; Fri, 17 Jan 2020 11:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VB3u4ZNOrV8Vtga50JJKGsekLVWXZnVZd45aAiHRqkA=; b=gUAGHZHVaJfnSilFQXgwuX9q+JRqjvdt/ax7xu07z8oWxlD4z8FiDICA9aXRT6SC7Y Qeuq5BFmPrscKmbL5XsEpRZZvvkF1+F7e5U6601L6psdMHVSAwGYCwcc+lPfi1HOEqNP uxZX9E/8VlocOQ4quFMmuqgetxJebt5WlN4ktnSMmZrO3bk/QcxnWZfDKOcPeoIQGC2a GdrEVJbKz87dz+FqbxlfMCvdHEGzSDyz/LYZIDcvw/2oBb1tvELIphCQgh1TeGqjGcJe 5ofKnvR2A1BHc6dn1MF2ejBaPAXexujs3WkFW3YSag2/JEIc2mH5NXzbaJsRkta61Q8i Ii8w== 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=VB3u4ZNOrV8Vtga50JJKGsekLVWXZnVZd45aAiHRqkA=; b=GiYkL5IqLNOY1Aj/V2/Pfyil4snFkMdxI/zXWXwH4a1DIR1d+ONvRNJfDkASQF+fKv rV+zlkEA/f73q0sJ4Yl7YTGU/SliC6Utaa63iGo93A3ftCBUBX9pAToCUDV8Ur8y6WDG kgUMA/UGWFKi11WPm4wx5owVRnTYnhDJFVomFQ0uSYPh5qOZsY6YnXdVc6WgO5flkS8M jumucdtvpVL3qIMecn/AVYf9fBobepUkO+tAFF4/FHK1y+Yx4bNBcRCiwW2rOZegCTH6 ADTEwsziK7Z+hmTT+rCgkcHLoD8cYMbUemXyc2HPhbDIG9EN9cqps105qM3NFrZ0UJaO nG2Q== X-Gm-Message-State: APjAAAWlpNaxk9ToiaTVg/Drx+28gVVU7/F8e0epkxOrwRLfMav2v0xH FRRQcq3Gpo5xnn1F4kFxJa6QE/k7 X-Google-Smtp-Source: APXvYqwNAOmxsM/2dXzMz8Df+ud5cFYDqaCg70UbE9+qtrQZDguz6fXT7eI5uEziuWbLeA5UaMyQ8A== X-Received: by 2002:a17:902:b281:: with SMTP id u1mr679431plr.67.1579288958943; Fri, 17 Jan 2020 11:22:38 -0800 (PST) Received: from ?IPv6:2600:8801:d000:494:d481:94f5:3872:61e2? ([2600:8801:d000:494:d481:94f5:3872:61e2]) by smtp.gmail.com with ESMTPSA id h11sm28443981pgv.38.2020.01.17.11.22.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jan 2020 11:22:37 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_92623A79-F7F3-44B8-930E-3DBEA2C900E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.2\)) Date: Fri, 17 Jan 2020 11:22:13 -0800 In-Reply-To: <4B73F334-E0B2-4302-AF5F-8267108ECDCE@consulintel.es> Cc: "v6ops@ietf.org" To: JORDI PALET MARTINEZ References: <4B73F334-E0B2-4302-AF5F-8267108ECDCE@consulintel.es> X-Mailer: Apple Mail (2.3608.60.0.2.2) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Jan 2020 19:22:41 -0000 --Apple-Mail=_92623A79-F7F3-44B8-930E-3DBEA2C900E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2020, at 2:38 PM, JORDI PALET MARTINEZ = wrote: > No doubt, that I will review as many times as needed, all the possible = =E2=80=9Cflows=E2=80=9D and interactions to make sure that the text in = the document is working and not breaking anything. Is it fair to assume that Alejandro, your co-author, has tested a = prototype in his network? --Apple-Mail=_92623A79-F7F3-44B8-930E-3DBEA2C900E9 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+AFAl4iCXcACgkQEhdRnd2G P+AsSBAAlWwNwP9llZdAfNJ1XiL7JsQOTb9XPZCRMJCDVUhAszgOycycVnFBmThZ Ko6C+BtkRFiJpDatUv6GCm2DHz880Pk6zNMCdUhAAJn36RZB+EiPQSs1W9HktVyU kAQZ3HId40t8plRYCmTdmRPtp6DutamSkPEG3XeUlNFwZYC6zds3dhIg/VYh8UX0 6B5etZx3Rg2K7Mx57UPP0lCKXRq2B3krqh9mY+uIpcUT2yXbUwPuZkzs5eHSUkXl Qb8Lz3tjUt8R7EhAGliWGOKBah9ccG5yf5W2wn7RlRj7yvGNJfSEvPVVOPwEoNrm WncHX8UdL0sCDgnL5HwQKfXjLrNNPfCGmChf4oMMW2lfyYNfSTdiFODQjrllpmm9 oe9tRyTIMdcAQ3Yj82ltKy5i6X7c3rUFCr42bOHD4AsaNI+hsowS0fxdEyFsm8gW eTaxYy5S0zR6mo7xEP4rurJ4ZMEP4cDVNiR0yrKTFiyU13v8MjTRWmighd3hIgHr a/6EOSuM65u04PYr18l37K6Ie5DKEiqp6IE3OH0S+fKy11ZkOTGvHwjtU1IShDq6 3tByGFEfy8nqvHD25jlokIMXiI1sUZajJCofcCmgFE573QBlD0nSVf9ypXOUv1xm cbQWfNTlOScm4RqTfw11VHIBfINNdbOMS1+PL3/VYcDY6rjtI10= =yc7R -----END PGP SIGNATURE----- --Apple-Mail=_92623A79-F7F3-44B8-930E-3DBEA2C900E9-- From nobody Tue Jan 21 06:47:34 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5631200F7 for ; Tue, 21 Jan 2020 06:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=spvxiI5g; dkim=pass (1024-bit key) header.d=juniper.net header.b=A4QUmdzI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY1He5B9PsvM for ; Tue, 21 Jan 2020 06:47:19 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CAE120142 for ; Tue, 21 Jan 2020 06:47:19 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00LEka1e020305 for ; Tue, 21 Jan 2020 06:47:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=dDh8+/bQRTMjGMh47IIX3pEC6WnpSNoaVWRE4CAEiMA=; b=spvxiI5gCAdbbe29MQe8hsH91S80ey++8WdcgTUJwUTpA3ERoFXw7cXPl4SIYJ5Mxt9t M27J/qETi428m/2DRvglvg/bPR0RMkiEHTnyAVtdt4oNW92eMDJkPWWkqv1/2pltjn65 n5Rx+oUe+iFWDJw5RTrmzfKWJtpXF4i6ZKCtHZya0KjG+ims3AwApkRoM5xpgzZ5vIwG zJt1PHfkhh65RwHMiZw2CrUjOFgX71kF8xbG+f5hGX218Dh3r751HJL6D0LRarWOkEBM tEYWdeSXRv66T7QIUnloIE0ctGRe/4YaWQNQhzYUoIK/kq5x+vrjWkTzP+VDsAXS6ths NQ== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by mx0a-00273201.pphosted.com with ESMTP id 2xm25tcekt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 Jan 2020 06:47:19 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gI+npKCWPrTKTXj+KachgqJo1001U7z36lnxWc2sk1eXYbQZvvd/VUJO6ATcCM0Uc8G00HWeGVIU31stJDzvncXfnNjw1GepPcbLJhq764wPx6ERfkhdOIB6MXYjbcwp7uC5WfzXuUrlN8wylEmEvnps2SW9iV0qEhNWkeuCem2y5JBpqhFg43rkslaTDS04yWVhr6XoIUARwRI3uRT72yLqM2RwCgHZ5RpeUXNuIAfSHtaU5++j2otOd6+vTSccOCdCTcwAGQ7M6csbJHayzosb21wJEd4pFY5RN9kzUYRRhy2wQtDz5es8oMl4is7ad6086Ai1iCAWxqlNxlA2CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dDh8+/bQRTMjGMh47IIX3pEC6WnpSNoaVWRE4CAEiMA=; b=Pf+snFkoDcfZXe/wFuEc3qdmdt97VxlS+QIrfYpWNrsY4e8crFSyiR8wVtFzGsZSLsVtn6jxWiDbF+J25XObEJlSa3JkccQURVJBwOyVeZLAZxr6IPVbtd+gsQWyaWeUycPYpmX5Q/rNNmtelRrAPNjQOc32ifogABYBBDgrKWJfDyY+8gAUw57iBLqg9DETvhA9sdRhQZ7y8Btch2y8soYKQ/QpYb2hzo7EilGNsDkSVthiAjWRlfaXNUF4FHyIA+HXAbO064EAFYT0GNd+4xcqQmmXbdzY0FB8cd+J8r71YhS6G2RYBx+6bW7uP6suGVslpwRCA5Iu5xyXtnTJVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dDh8+/bQRTMjGMh47IIX3pEC6WnpSNoaVWRE4CAEiMA=; b=A4QUmdzIuO6t/YFDdD9GGNZwLnBS/9aS7kOc9oVfJFQKIq8fmUVqJQ62fcHudMLHJXlyI3CDuYiH/vbMRPcFp94RdKIpzGcrk2ABOZoktr1TlslLln/oburCCZFK0sQTgvsb7KhTD7cI++dCB1S54TK0Beg3u7M3QZuUuR9PcV0= Received: from BN7PR05MB3938.namprd05.prod.outlook.com (52.132.216.30) by BN7PR05MB4435.namprd05.prod.outlook.com (52.135.251.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.10; Tue, 21 Jan 2020 14:47:15 +0000 Received: from BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864]) by BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864%5]) with mapi id 15.20.2665.015; Tue, 21 Jan 2020 14:47:15 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-lmhp-v6ops-transition-comparison **Call for Adoption** Thread-Index: AdXQaYmgMdob6733RnetZISEAl2aXQ== Date: Tue, 21 Jan 2020 14:47:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-01-21T14:46:18.2416660Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=3aca2fe6-9d15-4dab-99a3-aa60da0a02eb; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.3.2.8 dlp-reaction: no-action x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 42f68d3b-e7ad-49f5-f03f-08d79e80ce9d x-ms-traffictypediagnostic: BN7PR05MB4435: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2887; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(136003)(39860400002)(346002)(366004)(199004)(189003)(6506007)(81166006)(81156014)(316002)(4744005)(64756008)(76116006)(66446008)(66476007)(8676002)(66556008)(66946007)(26005)(52536014)(6916009)(9686003)(55016002)(5660300002)(33656002)(478600001)(86362001)(7696005)(71200400001)(2906002)(8936002)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4435; H:BN7PR05MB3938.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7XlsMSQCcaksec9wcngY27COEZW3+LAwpGIqpzYAlbrIY+pTw997gMaKTZSPpt/MHh4UTSk172JJCHqLeziO4o6P87ISClZJ1guAAWzQRpAmgN4CXzenNZmOvYnKShkhPVG8d7dNPZGLZXtG3Z6OlffGJSsdYJa8vEYWqZ73NPIqW9yQMOnSz9WcymTuG4TAaCtn6ICxi08377idITiWv0Yg0CUTX2Ep2hGTtYnjjwc9ktfuTvWdtFfJ1xbniNQZ5PnVt0lH1KqIhpfPWPR//9oNM4tIawr/EdJh92TZe7hYsS+cL52OudclSdt/3jlt7ZebAm33ASKZaf6F32uh2K3IeA1iTWM0AWe3XoMkVQ602PbhHpeVu/Zn8TbzXbVMXDv9EsTOel14N6y15asxW6GEzNdQYb1XGLO3hQLCyupveSG1uRCWJwq7pKOGKDC/ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR05MB3938E445275493A6BFC9B3F1AE0D0BN7PR05MB3938namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 42f68d3b-e7ad-49f5-f03f-08d79e80ce9d X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 14:47:15.4924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CbMIseReE6i7IAYkK/9RtxwAyNhTNugjUpr6NK95/uKqWL9KlwrOd8MQlVY8UWnMXIdeVQ7HQAp8XWuWuFD7dg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4435 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-21_04:2020-01-21, 2020-01-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 bulkscore=0 clxscore=1015 mlxscore=0 adultscore=0 phishscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 mlxlogscore=804 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001210120 Archived-At: Subject: [v6ops] draft-lmhp-v6ops-transition-comparison **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jan 2020 14:47:33 -0000 --_000_BN7PR05MB3938E445275493A6BFC9B3F1AE0D0BN7PR05MB3938namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Each week between now and IETF 107, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-lmhp-v6ops-transition-compari= son . When reviewing this draft, please indicate whether you think that V6OPS sho= uld adopt it a s a work item. Fred and Ron Juniper Business Use Only --_000_BN7PR05MB3938E445275493A6BFC9B3F1AE0D0BN7PR05MB3938namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Each week between now and IETF 107, we will revie= w and discuss one draft with an eye towards progressing it.

 

This week, please review and comment on draft-lmhp-v= 6ops-transition-comparison .

 

When reviewing this draft, please indicate whether y= ou think that V6OPS should adopt it a s a work item.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Fred and Ron

 

 


Juniper Business= Use Only

--_000_BN7PR05MB3938E445275493A6BFC9B3F1AE0D0BN7PR05MB3938namp_-- From nobody Wed Jan 22 04:18:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD3120089 for ; Wed, 22 Jan 2020 04:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew5VbfimgB3O for ; Wed, 22 Jan 2020 04:18:01 -0800 (PST) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 D3719120077 for ; Wed, 22 Jan 2020 04:18:00 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id i78so1892162vke.0 for ; Wed, 22 Jan 2020 04:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=COFWk8+yXwk1KCX9kjchu8fW0VFSYfolq4+eus/hN9E=; b=u1Q8XNc8i0vvQYIo1eFZ65scH8qC5ZIRrxAnZ3WZ26a0GefoktabzS0OXl3LKsCcWf qtoPgQ9OpDQNV/z+K/enKYx/2sV2VwxMcWg+vJH1Dv3II5lz3p7DIb9Z5wSnggBsC7+W VOtkSMLfWjt4bmCo9VloolG02qcxNWrb8P2wd0e6h6lEG4Qq7/faPKX4BJ1BYbOQZyAb bAoJjlHjrlsV7DDqOl6bV1xzrwXQ1nemvDNwodA4u9QZ5d7CVaFoJhIl/+5IKDcFcUEs HMopvXBKt1HDHQ7q4p1viuF460AshLlcSiPqNUpNpwbv+joz3k1ktLaN4e6gxYA4xs8S EDgw== 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:cc; bh=COFWk8+yXwk1KCX9kjchu8fW0VFSYfolq4+eus/hN9E=; b=JWLk8XbIj7HNkyhs+O3dSzeu2swfZ8lr/UYUfQ2GG5ry7PJSqUWNqWfkNdWYxJi3Vm E9Y8Pmo3GA36vKK3XR3LmXIFGcW2I6LTZDbhmbqR6fBeUSnmXwYu7iLIRSMqm2kVfpaH zgfps+gFj3mZw74zEOxecILdo7qN7EryCjvZbswnXrHNJwThoOchgR6s0m5OM97KDY6E DIYzPtaHJbt4sTN6BSTvc+vk5KeBL5vuXz6LlrAM+ssU0uvR3VOaMb3/qJJ7c5gT2LvG 30BOAUG5XotkIhX4GcFomJDzyLSbSdtSUPQrKaB9z6GM4mjTKGaGv+KRUkCl1PZqhNt4 HcTg== X-Gm-Message-State: APjAAAVAoG4h9M+lB5+po8P0EGpsoDQ7PVHsr0Q3eXwR8/+16DINHP1/ VnpAx0EI8XMBW9qW4fDNABbceWHX9F30waN+DYi4hAiEvEQcXw== X-Google-Smtp-Source: APXvYqwzi7DBNyh/smCz431C5qXnFNVVNer7jxAUnk7FwTqFYKMUeQZRMH6wjuSb5cwif7GKIHTTrdYeG53lCnQ33dQ= X-Received: by 2002:a05:6122:2dc:: with SMTP id k28mr5959223vki.70.1579695479509; Wed, 22 Jan 2020 04:17:59 -0800 (PST) MIME-Version: 1.0 References: <7c69bc2c-07e1-547b-6412-bbda37b8a182@gmail.com> In-Reply-To: <7c69bc2c-07e1-547b-6412-bbda37b8a182@gmail.com> From: Uesley Correa Date: Wed, 22 Jan 2020 09:17:48 -0300 Message-ID: Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000e8d5b6059cb98336" Archived-At: Subject: Re: [v6ops] draft-gont-v6ops-cpe-slaac-renum **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2020 12:18:02 -0000 --000000000000e8d5b6059cb98336 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi folks, Can I copy and paste for Fernando Frediani mail? This is exactly can occurred in a much ISPs because they not know solve this. And much ISPs are disable IPv6 for solve this trouble. I support to be adopted the draft. Regards, Uesley Corr=C3=AAa - Analista de Telecomunica=C3=A7=C3=B5es CEO Telecom Consultoria, Entrenamiento y Servicios CEO Telecom Fiber Solutions Em dom., 12 de jan. de 2020 =C3=A0s 22:01, Fernando Frediani < fhfrediani@gmail.com> escreveu: > I have reviewed this draft and I support it to be adopted. > > This is a real operational problem among ISPs where the CPE somehow loose= s > connectivity and devices behind it keep trying to navigate via IPv6 whic= h > in turn gives a false sensation of slowness or connectivity problems. In > some cases unsuspecting operators don't know how to diagnose and just > disable IPv6 which causes a even bigger damage to the its adoption. > Therefore I believe this issue should be worked and addressed. > > Regards > Fernando > On 12/01/2020 20:18, Ron Bonica wrote: > > Folks, > > > > Each week between now and IETF 107, we will review and discuss one draft > with an eye towards progressing it. > > > > This week, please review and comment on draft-gont-v6ops-cpe-slaac-renum. > > > > When reviewing this draft, please indicate whether you think that V6OPS > should adopt it a s a work item. > > > > Fred and Ron > > > > Juniper Business Use Only > > _______________________________________________ > v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6o= ps > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000e8d5b6059cb98336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi folks,

Can I copy and paste for Fernando Fredi= ani mail? This is exactly can occurred=C2=A0in a much ISPs because they not= know solve this. And much ISPs are disable IPv6 for solve this trouble. I = support to be adopted the draft.

Regards,

Uesley C= orr=C3=AAa - Analista de Telecomunica=C3=A7=C3=B5es
C= EO Telecom Consultoria, Entrenamiento y Servicios
CEO Telecom Fib= er Solutions


Em dom., 12 de jan. de 2020 =C3=A0s 22:01, Fernand= o Frediani <fhfrediani@gmail.com= > escreveu:
=20 =20 =20

I have reviewed this draft and I support it to be adopted.

This is a real operational problem among ISPs where the CPE somehow looses connectivity and devices behind=C2=A0 it keep trying t= o navigate via IPv6 which in turn gives a false sensation of slowness or connectivity problems. In some cases unsuspecting operators don't know how to diagnose and just disable IPv6 which causes a even bigger damage to the its adoption.
Therefore I believe this issue should be worked and addressed.

Regards
Fernando

On 12/01/2020 20:18, Ron Bonica wrote:
=20 =20 =20

Folks,

=C2=A0

Each week between now and IETF 107, we will review and discuss one draft with an eye towards progressing it.

=C2=A0

This week, please review and comment on draft-gont-v6ops-cpe-slaac-renum.

=C2=A0

When reviewing this draft, please indicate whether you think that V6OPS should adopt it a s a work item.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fred and Ron

=C2=A0


Juniper Business Use Only


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000e8d5b6059cb98336-- From nobody Wed Jan 22 07:03:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84631200F6 for ; Wed, 22 Jan 2020 07:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Qd8GafEyukYm for ; Wed, 22 Jan 2020 07:03:36 -0800 (PST) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A73C1200EF for ; Wed, 22 Jan 2020 07:03:35 -0800 (PST) Received: from [192.168.1.135] (host-79-121-42-199.kabelnet.hu [79.121.42.199]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 00MF3NiU038671 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 22 Jan 2020 16:03:29 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-199.kabelnet.hu [79.121.42.199] claimed to be [192.168.1.135] To: v6ops@ietf.org References: From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <0cc2383b-4be4-4958-f5a5-6c21830b3e10@hit.bme.hu> Date: Wed, 22 Jan 2020 16:03:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6FBCC5B80E3E89CD5C2B6520" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.199; helo=[192.168.1.135]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2020 15:03:42 -0000 This is a multi-part message in MIME format. --------------6FBCC5B80E3E89CD5C2B6520 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear V6OPS Members, The latest version of our draft contains a short section about Performance Comparison: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-04#section-5 I consider the performance comparison of the different IPv6-as-a-Service solutions (and that of their different implementations) quite important from network operator point of view, because their performance requirement has a direct influence on the price of the required hardware and also on the electricity bill. Let me give you a short summary, what we have for a reasonable performance comparison and what we are lacking of. Theoretically, we have the methodology in RFC 8219 ("Benchmarking Methodology for IPv6 Transition Technologies"). However, only a small part of the methodology (DNS64) has been actually validated by real experiments. So far, the problem was the lack of compliant Testers. I have recently implemented siitperf, a DPDK-based software Tester for SIIT (also called stateless NAT64) implementations: https://github.com/lencsegabor/siitperf An MSc student of mine is working on a DS-Lite Tester, which I expect to be usable by the end of the Spring semester. (MAP-T/E and Lw4o6 Testers are planned to be implemented from the Autumn semester.) For executing the benchmarking measurements, I can use some Dell servers with 10Gbps interfaces at the NICT StarBED, Japan: http://starbed.nict.go.jp/en/equipment/ I plan to start benchmarking with 464XLAT, as its CLAT and PLAT parts do stateless NAT46 and stateful NAT64, respectively, for which I have a tester. (Siitperf implements Througput, Frame Loss Rate, Latency, and Packet Delay Variation tests of RFC 8219.) However, *there are some points in the methodology, where I will surely need some input from you* as I am a university researcher, and not a network operator. I try to list the most important ones below. 1. Stateful operation According to my understanding of RFC 8219, stateful technologies should be benchmarked with the corresponding stateless tests PLUS a few others defined in Section 8: https://tools.ietf.org/html/rfc8219#page-15 For the ease of use, I copy the relevant text here: 8.1 . Concurrent TCP Connection Capacity UseSection 5.2 of [RFC3511] unmodified. 8.2 . Maximum TCP Connection Establishment Rate UseSection 5.3 of [RFC3511] unmodified. However, I do NOT believe that it is enough. Even if a PLAT can work with 10,000,000 TCP connections, and even if it can establish them fast enough, its performance very likely degrades as the size of the state table increases. What method should be used for assessing this degradation? Is the one below appropriate? 2. Scalability Roughly speaking, I mean under scalability that if the number of the subscribers are doubled, than it will do if we also double the number of CPU cores assigned to the PLAT. (Scalability can be a concern in the case of stateless operation, too. For example, when Explicit Address Mapping is used, the increasing size of the mapping table may also result in decreased performance. Of course, the connection tracking table of a stateful NAT64 gateway may have significantly more entries.) Section 10 of RFC 8219 defines a methodology: https://tools.ietf.org/html/rfc8219#section-10 However, I have a few questions: - What is the right number of network flows to use? - How should I create a high number of network flows? Currently, siitperf follows the requirement of RFC 8219, which uses the Throughput test of RFC 2544. It requires testing first, with a single source and destination address pair, and then using 256 different destination networks. Details: For single flow, siitperf always sends out the same pre-generated test frames. For multi flow, siitperf pre-generates 256 different test frames, where bits 16-23 of the IPv4 addresses and bits 56-63 of the IPv6 addresses are used to express the different networks. The last byte was used to address the DUT (.1) and the Tester (.2). (For the ease of use, I used Explicit Address Mapping, when I performed an initial testing of siitperf: http://www.hit.bme.hu/~lencse/publications/IEICE-2019-siitperf-for-review.pdf .) Which bits of the addresses should be used to create a high number of network flows? Is it enough to use source port numbers to create a high number of network flows? What source port range is to be used? (e.g. from 32768-65535) Or perhaps, when using IPv4-embedded IPv6 addresses and Stateful NAT64, it is not a problem, as there are a high number of IPv6 addresses, which are then mapped for the same public IPv4 address. However, still there are a lot of questions. What number of IPv6 addresses are to be used? What number of different source ports per IPv6 address are to be used? What number of public IPv4 addresses are to be assigned to the NAT64 gateway? Current stateful NAT64 implementations usually use full 5-tuple, that is the same public IP addresses can be reused, when the destination addresses are different. Fortunately, the most popular web sites are usually IPv6 capable, but there may be a few more popular sites among the IPv4-only ones. Is it OK, to assume a uniform distribution of the destination addresses? In many cases, I could just guess some numbers. However, I want to do the tests with *realistic parameters*, so the that results may be useful for the network operators. Please give me suggestions, how to choose good enough parameters! Thank you very much for your help in advance! Best regards, Gábor 2020.01.21. 15:47 keltezéssel, Ron Bonica írta: > > Folks, > > Each week between now and IETF 107, we will review and discuss one > draft with an eye towards progressing it. > > This week, please review and comment on > draft-lmhp-v6ops-transition-comparison . > > When reviewing this draft, please indicate whether you think that > V6OPS should adopt it a s a work item. > > Fred and Ron > > > Juniper Business Use Only > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------6FBCC5B80E3E89CD5C2B6520 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear V6OPS Members,

The latest version of our draft contains a short section about Performance Comparison: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-04#section-5

I consider the performance comparison of the different IPv6-as-a-Service solutions (and that of their different implementations) quite important from network operator point of view, because their performance requirement has a direct influence on the price of the required hardware and also on the electricity bill.

Let me give you a short summary, what we have for a reasonable performance comparison and what we are lacking of.

Theoretically, we have the methodology in RFC 8219 ("Benchmarking Methodology for IPv6 Transition Technologies").
However, only a small part of the methodology (DNS64) has been actually validated by real experiments. So far, the problem was the lack of compliant Testers.
I have recently implemented siitperf, a DPDK-based software Tester for SIIT (also called stateless NAT64) implementations: https://github.com/lencsegabor/siitperf
An MSc student of mine is working on a DS-Lite Tester, which I expect to be usable by the end of the Spring semester. (MAP-T/E and Lw4o6 Testers are planned to be implemented from the Autumn semester.)
For executing the benchmarking measurements, I can use some Dell servers with 10Gbps interfaces at the NICT StarBED, Japan: http://starbed.nict.go.jp/en/equipment/

I plan to start benchmarking with 464XLAT, as its CLAT and PLAT parts do stateless NAT46 and stateful NAT64, respectively, for which I have a tester. (Siitperf implements Througput, Frame Loss Rate, Latency, and Packet Delay Variation tests of RFC 8219.)

However, there are some points in the methodology, where I will surely need some input from you as I am a university researcher, and not a network operator.
I try to list the most important ones below.
 
1. Stateful operation

According to my understanding of RFC 8219, stateful technologies should be benchmarked with the corresponding stateless tests PLUS a few others defined in Section 8: https://tools.ietf.org/html/rfc8219#page-15

For the ease of use, I copy the relevant text here:

8.1.  Concurrent TCP Connection Capacity


   Use Section 5.2 of [RFC3511] unmodified.


8.2.  Maximum TCP Connection Establishment Rate


   Use Section 5.3 of [RFC3511] unmodified.

However, I do NOT believe that it is enough. Even if a PLAT can work with 10,000,000 TCP connections, and even if it can establish them fast enough, its performance very likely degrades as the size of the state table increases. 

What method should be used for assessing this degradation?
Is the one below appropriate?

2. Scalability

Roughly speaking, I mean under scalability that if the number of the subscribers are doubled, than it will do if we also double the number of CPU cores assigned to the PLAT.

(Scalability can be a concern in the case of stateless operation, too. For example, when Explicit Address Mapping is used, the increasing size of the mapping table may also result in decreased performance. Of course, the connection tracking table of a stateful NAT64 gateway may have significantly more entries.)

Section 10 of RFC 8219 defines a methodology: https://tools.ietf.org/html/rfc8219#section-10

However, I have a few questions:
- What is the right number of network flows to use?
- How should I create a high number of network flows?

Currently, siitperf follows the requirement of RFC 8219, which uses the Throughput test of RFC 2544. It requires testing first, with a single source and destination address pair, and then using 256 different destination networks.

Details: For single flow, siitperf always sends out the same pre-generated test frames. For multi flow, siitperf pre-generates 256 different test frames, where bits 16-23 of the IPv4 addresses and bits 56-63 of the IPv6 addresses are used to express the different networks. The last byte was used to address the DUT (.1) and the Tester (.2). (For the ease of use, I used Explicit Address Mapping, when I performed an initial testing of siitperf: http://www.hit.bme.hu/~lencse/publications/IEICE-2019-siitperf-for-review.pdf .)
Which bits of the addresses should be used to create a high number of network flows?
Is it enough to use source port numbers to create a high number of network flows?
What source port range is to be used? (e.g. from 32768-65535)

Or perhaps, when using IPv4-embedded IPv6 addresses and Stateful NAT64, it is not a problem, as there are a high number of IPv6 addresses, which are then mapped for the same public IPv4 address.
However, still there are a lot of questions.
What number of IPv6 addresses are to be used?
What number of different source ports per IPv6 address are to be used?
What number of public IPv4 addresses are to be assigned to the NAT64 gateway?

Current stateful NAT64 implementations usually use full 5-tuple, that is the same public IP addresses can be reused, when the destination addresses are different.
Fortunately, the most popular web sites are usually IPv6 capable, but there may be a few more popular sites among the IPv4-only ones.
Is it OK, to assume a uniform distribution of the destination addresses?

In many cases, I could just guess some numbers. However, I want to do the tests with realistic parameters, so the that results may be useful for the network operators.

Please give me suggestions, how to choose good enough parameters!

Thank you very much for your help in advance!

Best regards,

Gábor



2020.01.21. 15:47 keltezéssel, Ron Bonica írta:

Folks,

 

Each week between now and IETF 107, we will review and discuss one draft with an eye towards progressing it.

 

This week, please review and comment on draft-lmhp-v6ops-transition-comparison .

 

When reviewing this draft, please indicate whether you think that V6OPS should adopt it a s a work item.

 

                                                      Fred and Ron

 

 


Juniper Business Use Only


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

--------------6FBCC5B80E3E89CD5C2B6520-- From nobody Wed Jan 22 14:32:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D84120112 for ; Wed, 22 Jan 2020 14:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 JsBUDp7WAXdT for ; Wed, 22 Jan 2020 14:32:13 -0800 (PST) Received: from gw2mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (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 208E612004F for ; Wed, 22 Jan 2020 14:32:13 -0800 (PST) Received: from gw2mail.telecentro.local (localhost [127.0.0.1]) by gw2mail.telecentro.net.ar (Postfix) with ESMTP id 29E002007E; Wed, 22 Jan 2020 19:31:54 -0300 (-03) Received: from mail.telecentro.net.ar (unknown [10.4.20.96]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gw2mail.telecentro.net.ar (Postfix) with ESMTPS; Wed, 22 Jan 2020 19:31:52 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 5E2A83209ACE; Wed, 22 Jan 2020 19:32:09 -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 JHFJU-aflk_3; Wed, 22 Jan 2020 19:32:08 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id C65F93213552; Wed, 22 Jan 2020 19:32:08 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar C65F93213552 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1579732328; bh=Ykj1xeeJGmEMiQc9+ajldL9+xrl7/uhr7Ht4lc8Wum0=; h=Date:From:To:Message-ID:MIME-Version; b=h85XlBbG4IO9yEnNkNeLvqWxVN1AXG3NLNmYVz8vHYgmXUY2QbLuYrhzbtK0CMBoy z8jpR/nwzFUrfBcfA2/Pb0gaBuRXVFW95dFogxXxFfPtG3Hkh8sGkm+2c5WtkPQa2v Hw4NBDUgRvtU7WZzuvmyAu+H9Zye5qm2JuwjddPM/H9ZfKMly3G7nE9k/r0YkGDBVF zzysy7eVajmAs1FBTSD553Pq7GoIBRtilxLn2BZsncQffK9J6evrDsd5fPvxXgoKw9 T3pkUJimz1RXBC99pJZZpJ8ox2nWECUcVcC9uwcq9SDZsu9DzKRiPWugw10hDNLgKD T0LERsyDtGZNg== 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 gAMSrlBc7E66; Wed, 22 Jan 2020 19:32:08 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 9FDF03209ACE; Wed, 22 Jan 2020 19:32:08 -0300 (-03) Date: Wed, 22 Jan 2020 19:32:08 -0300 (ART) From: Alejandro D'Egidio To: Fred Baker Cc: JORDI PALET MARTINEZ , "v6ops@ietf.org list" Message-ID: <1224124514.457960864.1579732328124.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: References: <4B73F334-E0B2-4302-AF5F-8267108ECDCE@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.12_GA_3803 (ZimbraWebClient - GC79 (Win)/8.8.12_GA_3794) Thread-Topic: draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** Thread-Index: KrjShQ9Maoj+gL3bBGseNVIREl0PLA== X-KSMG-Rule-ID: 1 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 150206 [Jan 23 2020] X-KSMG-AntiSpam-Version: 5.8.14.0 X-KSMG-AntiSpam-Envelope-From: adegidio@telecentro.net.ar X-KSMG-AntiSpam-Auth: dkim=pass header.d=telecentro.net.ar X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Info: LuaCore: 341 341 26ad2aac06c26f4a4a73fd0d2e1fb4067492b8ef, {Tracking_content_type, plain}, {Tracking_from_domain_doesnt_match_to}, telecentro.net.ar:7.1.1; www.ietf.org:7.1.1; mail.telecentro.net.ar:7.1.1; 127.0.0.199:7.1.2; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean, bases: 2020/01/22 21:47:00 X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.12, bases: 2020/01/22 16:59:00 #14967065 X-KSMG-AntiVirus-Status: Clean, skipped Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2020 22:32:16 -0000 Hello Fred, I hope you are well. I'm sorry for the delay, I was on vacations. I'm working with our cablemodem vendor in a prototype but as this is a very= new feature and we are both working in many other projects. Despite that, I've receive test version. For the moment I'm not able to have the traffic "optimized" but if I send a= A query from PC the proxy DNS on CPE sends both A and AAAA query. Regards, Alejandro ----- Mensaje original ----- De: "Fred Baker" Para: "JORDI PALET MARTINEZ" CC: "v6ops@ietf.org list" Enviados: Viernes, 17 de Enero 2020 16:22:13 Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Ado= ption** On Jan 15, 2020, at 2:38 PM, JORDI PALET MARTINEZ wrote: > No doubt, that I will review as many times as needed, all the possible = =E2=80=9Cflows=E2=80=9D and interactions to make sure that the text in the = document is working and not breaking anything. Is it fair to assume that Alejandro, your co-author, has tested a prototype= in his network? _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jan 28 09:35:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3B512001A for ; Tue, 28 Jan 2020 09:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.336 X-Spam-Level: * X-Spam-Status: No, score=1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35Ic003R3bFL for ; Tue, 28 Jan 2020 09:35:34 -0800 (PST) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 2833E120044 for ; Tue, 28 Jan 2020 09:35:34 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id j17so515469pjz.3 for ; Tue, 28 Jan 2020 09:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=008iTIrJM7cJnpBWh75QYwADGpHzmxM7yyo7KQHvNRo=; b=tVtxaXFMhvOFgXiMsIszhm7I7G1f5wl04UnJv7gu5bvdfDSl7KEXDoG8fCf6FZNSzm jSvV5msNwXHTCJHdcLfhN52Pg1r4nKrqOniC/1Tlr+rLQcoK0kbEam8L5wTrX2ZA1RdE YDSDMMimfe+gMmRBvbwZzhUoB6CxkWtcOLqCVkzk7SD+Rxh/B9FvYda/leif962yB/Ss Si5SoO+c/rmVzvt2yBYeAf7n308LtA94z2s8vajhate5Pz+bxhvY7e/Wijr97gn/eWvF T2MiW2+jiOfCZP6469bsXWWXwxD8gUkhM91FF2Dh4n4UJslYc6PGIs1bcKLpiLQ4Koun kGZw== 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=008iTIrJM7cJnpBWh75QYwADGpHzmxM7yyo7KQHvNRo=; b=LaYDHbyLmVLrbgqlUrRc4a9sKdelXUlv4/HqlvEyC18nZ0BWrze+t03mNKKtigHqTS mL5+9PjN8eElBwvsVZPJlNahgKahKeLQ4fTYLuL/PvizCp8/iKESk3IrrsfQuw5HZNNy ZP80tsHl3xKSF+AKmb80L3yT+Rj3YwpTo2C2Pr3mZVWEhvhXrvo6hD3qzeumUB3i7O6+ CP5SoyVcawEvJrKbpvMf4tL9CaJ615aLgAJuuQQ+/sTQ8skDqPbLPABKlMjoswSPn03Y zkhP/lLszFo1+opTDty0KPNBILo8hasXKNsqEn0bxPt+NyuEY2V+z9r3iqQfZqNA1iho nFqQ== X-Gm-Message-State: APjAAAW8rFE4FCwqFjJnATZ95r0RCyK1mVRPe9zEL7PsfaBrCtHSd1tr dFbugktmgHyF9aqsxKglFBcg/9tw X-Google-Smtp-Source: APXvYqwAkTPAFSF+pZQr2RyUpokCLa+ExkcOPJgY6J1nz8z/em8JiDFxw2OrwIDuxSZHz8fD9YJS0A== X-Received: by 2002:a17:902:aa0b:: with SMTP id be11mr22903728plb.181.1580232933604; Tue, 28 Jan 2020 09:35:33 -0800 (PST) Received: from [172.20.3.120] (rrcs-74-87-33-234.west.biz.rr.com. [74.87.33.234]) by smtp.gmail.com with ESMTPSA id w5sm3556820pjt.32.2020.01.28.09.35.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jan 2020 09:35:32 -0800 (PST) From: Fred Baker Message-Id: <2E6A32F1-61A2-4187-8767-8EB5D646CC78@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DD8939DD-8C75-4A72-BBB7-6AC03AAA5D94"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Tue, 28 Jan 2020 09:35:31 -0800 In-Reply-To: <1224124514.457960864.1579732328124.JavaMail.zimbra@telecentro.net.ar> Cc: JORDI PALET MARTINEZ , "v6ops@ietf.org list" To: Alejandro D'Egidio References: <4B73F334-E0B2-4302-AF5F-8267108ECDCE@consulintel.es> <1224124514.457960864.1579732328124.JavaMail.zimbra@telecentro.net.ar> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Jan 2020 17:35:38 -0000 --Apple-Mail=_DD8939DD-8C75-4A72-BBB7-6AC03AAA5D94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks. I'm asking what I hope is the obvious "so what" question. Do we = have a prototype (it sounds like the answer is "almost"), and do we find = the recommendation to make a valuable improvement in the real world? > On Jan 22, 2020, at 2:32 PM, Alejandro D'Egidio = wrote: >=20 > Hello Fred, > I hope you are well. > I'm sorry for the delay, I was on vacations. >=20 > I'm working with our cablemodem vendor in a prototype but as this is a = very new feature and we are both working in many other projects. > Despite that, I've receive test version. > For the moment I'm not able to have the traffic "optimized" but if I = send a A query from PC the proxy DNS on CPE sends both A and AAAA query. >=20 >=20 > Regards, > Alejandro >=20 > ----- Mensaje original ----- > De: "Fred Baker" > Para: "JORDI PALET MARTINEZ" = > CC: "v6ops@ietf.org list" > Enviados: Viernes, 17 de Enero 2020 16:22:13 > Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call = for Adoption** >=20 > On Jan 15, 2020, at 2:38 PM, JORDI PALET MARTINEZ = wrote: >> No doubt, that I will review as many times as needed, all the = possible =E2=80=9Cflows=E2=80=9D and interactions to make sure that the = text in the document is working and not breaking anything. >=20 > Is it fair to assume that Alejandro, your co-author, has tested a = prototype in his network? >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_DD8939DD-8C75-4A72-BBB7-6AC03AAA5D94 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+AFAl4wcOMACgkQEhdRnd2G P+BWag/+Mz2kXUHo2+9uMYZ/3w0Yei2A8MSUEwC7Pu3vsh80b27E+ELCLUXPSJop 7q3/gL6lauPv3i5kEAhEPt6Nbh0ABfw7zs6D5NyX8ZXQrjWzBPxs974yFEmZLSmY vENLOENXfWHuSPU3zL62a7dZSI7C3qaxla6zlqgPL8x28kk26aID413ucuE+Fk5t MKYpr+TLvLqyre7E5VkTMv/gCy4GyKeOuoXxF6tYdrLiqsSQu/CxUvAZnSwPdipt nSPJuAOfDw/ZNpsOuOIa8CoyJQ5yEualIrf7g170hOltDf/9iUhTjMDOV/DIkSUT m4uCauYAuBTb9oq9wbAciXtiZ99puboSbOMeMLw9Ah1i9RW0c8sO1eGJReZGJExz FcLgZMaXlnbnH+svN7mOUx4DDrF7/IKpur/91mJvyGs+zljxHrTOg3c/gbslwTq5 pavycgr6OcITRFY4qvSRlkjmXIeiBzMwV+KBTPdAhpTK0MlOrqMoOlkyTLK6xeAa ZE1ZlVbNQJBrly352DCp9SpMMDeAhbEZ9hSAgn07hyapcexnpd+YT8fWQE9Afwb8 aH2mwkFb1AiEmaNeu8VQg4qXi8+6SF97Jj6kX+wGMRWkzy7OeGrQcEHVC/jBEZkZ rfoABsIPfcG0H6bv95A7U5vRdgm302NUepBYMb9BXTu1ZU48zqM= =jpI+ -----END PGP SIGNATURE----- --Apple-Mail=_DD8939DD-8C75-4A72-BBB7-6AC03AAA5D94-- From nobody Fri Jan 31 12:16:49 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524CD120088 for ; Fri, 31 Jan 2020 12:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym8odEtKb8X3 for ; Fri, 31 Jan 2020 12:16:44 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF06120043 for ; Fri, 31 Jan 2020 12:16:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 00VKGXXh005558 for ; Fri, 31 Jan 2020 21:16:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BB1AA207AA8 for ; Fri, 31 Jan 2020 21:16:33 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B10DA207926 for ; Fri, 31 Jan 2020 21:16:33 +0100 (CET) Received: from [10.11.240.17] ([10.11.240.17]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 00VKGXJ5011216 for ; Fri, 31 Jan 2020 21:16:33 +0100 From: Alexandre Petrescu To: "v6ops@ietf.org" References: Message-ID: <64a3ebd9-b9b8-8dcf-8d08-9d5cf8fb8c75@gmail.com> Date: Fri, 31 Jan 2020 21:16:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] CPE without IPv6 and without NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jan 2020 20:16:46 -0000 Please excuse posting on a topic out of the timeline of the WG. I have been reported and been given to try it remotely, a CPE that does not do IPv6, does IPv4 but does not do NAT. It is used in house at mister lambda on fiber. The ISP is SFR but that is not important, and the testers are not associated with them. Through this CPE box the end user's laptop obtains a publicly routable IPv4 address in the range 88.something if I recollect correctly (it might be something else like 81 or so). The IPv4 address is then pingable from elsewhere from the Internet (I pinged). And there is an openvpn server for lecture at University for this. Students learn it. After calculations, it might be that one or two class As might be sufficient to manage probably all clients of this ISP size, and all their devices. Once this mode is used (there are two modes in this CPE: router and another one) the CPE can no longer be managed remotely, but the device_s_ in house are reachable from the Internet. This test makes me understand better when I discussed in private with engineer from SFR and was told that IPv6 is not important to them. Again, this test was suggested by somebody else completely different than SFR, there is no commercial interest from me on this. Alex