<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> <4C8ACDEC.5060707@cernet.edu.cn>
In-Reply-To: <4C8ACDEC.5060707@cernet.edu.cn>
Subject: RE: [BEHAVE] [v4tov6transition]
draft-arkko-ipv6-transition-guidelines WGLC
Date: Sat, 11 Sep 2010 09:10:42 +0800
Message-ID: <002b01cb514e$2daa3720$88fea560$@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: ActRSQipoO3mZKqKQYiYgtDMbUt0GwAAy56w
Content-Language: zh-cn
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

I agree. IVI should be deployed in the scenarios with IPv6-only hosts, =
dIVI
should be deployed for dual-stack hosts. So in my test, IVI will compare
with NAT64, NAT-PT, dIVI will compare with DS-Lite, 6RD, Veno and etc.


Best regards,
Yang Guoliang


-----Original Message-----
From: Xing Li [mailto:xing@cernet.edu.cn]=20
Sent: Saturday, September 11, 2010 8:32 AM
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:
> 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.
>  =20

(1) IVI and dIVI are unified approaches based on translation. The first
IVI translator is the same for both IVI and dIVI scenarios. If people
think ALG is an important issue, then use dIVI, otherwise just connect
an IPv6-only host with IPv4-translatable address and this host can
communicate with IPv6 Internet directly and communicate with IPv4
Internet via first IVI translator.

(2) The second IVI translator can be a module in the end system (for the
new devices, e.g. mobile devices), in this case the end system is
IPv6-only, not dual stack.

If you have any questions, please let us know.

Regards,

xing

