<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>
In-Reply-To: <4C8A384A.803@cernet.edu.cn>
Subject: RE: [BEHAVE] [v4tov6transition]
draft-arkko-ipv6-transition-guidelines WGLC
Date: Fri, 10 Sep 2010 23:39:40 +0800
Message-ID: <001401cb50fe$68c75400$3a55fc00$@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: ActQ75XAkaVKSR05SKme2g21JJMRfQADZzig
Content-Language: zh-cn
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

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.


Best regards,
Yang Guoliang


-----Original Message-----
From: Xing Li [mailto:xing@cernet.edu.cn]=20
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 =D0=B4=B5=C0:
> 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.
>  =20

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]=20
> 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:
>
>  =20
>> 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
>>    =20
> 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.
>  =20
>> 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.
>>    =20
> There are IPv4 addresses embedded in payload, NAT-PT can't translate.
>  =20
>> 2. The application programs are not designed for IPv6, such as some =
kind
>>    =20
> of WEB browsers and Email clients. These programs can't work on the OS
> without IPv4 address.
>  =20
>> So far I cannot find a stateless/stateful solution to solve the =
problems
>>    =20
> as above.
>  =20
>> Best regards,
>> Yang Guoliang
>>
>>
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@cisco.com]=20
>> Sent: Sunday, August 29, 2010 2:09 PM
>> To: YangGL
>> Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; v4tov6transition@ietf.org; =
Kurt
>>    =20
> Erik Lindqvist; Behave WG
>  =20
>> Subject: Re: [v4tov6transition] =
draft-arkko-ipv6-transition-guidelines
>>    =20
> WGLC
>  =20
>> </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
>>    =20
> 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.
>  =20
>> Are you running both modes, or only the stateful mode? If you are =
only
>>    =20
> running the stateful mode, that what you're reporting is what we have =
been
> saying for some time it will behave like.
>  =20
>> 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:
>>
>>    =20
>>> Tests in my lab have proved that many popular applications cannot =
work
on
>>>      =20
> 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=A1=AFs network. I think it is =
not a
good
> news to NAT64.
>  =20
>>> Tests also prove that almost all of popular applications on Internet =
can
>>>      =20
> work on IPv4-only network with single level and double level NAT44, =
such
as
> WEB, mail, IM, P2P, games, video and etc.
>  =20
>>> NAT64 and NAT44 are similar in theory. But what make the difference =
of
>>>      =20
> 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=A1=AFs 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.
>  =20
>>> Best regards,
>>> Yang Guoliang
>>>
>>> =B7=A2=BC=FE=C8=CB: v4tov6transition-bounces@ietf.org
>>>      =20
> [mailto:v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee
>  =20
>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05
>>> =CA=D5=BC=FE=C8=CB: huang cancan
>>> =B3=AD=CB=CD: Kurt Erik Lindqvist; IPv6 v6ops; =
v4tov6transition@ietf.org
>>> =D6=F7=CC=E2: Re: [v4tov6transition] =
draft-arkko-ipv6-transition-guidelines WGLC
>>>
>>> From user=A1=AFs perspective, do they care IPv4 or IPv6? Most =
don=A1=AFt. For
>>>      =20
> 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 =A1=B0could be=A1=B1 =
very similar.

>  =20
>>> However, this use case is rather limited and not applicable to many
>>>      =20
> applications. This is why I said =A1=B0could be=A1=B1. 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.
>  =20
>>> 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
>>>      =20
> same as IPv6-only + NAT64?
>  =20
>>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee =
<yiu_lee@cable.comcast.com>
>>>      =20
> wrote:
>  =20
>>> In order to deploy IPv6-only + NAT64, the client and network must =
talk
>>>      =20
> 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.=20
>  =20
>>>
>>> On 8/25/10 7:13 AM, "huang cancan" <cancanhuang110@gmail.com
>>>      =20
> <http://cancanhuang110@gmail.com> > wrote:
>  =20
>>> hi,Yiu:
>>>  As you mentioned below:
>>>      =20
>>>> All I am saying is the customer
>>>> experience of IPv4-only + NAT444 could be the same as IPv6-only +
NAT64,
>>>>        =20
> but
>  =20
>>>> the technologies and plan to offer these service are very =
different.
>>>>        =20
>>>  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
>>>      =20
> <http://yiu_lee@cable.comcast.com> > wrote:
>  =20
>>>> 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
>>>>
>>>>        =20
>>> Life cycle of mobile equipments could be every 2-3 years, but life =
cycle
>>>      =20
> of
>  =20
>>> 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
>>>      =20
> network,
>  =20
>>> there are technologies such as DS-lite and Softwire Mesh available =
to
run
>>>      =20
> a
>  =20
>>> pure IPv6 core network with dual-stack edge. All I am saying is the
>>>      =20
> customer
>  =20
>>> experience of IPv4-only + NAT444 could be the same as IPv6-only + =
NAT64,
>>>      =20
> but
>  =20
>>> the technologies and plan to offer these service are very different.
>>>
>>>
>>>
>>> _______________________________________________
>>> v4tov6transition mailing list
>>> v4tov6transition@ietf.org <http://v4tov6transition@ietf.org>=20
>>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> v4tov6transition mailing list
>>> v4tov6transition@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>>      =20
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>  =20