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

YangGL 写道:
> 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.
>   

In addition, IVI and dIVI can be mixed and using the same core IVI
translator. So the cases are:

(1) IVI
(2) dIVI using CPE
(3) dIVI implemeted in the host

Regards,

xing

>
> Best regards,
> Yang Guoliang
>
>
> -----Original Message-----
> From: Xing Li [mailto:xing@cernet.edu.cn] 
> 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 写道:
>   
>> 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.
>>   
>>     
>
> (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] 
>> 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
>   