IETF Logo Mail Archive

Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 13 November 2017 16:17 UTC

Return-Path: <otroan@employees.org>
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 E763F129B14 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 08:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 amJzQ0euE8ir for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 08:17:39 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D35F129B0E for <ipv6@ietf.org>; Mon, 13 Nov 2017 08:17:35 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id EE0072D4F99; Mon, 13 Nov 2017 16:17:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1EDF3200C0308E; Tue, 14 Nov 2017 00:17:10 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <991C27F8-26BE-4588-B8FA-D83531F8742D@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_9F523B89-A781-4CA7-BACD-CBB4AC26207A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 00:17:09 +0800
In-Reply-To: <CAD6AjGQuQT_=zvaY1PvOi-FCN7D08DqTn-=r=9NXNYOt+=R59g@mail.gmail.com>
Cc: 6man WG <ipv6@ietf.org>, Tim Chown <Tim.Chown@jisc.ac.uk>
To: Ca By <cb.list6@gmail.com>
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk> <CAD6AjGQdenKMxQ6KBeBGzTu6fAtR9d_x7HuSPYVATcKEOdmNUQ@mail.gmail.com> <D4AB0373-B105-4E13-B4CA-94FCDACCEBA6@employees.org> <CAD6AjGSzXPEN1Snu9=Acnc6xggJ3=9T4Zks1H=+pfNOyt-qaoQ@mail.gmail.com> <E5C5DFDE-DB7D-41BC-A197-7329C2FEE2F1@employees.org> <CAD6AjGQuQT_=zvaY1PvOi-FCN7D08DqTn-=r=9NXNYOt+=R59g@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/E3yMR_vqMuhlaWXz5XY9EW5gDPc>
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: Mon, 13 Nov 2017 16:17:41 -0000

Cameron,

> I thought this deployment provided dual stack service? 464XLAT, no?
> 
> My definition of ipv6-only includes 464xlat

Terminology is tricky. As proven by Jordi's presentation in v6ops today.

The difference as I see it between IPv6 only + NAT64 and 464XLAT is that in the former an IPv4 application cannot work.
While in the latter the host has an IPv4 address and the IPv4 only application works just as if it is provisioned with IPv4 using any other means. That being native, LW46, MAP-E, MAP-T, L2TP, Public4over6, DSTM, 2473, DS-lite...

Different use cases. While 464XLAT is a way to tunnel IPv4 across an IPv6 only access network (albeit with a null encap. :-)), IPv6 only + NAT64 is about delivering IPv6 only to hosts and applications. Applications would only have an IPv6 address to bind to. This use case would be much more akin to an enterprise network or home network.

> To your point, a large percentage of the tmobile case is 6555bis with nat64/dns64.
> 
> Based on the picture, you can probably guess when 6555bis was implemented ands its relative impact

:-)

Cheers,
Ole

v2.23.0 | Report a Bug | By Email