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

["YangGL" <[e-mail]>]

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.
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:[e-mail]] 
Sent: Friday, September 03, 2010 1:14 AM
To: YangGL
Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; [e-mail]; 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:[e-mail]] 
> Sent: Sunday, August 29, 2010 2:09 PM
> To: YangGL
> Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; [e-mail]; 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
>> 
>> 发件人: [e-mail]
[mailto:[e-mail]] 代表 Yiu L. Lee
>> 发送时间: 2010年8月25日 22:05
>> 收件人: huang cancan
>> 抄送: Kurt Erik Lindqvist; IPv6 v6ops; [e-mail]
>> 主题: 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" <[e-mail]> 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 <[e-mail]>
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" <[e-mail]
<http://[e-mail]> > 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 <[e-mail]
<http://[e-mail]> > 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
>> [e-mail] <http://[e-mail]> 
>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>> 
>> 
>> 
>> 
>> _______________________________________________
>> v4tov6transition mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v4tov6transition