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