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

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

Thank you!
I agree that many way to solve the problems, but I worry about that most of
these way need to modify the existing applications.
I maybe wrong, I will think about it again after reading the references in
your mail.

Best regards,
Yang Guoliang


-----Original Message-----
From: Dan Wing [mailto:[e-mail]] 
Sent: Friday, September 03, 2010 1:08 AM
To: 'YangGL'; 'Fred Baker'
Cc: 'Yiu L. Lee'; 'huang cancan'; 'IPv6 v6ops'; [e-mail];
'Kurt Erik Lindqvist'; 'Behave WG'
Subject: RE: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

> -----Original Message-----
> From: YangGL [mailto:[e-mail]]
> Sent: Thursday, September 02, 2010 2:33 AM
> To: 'Fred Baker'
> Cc: 'Yiu L. Lee'; 'huang cancan'; 'IPv6 v6ops';
> [e-mail]; 'Kurt Erik Lindqvist'; 'Behave WG'
> Subject: RE: [v4tov6transition] draft-arkko-ipv6-transition-guidelines
> WGLC
> 
> 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.

An IPv6 application that wants to communicate with IPv4 hosts, where
those IPv4 hosts are known only by IPv4 addresses (rather than DNS names)
will need to add its own support to communicate with IPv4 hosts.  One
way to do that is TURN (RFC5766), another way is TURN-IPv6
(draft-ietf-behave-turn-ipv6), another way is an application-
specific proxy (e.g., HTTP proxy), another way is a proxy (e.g.,
SOCKS proxy).  And another way is to learn the IPv6 prefix of the
NAT64 translator and send an IPv6 packet to the NAT64, 
draft-wing-v6ops-v6app-v4server

> 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.

That problem is unrelated to NAT64.

Yes, there are applications which have no IPv6 support, and there
are applications (and operating systems) which cannot work on an
IPv6-only network.  Those applications will need to be abandoned,
need to be modified, or need run on a dual-stack host.

-d


> 
> 
> 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:v4tov6transition-
> [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