Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
Lencse Gábor <lencse@hit.bme.hu> Mon, 06 January 2020 08:43 UTC
Return-Path: <lencse@hit.bme.hu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E5F120098 for <v6ops@ietfa.amsl.com>; Mon, 6 Jan 2020 00:43: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, 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 z2hsAL4T35J8 for <v6ops@ietfa.amsl.com>; Mon, 6 Jan 2020 00:43:06 -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 BD6FC12001E for <v6ops@ietf.org>; Mon, 6 Jan 2020 00:43:05 -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 0068gl9S089579 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <v6ops@ietf.org>; Mon, 6 Jan 2020 09:42:52 +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: <FFB9FE6E-D2D2-46A2-8F2A-DB4E5534FE3E@consulintel.es> <2020010616354842655859@chinatelecom.cn>
From: Lencse Gábor <lencse@hit.bme.hu>
Message-ID: <ece61d11-8e91-0f7c-8ed9-5cd9fd1dad32@hit.bme.hu>
Date: Mon, 06 Jan 2020 09:42:41 +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: <2020010616354842655859@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="------------67103B3F52D4A2B4E6B9602F"
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: <https://mailarchive.ietf.org/arch/msg/v6ops/-LGCbQA56_oxWaZGRIz5BMeL6Mc>
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 <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2020 08:43:11 -0000
1/6/2020 9:35 AM keltezéssel, xiechf@chinatelecom.cn írta: > > 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 <https://www.iana.org/go/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 > > *From:* JORDI PALET MARTINEZ > <mailto:jordi.palet=40consulintel.es@dmarc.ietf.org> > *Date:* 2020-01-06 04:56 > *To:* v6ops@ietf.org list <mailto:v6ops@ietf.org> > *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> > > Para: "Ron Bonica" <rbonica=40juniper.net@dmarc.ietf.org>, > "v6ops@ietf.org list" <v6ops@ietf.org> > > 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
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… xiechf@chinatelecom.cn
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fred Baker
- [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches … Ron Bonica
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fernando Frediani
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Uesley Correa
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fernando Gont
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Alejandro D'Egidio
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fernando Frediani
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… xiechf@chinatelecom.cn
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Lencse Gábor
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… xiechf@chinatelecom.cn
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fernando Frediani
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Alejandro D'Egidio
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fernando Frediani
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fernando Gont
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Ca By
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Lencse Gábor
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… otroan
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Ca By
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Ole Troan
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Erik Nygren
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fernando Gont
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Ca By
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fred Baker
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Alejandro D'Egidio
- Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-cac… Fred Baker