Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sun, 19 November 2017 10:15 UTC

Return-Path: <prvs=14969faf01=jordi.palet@consulintel.es>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB71812700F for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 02:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es 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 IZqg6a3ZElAc for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 02:15:11 -0800 (PST)
Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C99126DED for <ipv6@ietf.org>; Sun, 19 Nov 2017 02:15:10 -0800 (PST)
X-MDAV-Processed: mail.consulintel.com, Sun, 19 Nov 2017 11:15:08 +0100
Received: from mail.consulintel.es by mail.consulintel.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v11.0.3) with ESMTP id md50000952571.msg for <ipv6@ietf.org>; Sun, 19 Nov 2017 11:15:07 +0100
X-Spam-Processed: mail.consulintel.com, Sun, 19 Nov 2017 11:15:07 +0100 (not processed: spam filter heuristic analysis disabled)
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Return-Path: prvs=14969faf01=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511086171; x=1511690971; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=Uz8TBocArOnbs/FCV+p8hww6w 3GfSsARV0vT+JegIeM=; b=h9Mw656tSP5c6K3274ki6O1B6y9G5qRjRgNg+zN6p FlhmWxpQLeg39w6WRYhlNMpjUvF/wNANHDcXFEcJ1gxDsukQhV4qpSK45GSZilON lkOG7GBiY3xqED3c7GH32Qxe0OvVe14IPruKZc2qXEvGT51v7cOTxHfej5CKmfpp B4=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=EussYhahRGyk8Rjrva4Ax8XqtKSD/aQAw0TEc1agr5EiHJYQZ4Plkyv2aYIF YD2TZHjBwKdE6cvKAV0Gh0paXP0xDSPflqqtn6jmjh+QA8z6DPyFzj4Kr yqF1G5a/40WymwU/87sKVHLWCuZ1QSYjF/ICIl71Y0g76kVI0hde4I=;
X-MDAV-Processed: mail.consulintel.es, Sun, 19 Nov 2017 11:09:31 +0100
X-Spam-Processed: mail.consulintel.es, Sun, 19 Nov 2017 11:09:30 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005629749.msg for <ipv6@ietf.org>; Sun, 19 Nov 2017 11:09:29 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:171119:md50005629749::vlV9XC7vfx4u57CR:00007+UO
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Sun, 19 Nov 2017 07:39:05 +0000
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <6F8C95C5-5106-43AC-A888-F1B38256EA1C@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <CAFU7BARaJHKOyrD1KAeorbYQwgsmxBLk1QELH+wZ4=HDCP1q-w@mail.gmail.com> <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com> <CFDD8D9E-0726-46C1-9CC7-5C88DD111E9D@employees.org>
In-Reply-To: <CFDD8D9E-0726-46C1-9CC7-5C88DD111E9D@employees.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JnvamrjW8pn1nFKbQV6G7HB9pB0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 10:15:14 -0000

Fully agree with Ole, but not in one specific point …

-> We want a situation where IPv4 only services are fronted by IPv6, and the cost born by those operating those services.

I don’t see an easy way for people with IPv4-only services to pay for the cost. If I’m an ISP and want to connect customers to Internet, even if I deploy IPv6, if I don’t provide myself a NAT64 (probably together with CLAT at the CEs), my customers will go away, because I’ve no solution to “charge” the cost of my NAT64 to the “bad and outdated” service providers that rely only in IPv4 (and IPv4-only DNSSEC).

Also, if I want customers that have IPv4-only devices at home, I still need to provide some sort of IPv4-as-a-service for that.

If we pretend that to happen, either we find a *real* way to make responsibles of the cost to the “ugly” content providers, or we will fail again as we failed assuming that dual-stack will be deployed at the right time so we can turn-off IPv4.

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de Ole Troan <otroan@employees.org>
Responder a: <otroan@employees.org>
Fecha: domingo, 19 de noviembre de 2017, 1:03
Para: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
Asunto: Re: IPv6 only host NAT64 requirements?

    Brian,
    
    > To be clear: I used ietf-nat64 all week, and all the things that didn't work
    > are not an issue on a dual-stack network. From the host's point of view,
    > dual-stack is definitively superior, IMNSHO, and nothing is going to
    > change that. NAT64 is second-best. It may appear to be cheaper for some
    > operators in some scenarios, that's all.
    
    From that perspective, "IPv4 only" is still best. But that's not where we want to be, is it?
    
    The original transition plan was for all networks, hosts and application to be dual-stacked, then when that point was reached, there would be no more traffic on the "IPv4 Internet" and it could be turned off. We now know that this point is not within sight.
    
    Dual-stack as a transition is a failure. Dual-stack is a deployment model where we bear the cost caused by the IPv4 laggards.
    
    IPv6 only + NAT64 is progress. It relegates IPv4 to the edges.
    We want a situation where IPv4 only services are fronted by IPv6, and the cost born by those operating those services.
    
    The challenge we have in front of us is to make IPv6 only work.
    
    Ole
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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.