Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Mar 2019 10:53:56 +0100

One important consideration that I missed in the submitted version.

In the case of the "operator provided EAMT" (section 5), there is no need to have a "match" with the AAAA records. So, we can have for example:
www.example.com                   A       192.0.2.1
                                  AAAA    2001:db8::192.0.2.2
EAMT pushed entry              192.0.2.1  2001:db8::192.0.2.33
CLAT translated to                        2001:db8::192.0.2.33
CDN IPv6 interface already is             2001:db8::192.0.2.33
Operator already has a specific route to  2001:db8::192.0.2.33

The problem of this alternative is now to "renew" the EAMT info, with will depend on the mechanism to tell the CE (or the CE to ask if we go for a pull instead of a push) ...

One more issue, how much time the EAMT information is kept in the case of the "automated" EAMT (section 4). May be with every A record request this entry should be cleared and otherwise use the default TTL from the A record?. This seems to avoid having a mechanism to configure the table at the CE.

I think the information that the CDN operators can provide will be key to determine which approach is better, or may be to figure out new approaches.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Jordi Palet Martínez <jordi.palet=[email-masked]>
Fecha: miércoles, 6 de marzo de 2019, 10:22
Para: "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

    Hi all,
    
    I've submitted this document after the questions from Alejandro for CDN optimization with IPv4aaS.
    
    https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/
    
    I think, in addition to operators, it will be interesting to have the views of CDN/cache operators, not sure if we have people related to this in the list, such as Akamai, Netflix, AWS, Facebook, Google, etc.
    
    We know that today some of them already do this optimization to avoid the CGN when using the 100.64.0.0/10 prefix.
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: <[email-masked]>
    Fecha: miércoles, 6 de marzo de 2019, 10:10
    Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
    Asunto: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

        A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
        has been successfully submitted by Jordi Palet Martinez and posted to the
        IETF repository.
        
        Name:		draft-palet-v6ops-464xlat-opt-cdn-caches
        Revision:	00
        Title:		464XLAT Optimization for CDNs/Caches
        Document date:	2019-03-06
        Group:		Individual Submission
        Pages:		9
        URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/
        Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-caches-00
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6ops-464xlat-opt-cdn-caches

        Abstract:
           This document describes the drawbacks of IP/ICMP Translation
           Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
           applications initiate traffic flows to dual-stack CDNs (Content
           Delivery Networks) or Caches, which are forced to be translated back
           to IPv4 by a NAT64.  The document proposes possible solutions to
           avoid that.

        
        Please note that it may take a couple of minutes from the time of submission
        until the htmlized version and diff are available at tools.ietf.org.
        
        The IETF Secretariat

    **********************************************
    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
    [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: Alejandro D'Egidio <[email-masked]>
Date: Wed, 6 Mar 2019 16:57:20 -0300 (ART)

Hello Jordi,
Thanks for helping with this scenario of CDNs, please let's work together on it.
As a summary you consider these scenarios always in a IPv6-only access network (which is the case):
1- IPv6 capable device/app: it can directly connects to IPv6 service (CDN, etc).
2- IPv4 only device/app: they need to use a PLAT to access to the service.

I think we can include, as a part of introduction, the actual case of why ISPs need to continue providing IPv4 to have a direct connection to CDNs avoiding CGN, something like:
                                               .--+--.	
                                              /       \
                                             /  IPv4   \
                                            (  Internet )
                                            /\         /
                                           /  \       /\
                                          /    `-----'  \
                  +-------+     .-----.  /               \  .-----.
                  | IPv6  |    /       \/                 \/ Dual- \
      .-----.     |  CE   |   /         \     .-----.     /  Stack  \
     / IPv4- \    |  or   +--(   DS      )---(  CGN  )---(           )
    /  only   \   |  UE   |   \  Access /\    `-----'     \  CDNs/  /
   (  SmartTV  )--+       |    \       /  \                \ Caches/
    \   STB   /   | with  |     `-----'    \   .-----.    / `--+--'
     \ VoIP  /    |       |                 \ /       \  /
      `-----'     | CLAT  |                  /  IPv6   \/ 
                  |   +   |                 (  Internet )
                  | IPv4- |                  \         /
                  |  CGN  |                   \       /  
                  +-------+                    `-----'   

Showing that private IPv4 (typically 100.64.0.0/10) can connect directly to CDNs with public IPv4.

After the text:
"As show in the precedent picture, this is also the case for other
   services, not just CDNs or caches, such as VoIP access to the
   relevant operator infrastructure, which may be also dual-stack, but
   is not commonly the case for many VoIP devices or applications."

Can be included a note saying that this is the scenario where ISPs and CDNs need to have a direct connection without CGN avoiding the sizing and translation impact of CGN.

About the approachings:
DNS/Routing-based Solution Approach: I think that is a good idea. The thing here is to know how possible is this to be considered by CNDs. Also, this scenario is just possible if CPE is in router mode.

CLAT/DNS-proxy-EAMT-based Solution Approach: I think this is a better approach where is not necessary to modify anything in CDNs.
I see two things:
a. How long is the timeout of the EAMT entry?
b. How to determine which FQDNs CLAT needs to verify if there is an AAAA record? If it tries with all A records it can have a service impact (more delay thinking about a lot of queries per second).

CLAT-provider-EAMT-based Solution Approach: Really hard to implement and to maintain. It depends on features of provisioning systems. With CM we can think on:
Push this information to millions of devices using SNMP and pray to all CMs are online what is not true because there are always CMs offline.
Include this information into a config-file and restart all CMs!?

For both cases how to update some change to all CMs?

I think the best approach is CLAT/DNS-proxy but I'm worried about A record queries delay where destination is an external service.

Regards,
ALEJANDRO D'EGIDIO 
Jefe de Ingeniería de Backbone | Dirección de Ingeniería 
M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 11 3977-1025 | +54 11 3977-1025 ] | [ mailto:[email-masked] | [email-masked] ] 
Pje. Lavardén 157. Piso 3. CABA (C1437FBC)

----- Mensaje original -----
De: "JORDI PALET MARTINEZ" <jordi.palet=[email-masked]>
Para: "[email-masked] list" <[email-masked]>
Enviados: Miércoles, 6 de Marzo 2019 6:53:56
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Jordi Palet Martínez <jordi.palet=[email-masked]>
Fecha: miércoles, 6 de marzo de 2019, 10:22
Para: "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

    Hi all,

    

    Regards,
    Jordi

    -----Mensaje original-----
    De: <[email-masked]>
    Fecha: miércoles, 6 de marzo de 2019, 10:10
    Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
    Asunto: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

        Abstract:

        
        
        The IETF Secretariat