Re: IPv6 only host NAT64 requirements?

Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> Mon, 13 November 2017 19:09 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
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 0844A129B50 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 11:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 hjGxt2xt54yy for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 11:09:13 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C49124C27 for <ipv6@ietf.org>; Mon, 13 Nov 2017 11:09:12 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEK6W-0000FzC; Mon, 13 Nov 2017 20:09:08 +0100
Message-Id: <m1eEK6W-0000FzC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: IPv6 only host NAT64 requirements?
From: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
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> <CAKD1Yr39jbxHGhzn001UDJC=RB+dTm7GHOK7D3--hzT7Pd9Ryw@mail.gmail.com>
In-reply-to: Your message of "Tue, 14 Nov 2017 02:16:44 +0900 ." <CAKD1Yr39jbxHGhzn001UDJC=RB+dTm7GHOK7D3--hzT7Pd9Ryw@mail.gmail.com>
Date: Mon, 13 Nov 2017 20:09:08 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CsG9BM0zwGggGIdwMvWySMPx3Xk>
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 19:09:15 -0000

>And how are those eyeball networks going to enter the market, given that
>they don't provide access to IPv4 content but their competitors do? Seems
>that they can only do that if pretty much all content is available over
>IPv6. That leaves us stuck at the chicken and egg problem again.

If your core business is IPv4, then in my opinion it doesn't make much 
sense to transition to a network setup where you tunnel your IPv4 traffic
over IPv6. 

As long as an eyeball network has plenty of IPv4 address and there is no
pressure from content providers, there is no point in transitioning to IPv6.

Moving bulk traffic (and bulk connections) to IPv6 make sense if all IPv4
traffic goes through a CGN. 

If an ISP has a full IPv6 setup to handle large volume traffic, and only has
to maintain an IPv4 CGN for content that doesn't want to move to IPv4, then
it is possible that slowly IPv4 performance will get worse. And then content
providers may see an incentive to move to IPv6. For some content providers,
accidentally kiling geolocation in order to improve CGN efficiency may
give them the nudge they need.

In the end, the only argument that seems to make economic sense is that
an IPv4 address is more expensive than an IPv6 address. And that traffic
through a CGN is more expensive than through a router.