>
> 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:
>  =20
>> Sorry, please let me emphasize my point again: I tested a deprecated
>>    =20
> NAT-PT
>  =20
>> 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
>>    =20
> is
>  =20
>> a big problem to all kind of v6-v4 translation. At this point, I =
think
>>    =20
> there
>  =20
>> is no big difference between NAT-PT and later technology.
>>  =20
>>    =20
>
> IVI requires ALG, but dIVI (double IVI) does not require ALG. xing
>
>  =20
>> 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
>>    =20
> am
>  =20
>> 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
>>    =20
> WGLC
>  =20
>> 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
>>    =20
> a
>  =20
>> stateful model). On the basis of testing one vendor's implementation =
of
>>    =20
> the
>  =20
>> deprecated procedure, you assert that there is no implementation of =
the
>> behave technology that uses the stateless mode, and the stateful mode =
of
>>    =20
> the
>  =20
>> 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
>>    =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
>>>      =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
>>    =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
>>>      =20
> P2P.
>  =20
>>>    =20
>>>      =20
>> There are IPv4 addresses embedded in payload, NAT-PT can't translate.
>>  =20
>>    =20
>>> 2. The application programs are not designed for IPv6, such as some =
kind
>>>    =20
>>>      =20
>> of WEB browsers and Email clients. These programs can't work on the =
OS
>> without IPv4 address.
>>  =20
>>    =20
>>> So far I cannot find a stateless/stateful solution to solve the =
problems
>>>    =20
>>>      =20
>> as above.
>>  =20
>>    =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
>>>      =20
>> Erik Lindqvist; Behave WG
>>  =20
>>    =20
>>> Subject: Re: [v4tov6transition] =
draft-arkko-ipv6-transition-guidelines
>>>    =20
>>>      =20
>> WGLC
>>  =20
>>    =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
>>>      =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
>>    =20
>>> Are you running both modes, or only the stateful mode? If you are =
only
>>>    =20
>>>      =20
>> running the stateful mode, that what you're reporting is what we have
been
>> saying for some time it will behave like.
>>  =20
>>    =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
>>>      =20
>>>> Tests in my lab have proved that many popular applications cannot =
work
>>>>        =20
> on
>  =20
>>>>      =20
>>>>        =20
>> IPv6-only network with NAT64, such as IM, P2P, games, and part of =
video.
>>    =20
> WEB
>  =20
>> and part of mail (Outlook and Outlook express) are the only =
applications
>>    =20
> we
>  =20
>> can find working properly with NAT64. But there are more than 50% =
traffic
>>    =20
> is
>  =20
>> P2P, WEB traffic is less than 20% on CT=A1=AFs network. I think it is =
not a
>>    =20
> good
>  =20
>> news to NAT64.
>>  =20
>>    =20
>>>> Tests also prove that almost all of popular applications on =
Internet
can
>>>>      =20
>>>>        =20
>> work on IPv4-only network with single level and double level NAT44, =
such
>>    =20
> as
>  =20
>> WEB, mail, IM, P2P, games, video and etc.
>>  =20
>>    =20
>>>> NAT64 and NAT44 are similar in theory. But what make the difference =
of
>>>>      =20
>>>>        =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
>>    =20
> come
>  =20
>> after this popular applications, situation is totally different. If =
NAT64
>>    =20
> is
>  =20
>> deployed on commercial network now, CT=A1=AFs network traffic will =
cut down
>>    =20
> 70%
>  =20
>> immediately, and most applications will release a new version for
>>    =20
> IPv6-only
>  =20
>> or NAT64 in the next one year. But it is not a good idea to =
providers.
>>  =20
>>    =20
>>>> Best regards,
>>>> Yang Guoliang
>>>>
>>>> =B7=A2=BC=FE=C8=CB: v4tov6transition-bounces@ietf.org
>>>>      =20
>>>>        =20
>> [mailto:v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee
>>  =20
>>    =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
>>>>        =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
>>    =20
> client
>  =20
>> 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
>
>  =20
>>  =20
>>    =20
>>>> However, this use case is rather limited and not applicable to many
>>>>      =20
>>>>        =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
>>    =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
>>>>        =20
>> same as IPv6-only + NAT64?
>>  =20
>>    =20
>>>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee =
<yiu_lee@cable.comcast.com>
>>>>      =20
>>>>        =20
>> wrote:
>>  =20
>>    =20
>>>> In order to deploy IPv6-only + NAT64, the client and network must =
talk
>>>>      =20
>>>>        =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
>>    =20
>>>> On 8/25/10 7:13 AM, "huang cancan" <cancanhuang110@gmail.com
>>>>      =20
>>>>        =20
>> <http://cancanhuang110@gmail.com> > wrote:
>>  =20
>>    =20
>>>> hi,Yiu:
>>>>  As you mentioned below:
>>>>      =20
>>>>        =20
>>>>> All I am saying is the customer
>>>>> experience of IPv4-only + NAT444 could be the same as IPv6-only +
>>>>>          =20
> NAT64,
>  =20
>>>>>        =20
>>>>>          =20
>> but
>>  =20
>>    =20
>>>>> the technologies and plan to offer these service are very =
different.
>>>>>        =20
>>>>>          =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
>>>>        =20
>> <http://yiu_lee@cable.comcast.com> > wrote:
>>  =20
>>    =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
>>>>>          =20
>>>> Life cycle of mobile equipments could be every 2-3 years, but life
cycle
>>>>      =20
>>>>        =20
>> of
>>  =20
>>    =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
>>>>        =20
>> network,
>>  =20
>>    =20
>>>> there are technologies such as DS-lite and Softwire Mesh available =
to
>>>>        =20
> run
>  =20
>>>>      =20
>>>>        =20
>> a
>>  =20
>>    =20
>>>> pure IPv6 core network with dual-stack edge. All I am saying is the
>>>>      =20
>>>>        =20
>> customer
>>  =20
>>    =20
>>>> experience of IPv4-only + NAT444 could be the same as IPv6-only +
NAT64,
>>>>      =20
>>>>        =20
>> but
>>  =20
>>    =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
>>>>        =20
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>>  =20
>>    =20
>
>
>  =20