Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 27 February 2019 06:19 UTC

Return-Path: <prvs=1961127b7a=jordi.palet@consulintel.es>
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 43E0E130E57 for <v6ops@ietfa.amsl.com>; Tue, 26 Feb 2019 22:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 1BPKlorH6pF0 for <v6ops@ietfa.amsl.com>; Tue, 26 Feb 2019 22:19:07 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6767012F1A6 for <v6ops@ietf.org>; Tue, 26 Feb 2019 22:19:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1551248343; x=1551853143; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=gXCU7Ljfnq3cfJUFLCpMe pJ7uZSgQLeZf6Z2Ujhn+4U=; b=nmx50EDuwVAtCQUKL3mzo4razjCpF5ju5ZZ+v lmB3OCxRbRcFOhZZlEPMG/ZCTI5lpDBVcnckpFRyMTf5gNfJRZxwhUD3XwODJauK GoJ5BMX7ytZRnoq/J9o8uJb0Lo6v2dAti3IKvDSGm593/cTlGhRjrnzRhjIiJ9Yb JpUXhk=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Wed, 27 Feb 2019 07:19:03 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 27 Feb 2019 07:19:02 +0100
Received: from [220.247.145.169] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006169252.msg for <v6ops@ietf.org>; Wed, 27 Feb 2019 07:19:01 +0100
X-MDRemoteIP: 10.8.10.10
X-MDHelo: [220.247.145.169]
X-MDArrival-Date: Wed, 27 Feb 2019 07:19:01 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1961127b7a=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.7.190210
Date: Wed, 27 Feb 2019 15:18:47 +0900
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Alejandro D'Egidio <adegidio=40telecentro.net.ar@dmarc.ietf.org>
CC: "v6ops@ietf.org list" <v6ops@ietf.org>
Message-ID: <86B7975E-87B1-44BE-8220-661A73A016B8@consulintel.es>
Thread-Topic: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Xystj-HcNFYF89fmMz6Kc7nC-Es>
Subject: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment
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: Wed, 27 Feb 2019 06:19:10 -0000

Hi Alejandro,

Thanks, I understand your point better now. I was thinking only that you mean IPv4-only CDN resources.

