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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 05 Jan 2020 21:56:40 +0100

Hi Fernando,

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

El 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio" <[email-masked] en nombre de adegidio=[email-masked]> 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" <[email-masked]>
    > Para: "Ron Bonica" <rbonica=[email-masked]>, "[email-masked] list" <[email-masked]>
    > 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
    >> [email-masked]
    >> https://www.ietf.org/mailman/listinfo/v6ops
    >> 
    > 
    > 
    > --
    > Fernando Gont
    > SI6 Networks
    > e-mail: [email-masked]
    > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
    > 
    > 
    > 
    > 
    > _______________________________________________
    > v6ops mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/v6ops
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    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.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 6 Jan 2020 16:35:49 +0800

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.
 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: [email-masked] list
Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
Hi Fernando,

 
    Hello Fernando,

    Regards,
    Alejandro

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 6 Jan 2020 09:42:41 +0100

1/6/2020 9:35 AM keltezéssel, [email-masked] írta:
> 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=[email-masked]>
>     *Date:* 2020-01-06 04:56
>     *To:* [email-masked] list <mailto:[email-masked]>
>     *Subject:* Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches
>     **Call for Adoption**
>     Hi Fernando,
>     El 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio"
>     <[email-masked] en nombre de
>     adegidio=[email-masked]> 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.
>         > De: "Fernando Gont" <[email-masked]>
>         > Para: "Ron Bonica" <rbonica=[email-masked]>,
>     "[email-masked] list" <[email-masked]>
>         > 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, 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.
>         >
>         >
>         >
>         > *** 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.
>         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.
>         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.
>         >
>         >
>         > * 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.
>         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.
>         >
>         > 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
>         >> [email-masked]
>         >> https://www.ietf.org/mailman/listinfo/v6ops
>         >>
>         >
>         >
>         > --
>         > Fernando Gont
>         > SI6 Networks
>         > e-mail: [email-masked]
>         > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55
>     1D4E 7492
>         >
>         >
>         >
>         >
>         > _______________________________________________
>         > v6ops mailing list
>         > [email-masked]
>         > https://www.ietf.org/mailman/listinfo/v6ops
>     This electronic message contains information which may be
>     privileged or confidential. The information is intended to be for
>     the exclusive use of the individual(s) named above and further
>     non-explicilty authorized disclosure, copying, distribution or use
>     of the contents of this information, even if partially, including
>     attached files, is strictly prohibited and will be considered a
>     criminal offense. If you are not the intended recipient be aware
>     that any disclosure, copying, distribution or use of the contents
>     of this information, even if partially, including attached files,
>     is strictly prohibited, will be considered a criminal offense, so
>     you must reply to the original sender to inform about this
>     communication and delete it.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 6 Jan 2020 16:50:59 +0800

Hi, Gábor,
I see, thank you!
Chongfeng
 
From: Lencse Gábor
Date: 2020-01-06 16:42
To: v6ops

Hi，Jordi,

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

Best regards

Chongfeng 

 
 
    Hello Fernando,

    Regards,
    Alejandro

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 06 Jan 2020 09:54:18 +0100

Hi Chongfeng,

Thanks for your inputs, comments below, in-line.

Regards,

Jordi

@jordipalet

El 6/1/20 9:36, "v6ops en nombre de [email-masked]" <[email-masked] en nombre de [email-masked]> escribió:

Hi，Jordi,

The document is looking for an optimization to 464XLAT in order to avoid double translation when IPv4-only clients, access any IPv6 available content. Precisely, our approach is trying to choose the option that avoids additional network configuration.

I don’t really agree on that. It makes a lot of sense, especially for operators that use 464XLAT in cellular, to have a single transition mechanism if they also have broadband networks. This also simplify the use of “hybrid” CPEs, where you have, for example, a GPON link, and a backup link via 3G/4G/5G.

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

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

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

Best regards

Chongfeng 

Date: 2020-01-06 04:56

To: [email-masked] list

Hi Fernando,

    Hello Fernando,

    

    Regards,

    Alejandro

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

    

    

    

    v6ops mailing list

    [email-masked]

 

IPv4 is over

The IPv6 Company

 

v6ops mailing list

[email-masked]

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

---

From: Fernando Frediani <[email-masked]>
Date: Mon, 6 Jan 2020 13:00:33 -0300

> seperate layer-two channle, which does not mix with the default 

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 <[email-masked]>
Date: Mon, 06 Jan 2020 17:10:18 +0100

In fact, we are working with several candidate vendors for several projects.

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

Regards,

Jordi

@jordipalet

El 6/1/20 17:01, "v6ops en nombre de Fernando Frediani" <[email-masked] en nombre de [email-masked]> escribió:

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

To: [email-masked] list

Hi Fernando,

    Hello Fernando,

    

    Regards,

    Alejandro

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

    

    

    

    v6ops mailing list

    [email-masked]

 

IPv4 is over

The IPv6 Company

 

v6ops mailing list

