[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Technically, these drafts are well written and very useful. It is really appreciated. Fred, would you explicitly point out the answers of the following questions from these drafts? Thanks.
1) There are some applications, server, clients don’t support IPv6. These situations will be met regardless of stateful or stateless NAT64. No one has right to request these applications must support IPv6 (Monocrat may have), but these applications have existed and been used for many people. In the migration to IPv6, if these users can’t use these service and applications, it will result in the losing of subscribers for operators, unless all the operators of the world support IPv6 at the same moment.
2) Some applications have supported NAT44 traversal maturely, but in a long period of time in the future these applications would unlikely to support NAT64’s traversal. If adopting NAT64, these applications would be impacted. No one has the right to request these applications must support NAT64 traversal, so after the usage of NAT64, these application will conk out inevitably. Both stateful and stateless NAT64 have the same issues.
3) Some applications contain the senders’ IP address in the packet payload, even in the encrypted packet case. These will have problems when using NAT64. Since these applications are existing applications, no one has right to requesting stop using these applications. These issues will be encountered when using NAT64 (both stateful and stateless ones have the same problem).
4) No one has the right to force all the UE to support IPV6, therefore from the technology evolution point of view, we don't have to consider IPV4 only user actively visits IPv6 only service, but in the actual use people have to consider it, otherwise it may result in the subscriber losing. Yes, it is not NAT64.
5) For some P2P application, after using NAT64, IPv4 only peer is not able to actively scan the IPv6 only peer; some P2P applications don’t consider NAT64 traversal for the time being. 

Again, these drafts are very practical drafts, any way.

B. R.
Tina
http://tinatsou.weebly.com/index.html
----- Original Message ----- From: "YangGL" <iamyanggl@gmail.com> 
To: "'Fred Baker'" <fred@cisco.com>
Cc: "'Behave WG'" <behave@ietf.org>; "'Kurt Erik Lindqvist'" <kurtis@kurtis.pp.se>; "'IPv6 v6ops'" <v6ops@ops.ietf.org>; <v4tov6transition@ietf.org> 
Sent: Tuesday, August 31, 2010 10:27 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC



Hi Fred,
You are really the dictionary of IPv6! Your mail always make me feel
difficult to answer, too many references to read, give me some time, I will 
come back after reading those documents mentioned in your mail.


Best regards,
Yang Guoliang


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


_______________________________________________
v4tov6transition mailing list
v4tov6transition@ietf.org
https://www.ietf.org/mailman/listinfo/v4tov6transition