However, I believe that by using routing (I didn't actually try it myself, but I think it is simple to do), because the CLAT brings this IPv4-only as IPv6 traffic into your access/distribution network, so you can make sure to route more specifics prefixes directly to the CDN as IPv6, without going thru the NAT64 and then the CLAT will translate it back to IPv4 for the SmartTV.

So I don't think we need any additional "protocol" or change to 464XLAT to do that.

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Alejandro D'Egidio <adegidio=40telecentro.net.ar@dmarc.ietf.org>
Fecha: miércoles, 27 de febrero de 2019, 1:55
Para: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org list" <v6ops@ietf.org>
Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment

    Hello Jordi,
    
    All these big public CDNs work in dual-stack natively.
    The case is when we have a customer in dual-stack but behind CGN for IPv4 and he/she also has devices (or applications within those devices) that don't support IPv6 (e.g.: Smart TVs and Set-top-Boxes).
    This is the scenario:
                               +------------+
                               |            |
                               |Public CDN  |                                                Priv IPv4 +-----------+
                               |            |                                                          |           |
                               |            |                                                +---------+  SMART TV |
                               +------------+                                                |         |           |
                                     |Dual-Stack                                             |         +-----------+
                                     |Pub IPv4                                               |
                                     |GUA IPv6                                               |
                               +------------+       +------------------+                     |
    +-------------+            |            |       |                  |             +-------+-+ Priv  +-----------+
    |             |Dual-Stack  |            |       |                  |             |         | IPv4  |           |
    |  Internet   +------------+   Router   +-------+    ISP Network   +-------------+  CPE    +-------+  STB      |
    |             |            |            |       |                  |             |         |       |           |
    +-------------+            |            |       |                  |             +-------+-+       +-----------+
                               +-+--------+-+       +------------------+         Dual-Stack  |
                                 |        |                                      IPv4 CGN    |
                                 |        |                                      IPv6        |
                                 |        |                                                  |         +-----------+
                         Outside |        |Inside                                            |         |           |
                         Pub IPv4|        |IPv4 CGN                                          +---------+ Notebook  |
                               +------------+                                                Dual-Stack|           |
                               |            |                                                Priv IPv4 +-----------+
                               |  CGN       |                                                GUA IPv6
                               |            |
                               +------------+
    
    Notebook has dual-stack. It will prefer IPv6 to connect to CDN.
    Smart TV and STB don't have IPv6. They will usually need to go through CGN to connect to Public CDN.
    Some Public CDNs are supporting to receive connections from CGN addresses (usually 100.64.x.x). In this case we can avoid to go through CGN and have a direct connection between customers and CDN. Customers normally are behind NAT of CPEs but they can have a CPE in bridge mode.
    So, customers behind CGN don't need a CGN to connect to a public CDN installed within the ISP.
    
    This case is where I see the three points where an ISP can use to consider to don't have an IPv6-only access network:
    1- Traffic avoids a point of failure (CGN), obviously it should be redundant but the point of failure exists.
    2- Traffic is more "transparent" avoiding another translation for CDN.
    3- This traffic doesn't impact in CGN sizing.
    
    
    Regards,
    Alejandro
    
    ----- Mensaje original -----
    De: "JORDI PALET MARTINEZ" <jordi.palet=40consulintel.es@dmarc.ietf.org>
    Para: "Alejandro Degidio" <adegidio@telecentro.net.ar>
    CC: "v6ops@ietf.org list" <v6ops@ietf.org>
    Enviados: Lunes, 25 de Febrero 2019 22:12:12
    Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment
    
    Hi Alejandro,
    
    (removed dnsop, as this is not - I think - relevant for them)
    
    My understanding is that CDNs today have IPv6 already (at least the most important ones, the ones with more traffic). If that's the case, the traffic from the CEs, will be IPv6.
    
    Now, if a CDN don't have IPv6 support, in 464XLAT, the link is IPv6-only, so I don't see how we can change that.
    
    However, also I see that a possible solution for an IPv4-only CDN to support IPv6 in this scenario, may be via stateless NAT64, with pre-configured EAMT (RFC7757) rules or something similar and the relevant AAAA entries. I think this is more an operational issue than a new protocol.
    
    Clearly that means that you don't have that traffic in the stateful NAT64, which I understand is your main goal.
    
    Anyway, of course, the right thing for those IPv4-only CDNs will be to push them for IPv6 support! I will be nice if you can publicly name them ...
    
    That make sense to you?
    
    Regards,
    Jordi
     
     
    
    -----Mensaje original-----
    De: v6ops <v6ops-bounces@ietf.org> en nombre de Alejandro D'Egidio <adegidio=40telecentro.net.ar@dmarc.ietf.org>
    Fecha: martes, 26 de febrero de 2019, 0:24
    Para: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
    CC: "v6ops@ietf.org list" <v6ops@ietf.org>, dnsop <dnsop@ietf.org>
    Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment
    
        Hello Jordi,
        I like 464XLAT and this is something I would like to implement in DOCSIS networks.
        As Deployment Guidelines maybe you can include/consider the next case, if not please forget it or we can include it on another document.
        
        Today we still have many devices that don't support IPv6 or some applications on it don't support it, this is the case of SMART TVs and set top boxes.
        There is a common scenario where big public CDNs support deliver content to private IPv4 destinations (usually CGN prefixes) directly without going through a CGN.
        In that scenario, CPEs (with eRouter) that have IPv4 of CGN (ie 100.64.x.x) can connect receive traffic from CDNs directly without having any CGN in the middle.
        
        So I see three points in this case:
        1- Traffic avoids a point of failure (CGN), obviously it should be redundant but the point of failure exists.
        2- Traffic is more "transparent" avoiding another translation for CDN.
        3- This traffic doesn't impact in CGN sizing.
        
        As I said, I like 464XLAT and I would like to have a IPv6-Only access network but this is a real case where ISPs can consider to continue provisioning IPv4 to customers.
        
        
        
        Regards,
        Alejandro
        
        ----- Mensaje original -----
        De: "JORDI PALET MARTINEZ" <jordi.palet=40consulintel.es@dmarc.ietf.org>
        Para: "v6ops@ietf.org list" <v6ops@ietf.org>, "dnsop" <dnsop@ietf.org>
        Enviados: Jueves, 21 de Febrero 2019 2:58:36
        Asunto: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment
        
        Hi all,
        
        (dnsop copied because DNS64)
        
        I'm working in a new version of this document.
        
        Link to the document:
        
        https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/
        
        It will be great if we can get some new inputs.
        
        Thanks!
        
        Regards,
        Jordi
         
         
        
        
        
        **********************************************
        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
        
    
    
    
    **********************************************
    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
    



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