Subject: Re: [BEHAVE] [v4tov6transition]

From: Xing Li <[email-masked]>
Date: Sat, 11 Sep 2010 21:25:22 +0000

draft-arkko-ipv6-transition-guidelines
 WGLC
References:
<AANLkTim8kzSA8pKazc8u_w4C6j=[email-masked]>
<[email-masked]>
<002a01cb4712$d9f72fb0$8de58f10$@com>
<[email-masked]>
<006c01cb4a81$ed53cd80$c7fb6880$@com>
<[email-masked]>
<002301cb4b0b$b3dab750$1b9025f0$@com>
In-Reply-To: <002301cb4b0b$b3dab750$1b9025f0$@com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: [email-masked]
X-AIMC-Msg-ID: 6idCEuYB
Sender: [email-masked]
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

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:[email-masked]] 
> Sent: Friday, September 03, 2010 1:14 AM
> To: YangGL
> Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; [email-masked]; 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:[email-masked]] 
>> Sent: Sunday, August 29, 2010 2:09 PM
>> To: YangGL
>> Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; [email-masked]; 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
>>>
>>> ������: [email-masked]
>>>       
> [mailto:[email-masked]] ���� Yiu L. Lee
>   
>>> ����ʱ��: 2010��8��25�� 22:05
>>> �ռ���: huang cancan
>>> ����: Kurt Erik Lindqvist; IPv6 v6ops; [email-masked]
>>> ����: 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" <[email-masked]> 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 <[email-masked]>
>>>       
> 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" <[email-masked]
>>>       
> <http://[email-masked]> > 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 <[email-masked]
>>>       
> <http://[email-masked]> > 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
>>> [email-masked] <http://[email-masked]> 
>>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> v4tov6transition mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>>       
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>