Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Fred Baker <fred@cisco.com> Thu, 02 September 2010 17:15 UTC

Return-Path: <fred@cisco.com>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A123A6AEA; Thu, 2 Sep 2010 10:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.526
X-Spam-Level:
X-Spam-Status: No, score=-108.526 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YG3rWOTBaLp; Thu, 2 Sep 2010 10:15:23 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 07E093A69CB; Thu, 2 Sep 2010 10:13:45 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPt3f0yrR7H+/2dsb2JhbACDGJ1pcaNAiXUIkh6BHoMmdwSEJRyFWA
X-IronPort-AV: E=Sophos;i="4.56,308,1280707200"; d="scan'208";a="180575845"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 Sep 2010 17:14:04 +0000
Received: from Freds-Computer.local (sjc-vpn5-1612.cisco.com [10.21.94.76]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o82HDrSE013457; Thu, 2 Sep 2010 17:13:55 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 02 Sep 2010 10:14:02 -0700
X-PGP-Universal: processed; by Freds-Computer.local on Thu, 02 Sep 2010 10:14:02 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <006c01cb4a81$ed53cd80$c7fb6880$@com>
Date: Thu, 02 Sep 2010 10:13:47 -0700
Message-Id: <7C56CE35-9D5A-4D29-823B-95CF8ADDA105@cisco.com>
References: <AANLkTim8kzSA8pKazc8u_w4C6j=y5bc-uArMWZaH9Nbm@mail.gmail.com> <C89A9B64.30FA2%yiu_lee@cable.comcast.com> <002a01cb4712$d9f72fb0$8de58f10$@com> <B7569879-BD21-48EF-B411-BC99FAA48A22@cisco.com> <006c01cb4a81$ed53cd80$c7fb6880$@com>
To: YangGL <iamyanggl@gmail.com>
X-Mailer: Apple Mail (2.1081)
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable
Cc: Behave WG <behave@ietf.org>, Kurt Erik Lindqvist <kurtis@kurtis.pp.se>, IPv6 v6ops <v6ops@ops.ietf.org>, v4tov6transition@ietf.org
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Sep 2010 17:15:32 -0000

So you tested one implementation, one that uses a technology that the IETF has deprecated (NAT-PT), and did not test the technology that has been discussed in the behave working group under the name NAT64 (which is also a stateful model). On the basis of testing one vendor's implementation of the deprecated procedure, you assert that there is no implementation of the behave technology that uses the stateless mode, and the stateful mode of the behave technology that you didn't test either "doesn't work".

Did I get that right?

On Sep 2, 2010, at 2:33 AM, YangGL wrote:

> Hi Fred,
> The device in my NAT64 tests was NAT-PT from Juniper, it is stateful.
> Based on my knowledge of IPv4/IPv6 translation, the major differences between stateful and stateless are bidirection and scalability. There are similar impact to applications. My test goal is finding out the impact to applications caused by IPv4/IPv6 translation, not whether a specific translator work well. So I didn't test more products, also didn't run two modes.
> There are two major reasons for failure in my tests:
> 1. The protocols can't work with IPv4/IPv6 translator, such as IM and P2P. There are IPv4 addresses embedded in payload, NAT-PT can't translate.
> 2. The application programs are not designed for IPv6, such as some kind of WEB browsers and Email clients. These programs can't work on the OS without IPv4 address.
> So far I cannot find a stateless/stateful solution to solve the problems as above.
> 
> 
> Best regards,
> Yang Guoliang
> 
> 
> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com] 
> Sent: Sunday, August 29, 2010 2:09 PM
> To: YangGL
> Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; v4tov6transition@ietf.org; Kurt Erik Lindqvist; Behave WG
> Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
> 
> </chair> <!-- v6ops -->
> <author> <!-- draft-ietf-behave-v6v4-xlate -->
> 
> May I ask a question?
> 
> When you say you tested it with NAT64, what did you test with?
> 
> There are two modes for translation between IPv4 and IPv6. The stateful mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to connect to IPv4 systems but not the reverse. The stateless mode, described in draft-ietf-behave-v6v4-xlate, allows connections to be initiated in either direction. The downside of the stateless mode is that it requires a direct mapping between an IPv4 and an IPv6 address. The are two parts of a common framework, use the same addressing plan, and the same DNS extension.
> 
> Are you running both modes, or only the stateful mode? If you are only running the stateful mode, that what you're reporting is what we have been saying for some time it will behave like.
> 
> http://datatracker.ietf.org/doc/draft-ietf-behave-address-format
> http://tools.ietf.org/html/draft-ietf-behave-address-format
>  "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian
>  Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10,
>  <draft-ietf-behave-address-format-10.txt>
> 
> http://datatracker.ietf.org/doc/draft-ietf-behave-dns64
> http://tools.ietf.org/html/draft-ietf-behave-dns64
>  "DNS64: DNS extensions for Network Address Translation from IPv6 Clients
>  to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews,
>  Iljitsch van Beijnum, 5-Jul-10, <draft-ietf-behave-dns64-10.txt>
> 
> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework
> http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework
>  "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao
>  Bao, Kevin Yin, 17-Aug-10, <draft-ietf-behave-v6v4-framework-10.txt>
> 
> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate
> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate
>  "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker,
>  22-Aug-10, <draft-ietf-behave-v6v4-xlate-22.txt>
> 
> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful
> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
>  "Stateful NAT64: Network Address and Protocol Translation from IPv6
>  Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van
>  Beijnum, 12-Jul-10, <draft-ietf-behave-v6v4-xlate-stateful-12.txt>
> 
> 
> On Aug 28, 2010, at 5:40 PM, YangGL wrote:
> 
>> Tests in my lab have proved that many popular applications cannot work on IPv6-only network with NAT64, such as IM, P2P, games, and part of video. WEB and part of mail (Outlook and Outlook express) are the only applications we can find working properly with NAT64. But there are more than 50% traffic is P2P, WEB traffic is less than 20% on CT’s network. I think it is not a good news to NAT64.
>> Tests also prove that almost all of popular applications on Internet can work on IPv4-only network with single level and double level NAT44, such as WEB, mail, IM, P2P, games, video and etc.
>> NAT64 and NAT44 are similar in theory. But what make the difference of application support? I think it should be timing. NAT44 appears ten years ago. There are a few applications on internet at that time. Subsequent applications, such as IM, P2P, were designed to work with NAT44. NAT64 come after this popular applications, situation is totally different. If NAT64 is deployed on commercial network now, CT’s network traffic will cut down 70% immediately, and most applications will release a new version for IPv6-only or NAT64 in the next one year. But it is not a good idea to providers.
>> 
>> Best regards,
>> Yang Guoliang
>> 
>> 发件人: v4tov6transition-bounces@ietf.org [mailto:v4tov6transition-bounces@ietf.org] 代表 Yiu L. Lee
>> 发送时间: 2010年8月25日 22:05
>> 收件人: huang cancan
>> 抄送: Kurt Erik Lindqvist; IPv6 v6ops; v4tov6transition@ietf.org
>> 主题: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
>> 
>> From user’s perspective, do they care IPv4 or IPv6? Most don’t. For example: a casual web user wants to access his/her favorite IPv4-only website. If his web client and PC support IPv6 and on an IPv6-only network with NAT64, the web traffic will go through the NAT once. If his web client and PC support IPv4-only on an IPv4 network with NAT444, the web traffic will go through the NAT twice. In the end, he/she still gets the same content. From this perspective, both experience “could be” very similar. 
>> 
>> However, this use case is rather limited and not applicable to many applications. This is why I said “could be”. Also, both Cameron and I agree that this is easier to implement IPv6-only on mobile network than on fixed network because mobile operators have more control over the devices and apps. IMHO, it will take longer time for fixed network operators to support NAT64 only solution in the network.
>> 
>> 
>> On 8/25/10 9:41 AM, "huang cancan" <cancanhuang110@gmail.com> wrote:
>> 
>> well, I mean: why customer experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64?
>> 
>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <yiu_lee@cable.comcast.com> wrote:
>> In order to deploy IPv6-only + NAT64, the client and network must talk IPv6. It also requires DNS64. These requirements are not needed for IPv4-only + NAT444. From the deployment point of view, they are very different technologies. 
>> 
>> 
>> 
>> On 8/25/10 7:13 AM, "huang cancan" <cancanhuang110@gmail.com <http://cancanhuang110@gmail.com> > wrote:
>> 
>> hi,Yiu:
>>  As you mentioned below:
>>> All I am saying is the customer
>>> experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, but
>>> the technologies and plan to offer these service are very different.
>> 
>>  Do you have any test data to support this conclusion?
>> 
>> Can-can Huang
>> 
>> 
>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <yiu_lee@cable.comcast.com <http://yiu_lee@cable.comcast.com> > wrote:
>> 
>>> Agreed.  The 2x cost is really just the packet core ... which is of
>>> course a lot of money to double for no tangible benefit ..... talk
>>> about no business case .... And, still have numbering issues, customer
>>> experience is the same as IPv4-only + NAT44 and approximately the same
>>> as IPv6-only + NAT64
>>> 
>> Life cycle of mobile equipments could be every 2-3 years, but life cycle of
>> consumer electronics could be 5+ years. Consider many large TVs with
>> Internet service selling today are still running IPv4-only, fixed line
>> operators must prepare to support them in foreseeable future.
>> 
>> That said, I am not saying an operator must build a dual-stack core network,
>> there are technologies such as DS-lite and Softwire Mesh available to run a
>> pure IPv6 core network with dual-stack edge. All I am saying is the customer
>> experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, but
>> the technologies and plan to offer these service are very different.
>> 
>> 
>> 
>> _______________________________________________
>> v4tov6transition mailing list
>> v4tov6transition@ietf.org <http://v4tov6transition@ietf.org> 
>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>> 
>> 
>> 
>> 
>> _______________________________________________
>> v4tov6transition mailing list
>> v4tov6transition@ietf.org
>> https://www.ietf.org/mailman/listinfo/v4tov6transition