Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 21 November 2017 10:07 UTC

Return-Path: <prvs=14985c1375=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 0D478129462 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 02:07:42 -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 FSFyabK6gfkJ for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 02:07:40 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA58129443 for <ipv6@ietf.org>; Tue, 21 Nov 2017 02:07:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511258846; x=1511863646; 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=dE+kzhNaaYCPFF0KsTuIhElGC onszD66wZEYh1dPJYk=; b=XHNKfxFwPcDwVeqRVORRqwpklKAycLvFBJsiwgdcY vjxs/n5EPU1K+DAO1K1z/HOguwREaTdNm2GKhF22W/ZB9C0xHRYfVZgSWQ7oo9+q UGM8so28zYrXvsgbe1+fZqtZ47NJaot4sFW/rixCGTDnfr1ed103KCk312AGsuSa QY=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=eijbGwpyNe5if29CxYrwJlIFVzyvoll6HcYdsFl4vNdx7jkKnipwGuw46mFc YOkjzjQVzgNv+HHPXpASOWhM61DtrnwQ0IViv4ndZuyOKuCUt3NtI6daW NxYDp/0EXvAA4yxca5t+Gt5uZ6zgH7D/k/c+wWDmNpAGVF6s6swzvk=;
X-MDAV-Processed: mail.consulintel.es, Tue, 21 Nov 2017 11:07:24 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 21 Nov 2017 11:07:22 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005633641.msg for <ipv6@ietf.org>; Tue, 21 Nov 2017 11:07:21 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:171121:md50005633641::zqYh3JNZCoKQigyi:000050VJ
X-Return-Path: prvs=14985c1375=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Tue, 21 Nov 2017 11:07:14 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: ipv6@ietf.org
Message-ID: <10F26994-3EC2-4998-84EC-09486743D7CE@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAFU7BARoXgodiTJfTGc1dUfQ8-ER_r8UOE1c3h-+G0KTeCgBew@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <F9E3BD88-38E0-4329-A4BF-22083A023268@employees.org> <f673d6c7-570e-b2b8-e8aa-15d73ea8ba3f@gmail.com> <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no>
In-Reply-To: <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lABwIrHQJV-479a4HDFT3DY1FYs>
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: Tue, 21 Nov 2017 10:07:42 -0000

I will even say that introducing NAT64+CLAT will solve more problems that if there is NAT+CGN or NAT+CGN+NAT64.

As you indicate, the support for IPv6 will resolve 99.99% of the issues for dual-stacked services and I think NAT64 will improve the % of failures vs CGN+NAT, and if the 464XLAT is properly configured, only a few % of remote IPv4-only-DNSSEC services will fail. 

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de Ola Thoresen <ola@nlogic.no>
Responder a: <ola@nlogic.no>
Fecha: martes, 21 de noviembre de 2017, 10:40
Para: <ipv6@ietf.org>
Asunto: Re: IPv6 only host NAT64 requirements?

    On 20. nov. 2017 20:37, Brian E Carpenter wrote:
    
    > On 21/11/2017 02:36, Ole Troan wrote:
    > ...>> [Med] These are generic statements, Ole. We are talking about the IETF case.
    >>> * The IETF has no control on the hosts that connect to the IETF network,
    >>> * IETF attendees who are using corporate devices, have no control on these hosts
    >>>
    >>> So, how forcing devices to use "IPv6+nat64" will help here?
    >> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
    >> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.
    > However, as long as even one application, such as one VPN, or one
    > literal IPv4 address, fails, that represents millions of failure cases
    > if we consider the whole world (e.g. imagine every hotel network in
    > the world running IPv6+NAT64 only). That simply isn't viable. Dual
    > stack in every hotel room in the world is viable, from the hotel guests'
    > point of view. Operators might not like it, but users wouldn't care.
    
    In hotel rooms and other "public" or "guest" networks, there are so many 
    things that fail already, due to NAT, misconfigured firewalls, 
    unmaintained blocklists, SSL-proxies and whatnot, so you can hardly 
    expect any services other than basic web-surfing without https to work.
    Not that this is an ideal situation today, but i do not believe that "if 
    even one VPN or one liter IPv4 address fails" should be a showstopper 
    for introducing this.
    Possibly, or even probably, introducing IPv6 (-only and NAT64) will even 
    make the situation better for a lot of people, as you get rid of all the 
    horrible NAT solutions for services that are already dual stacked.
    
    
    Rgds.
    
    Ola Thoresen
    
    --------------------------------------------------------------------
    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.