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

["[e-mail]" <[e-mail]>]

Hi, Gábor,
I see, thank you!
Chongfeng
 
From: Lencse Gábor
Date: 2020-01-06 16:42
To: v6ops
Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**


1/6/2020 9:35 AM keltezéssel, [e-mail] í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] 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
Date: 2020-01-06 04:56
To: [e-mail] 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" <[e-mail] en nombre de adegidio=[e-mail]> 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" <[e-mail]>
    > Para: "Ron Bonica" <rbonica=[e-mail]>, "[e-mail] list" <[e-mail]>
    > 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
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/v6ops
    >> 
    > 
    > 
    > --
    > Fernando Gont
    > SI6 Networks
    > e-mail: [e-mail]
    > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
    > 
    > 
    > 
    > 
    > _______________________________________________
    > v6ops mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/v6ops
    
    _______________________________________________
    v6ops mailing list
    [e-mail]
    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
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops