Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
"YangGL" <iamyanggl@gmail.com> Tue, 14 September 2010 06:01 UTC
Return-Path: <iamyanggl@gmail.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575D33A6898; Mon, 13 Sep 2010 23:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.842
X-Spam-Level:
X-Spam-Status: No, score=0.842 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45]
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 D4jAA7V3eQsL; Mon, 13 Sep 2010 23:01:47 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 64FF33A6801; Mon, 13 Sep 2010 23:01:41 -0700 (PDT)
Received: by pxi6 with SMTP id 6so3118748pxi.31 for <multiple recipients>; Mon, 13 Sep 2010 23:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=ocI8myfux+Q6gWpmCNCUJANch3dWekO7zFykjLYcI+o=; b=AuKfvcEnj7zBcdfIZf60Mk01Qq5VNyNmAlF/j0/s1TQXYNd371dXoxbxYbYxFSAvbm p2Gs1sVs1j9Uffz/9VqEiZYLkEOkFFl9OJ4nnUUJs3AGCsnqcsz/yEOiJwncCuriOlzv EfTe9h8j6wtVdNWMBVQEArAf8DkvlwDU2ja5M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=EC4c074lNCw6/QNpc6Xq7U4iZYOvafnFtJq1Hrw4Ol21v+dei2YRyC+zCU+IyHECi1 mMYG2EVSAD2bXLy2p3aOp0U/SfZjw4FMue/qnc13TFv/snoQcZC+4u62HgtFPFCXh9oH zjONJUwKQDdAFOvL07Sn/hEnx4wEZK7AznFys=
Received: by 10.142.161.2 with SMTP id j2mr496019wfe.161.1284444127408; Mon, 13 Sep 2010 23:02:07 -0700 (PDT)
Received: from LocalHost ([120.88.10.132]) by mx.google.com with ESMTPS id l41sm9689093wfa.13.2010.09.13.23.01.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Sep 2010 23:02:03 -0700 (PDT)
From: YangGL <iamyanggl@gmail.com>
To: 'Xing Li' <xing@cernet.edu.cn>
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> <7C56CE35-9D5A-4D29-823B-95CF8ADDA105@cisco.com> <002301cb4b0b$b3dab750$1b9025f0$@com> <4C8A384A.803@cernet.edu.cn> <001401cb50fe$68c75400$3a55fc00$@com> <4C8E0057.5050803@cernet.edu.cn>
In-Reply-To: <4C8E0057.5050803@cernet.edu.cn>
Date: Tue, 14 Sep 2010 14:01:49 +0800
Message-ID: <008f01cb53d2$596f1200$0c4d3600$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActTMJE2auHQwnrSRmWlJmHGjFYamwAobBMw
Content-Language: zh-cn
X-Mailman-Approved-At: Tue, 14 Sep 2010 10:43:44 -0700
Cc: 'Behave WG' <behave@ietf.org>, 'huang cancan' <cancanhuang110@gmail.com>, 'Fred Baker' <fred@cisco.com>, "'Yiu L. Lee'" <yiu_lee@cable.comcast.com>, 'IPv6 v6ops' <v6ops@ops.ietf.org>, v4tov6transition@ietf.org
Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2010 06:01:49 -0000
Yes, just like ds-lite. Best regards, Yang Guoliang -----Original Message----- From: Xing Li [mailto:xing@cernet.edu.cn] Sent: Monday, September 13, 2010 6:44 PM To: YangGL Cc: 'Behave WG'; 'huang cancan'; 'Fred Baker'; 'Yiu L. Lee'; 'IPv6 v6ops'; v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC YangGL 写道: > Sure, dIVI does not require ALG, because it work like a tunnel technology in > the scenarios of IPv4-IPv6-IPv4. Hosts in the dIVI scenarios are also > dual-stack, not IPv6-only. > If dIVI is implemented in host, then the host is IPv6 single stack connecting to the IPv6-only network. The sockets API is dual stack for the applications running in the host. regards, xing > > Best regards, > Yang Guoliang > > > -----Original Message----- > From: Xing Li [mailto:xing@cernet.edu.cn] > Sent: Friday, September 10, 2010 9:53 PM > To: YangGL > Cc: 'Fred Baker'; 'Behave WG'; 'huang cancan'; 'Yiu L. Lee'; 'IPv6 v6ops'; > v4tov6transition@ietf.org > Subject: Re: [BEHAVE] [v4tov6transition] > draft-arkko-ipv6-transition-guidelines WGLC > > YangGL 写道: > >> Sorry, please let me emphasize my point again: I tested a deprecated >> > NAT-PT > >> not because there isn't any stateless or stateful implementation (I know >> about IVI). Reasons are as below: >> 1. On the basis of theoretical analysis, IPv4 address embedded in payload >> > is > >> a big problem to all kind of v6-v4 translation. At this point, I think >> > there > >> is no big difference between NAT-PT and later technology. >> >> > > IVI requires ALG, but dIVI (double IVI) does not require ALG. xing > > >> 2. There is a Juniper firewall in my lab, it can support NAT-PT. So I can >> carry on easily. >> I don't want to argue again. Since many people question my test result, I >> > am > >> going to do it again, welcome everybody to work with us, and Fred, please >> give me the typical product list. >> Please notice that the next test isn't an authentication entering China >> telecom's network, just for study. >> >> >> Best regards, >> Yang Guoliang >> >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Friday, September 03, 2010 1:14 AM >> 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 > >> 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 >>>> >>>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Fred Baker
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… huang cancan
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… huang cancan
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Brian E Carpenter
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Tina TSOU
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Joel Jaeggli
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… YangGL
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… huang cancan
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Fred Baker
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Gert Doering
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… YangGL
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Dan Wing
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Fred Baker
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Pekka Savola
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Joel Jaeggli
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Gert Doering
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Tina TSOU
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Dan Wing
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Tina TSOU
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Tina TSOU
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Christopher Morrow
- [BEHAVE] Comment on draft-lee-v4v6tran-problem-00… Tina TSOU
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Tina TSOU
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Tina TSOU
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Dan Wing
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Christopher Morrow
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… YangGL
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… YangGL
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Cameron Byrne
- [BEHAVE] DS hosts & DS networks - need for a more… Rémi Després
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Christopher Morrow
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Xing Li
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Xing Li
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… YangGL
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… YangGL
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Xing Li
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… Xing Li
- Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-… YangGL