[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jan 2020 23:05:02 -0800

> On Jan 6, 2020, at 12:42 AM, Lencse Gábor <[email-masked]> wrote:
> 
> 
> 

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

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. 

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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 7 Jan 2020 22:09:48 +0800

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

 

 
    Hello Fernando,

    Regards,
    Alejandro

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 08 Jan 2020 15:11:24 +0100

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 [email-masked]" <[email-masked] en nombre de [email-masked]> escribió:

Hi，Fernando,

Best regards

Chongfeng

From: Fernando Frediani

Date: 2020-01-07 00:00

To: v6ops

Regards
Fernando Frediani

Date: 2020-01-06 04:56

To: [email-masked] list

Hi Fernando,

    Hello Fernando,

    

    Regards,

    Alejandro

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

    

    

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

    

    v6ops mailing list

    [email-masked]

 

IPv4 is over

The IPv6 Company

 

v6ops mailing list

[email-masked]

---

From: Fernando Frediani <[email-masked]>
Date: Wed, 8 Jan 2020 11:45:29 -0300

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.
>
> El 7/1/20 15:10, "v6ops en nombre de [email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]> en nombre de [email-masked] 
> <mailto:[email-masked]>> 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 <mailto:[email-masked]>
>
>     *Date:* 2020-01-07 00:00
>
>     *To:*v6ops <mailto:[email-masked]>
>
>     On 06/01/2020 05:35, [email-masked]
>     <mailto:[email-masked]> 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
>             <mailto:jordi.palet=40consulintel.es@dmarc..ietf.org>
>
>             *Date:* 2020-01-06 04:56
>
>             *To:[email-masked] list <mailto:[email-masked]>
>
>             *Subject:* Re: [v6ops]
>             draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
>
>             Hi Fernando,
>
>             adegidio=[email-masked]>
>             <mailto:[email-masked]=40telecentro.net.ar@dmarc..ietf.org>
>             escribió:
>
>             Hello Fernando,
>
>             <mailto:[email-masked]>
>
>             > Para: "Ron Bonica"
>             <rbonica=[email-masked]>
>             <mailto:rbonica=[email-masked]>,
>             "[email-masked] list" <mailto:[email-masked]>
>             <[email-masked]> <mailto:[email-masked]>
>
>             > Asunto: Re: [v6ops]
>             draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
>
>             > Folks,
>
>             >
>
>             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.
>
>             >
>
>             -> 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.
>
>             >
>
>             -> 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, 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)..
>
>             >
>
>             -> 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.
>
>             As we know, CLAT is a combination of NAT46 + SIIT because
>             it's an stateless translation from IPv4 to IPv6.
>
>             >
>
>             >
>
>             > * Introduction:
>
>             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:
>
>             -> 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.
>
>             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:
>
>             -> I think it is clear if you read the paragraph before
>             that one. Otherwise we could expand the text to make it
>             more obvious.
>
>             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:
>
>             -> 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:
>
>             >   address..  A web page IPv4-only hosted by IETF(?)
>             showing "sorry this
>
>             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).
>
>             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:
>
>             >> [email-masked] <mailto:[email-masked]>
>
>             > e-mail: [email-masked] <mailto:[email-masked]>
>
>             > [email-masked] <mailto:[email-masked]>
>
>             [email-masked] <mailto:[email-masked]>
>
>             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.
>
>             [email-masked] <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents of 
> this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you 
> are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited, will be 
> considered a criminal offense, so you must reply to the original 
> sender to inform about this communication and delete it.
>
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Jan 2020 09:46:10 -0300

On 8/1/20 11:11, JORDI PALET MARTINEZ wrote:
> 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,

---

From: Ca By <[email-masked]>
Date: Thu, 9 Jan 2020 06:22:03 -0800

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

---

From: <[email-masked]>
Date: Thu, 9 Jan 2020 14:54:24 +0000

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.

Cheers,
Med

De : v6ops [mailto:[email-masked]] 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 <[email-masked]<mailto:[email-masked]>> wrote:

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: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lencse Gábor <[email-masked]>
Date: Thu, 9 Jan 2020 16:13:57 +0100

1/9/2020 3:54 PM keltezéssel, [email-masked] í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:[email-masked]] *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**
>

---

From: [email-masked]
Date: Thu, 9 Jan 2020 18:40:50 +0100

>    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

---

From: Ca By <[email-masked]>
Date: Thu, 9 Jan 2020 11:03:49 -0800

On Thu, Jan 9, 2020 at 9:41 AM <[email-masked]> wrote:

> 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’t believe there is a meaningful scaling function difference.  I
don’t know the details 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 horizontally.  Yes, each NAT64 needs a unique ipv4 pool, but it’s
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.

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Jan 2020 20:22:29 +0100

> On 9 Jan 2020, at 20:04, Ca By <[email-masked]> wrote:
> 
> 
> 
> 
> eh, i don’t believe there is a meaningful scaling function difference.  I don’t know the details 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 horizontally.  Yes, each NAT64 needs a unique ipv4 pool, but it’s 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. 

All solutions have stateful NATs. It’s just a question if you have one, two or three (in this case one is stateless though).  In a MAP solution the CPE NAT can also operate in endpoint dependent mode. 

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

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

Cheers 
Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 09 Jan 2020 21:33:51 +0100

Hi Ole,

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

There are CapEx and OpEx impacts that may be different when you need to deliver IPv6-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 example) GPON and a backup link via 3/4/5G. Again, because in cellular the only choice is 464XLAT, it becomes much easier (and cheaper) to use also 464XLAT in the main broadband link.

Regards,

Jordi

@jordipalet

El 9/1/20 20:22, "v6ops en nombre de Ole Troan" <[email-masked] en nombre de [email-masked]> escribió:

 

Not allegedly.

Cheers,
Ole

Cheers 

Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Jan 2020 11:29:13 -0300

> sessions a user can dynamically create. 

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

Thanks,

---

From: Ca By <[email-masked]>
Date: Fri, 10 Jan 2020 09:16:46 -0800

> 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’s say, 1,000 subscriber
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.