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

From: Fred Baker <[email-masked]>
Date: Wed, 1 Sep 2010 20:49:26 -0700

On Aug 30, 2010, at 2:04 AM, huang cancan wrote:

>    We test the statful one and hadn't test the statless one, because there is no commercial device supporting DIVI.

</ietf>
<cisco>
Cisco has a commercial implementation in the field. I have contacted one of the engineers working on it to discuss it with you.
</cisco>
<ietf>

---

From: Gert Doering <[email-masked]>
Date: Thu, 2 Sep 2010 16:32:24 +0200

Hi,

On Tue, Aug 31, 2010 at 11:12:58AM +0800, Tina TSOU wrote:
[..]
> No one has the right to request these applications must support NAT64 
> traversal, 
[..]
> NAT64. Since these applications are existing applications, no one has right 
> to requesting stop using these applications. 
[..]
> 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 
[..]

I'm wondering which parallel universe this is going to happen.

In my universe, IPv4 is going to run out, and if there is no more IPv4,
these applications will either get fixed, or die.  Very straightforward.

gert
-- 
Total number of prefixes smaller than registry allocations:  155817

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "YangGL" <[email-masked]>
Date: Thu, 2 Sep 2010 17:33:21 +0800

WARNING: contains banned part

Subject: RE: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
From: "YangGL" <[email-masked]>
To: "'Fred Baker'" <[email-masked]>
Cc: "'Yiu L. Lee'" <[email-masked]>, "'huang cancan'" <[email-masked]>, "'IPv6 v6ops'" <[email-masked]>, <[email-masked]>, "'Kurt Erik Lindqvist'" <[email-masked]>, "'Behave WG'" <[email-masked]>
Date: Thu, 2 Sep 2010 17:33:21 +0800

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Sep 2010 10:08:03 -0700

> From: YangGL [mailto:[email-masked]]
> Sent: Thursday, September 02, 2010 2:33 AM
> To: 'Fred Baker'
> Cc: 'Yiu L. Lee'; 'huang cancan'; 'IPv6 v6ops';
> [email-masked]; 'Kurt Erik Lindqvist'; 'Behave WG'
> 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.
> 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

> Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; [email-masked];
> Kurt Erik Lindqvist; Behave WG
> 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.
> 
> running the stateful mode, that what you're reporting is what we have
> been saying for some time it will behave like.
> 
> > 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:v4tov6transition-
> [email-masked]] 代表 Yiu L. Lee
> > 发送时间: 2010年8月25日 22:05
> > 收件人: huang cancan
> 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.
> >
> 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.
> >
> >
> > 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.
> >
> >
> >
> > > experience of IPv4-only + NAT444 could be the same as IPv6-only +
> NAT64, but
> > On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee
> <[email-masked] <http://[email-masked]> > wrote:
> >
> > Life cycle of mobile equipments could be every 2-3 years, but life
> cycle of
> > there are technologies such as DS-lite and Softwire Mesh available to
> run a
> > experience of IPv4-only + NAT444 could be the same as IPv6-only +
> NAT64, but

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Sep 2010 10:13:47 -0700

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:

> 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.
> 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
> 
> 
> Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; [email-masked]; Kurt Erik Lindqvist; Behave WG
> 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.
> 
>> 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
>> 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.
>> 
>> 
>> 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:
>>> experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, but
>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked] <http://[email-masked]> > wrote:
>> 
>> Life cycle of mobile equipments could be every 2-3 years, but life cycle of
>> 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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Sep 2010 20:31:59 +0300 (EEST)

> these applications will either get fixed, or die.  Very straightforward.

In the same universe where there will be IPv4 public addresses and 
NAT44 still in 20 years, I suppose?  I guess it's in the eye of the 
beholder how difficult you expect it to be to be able to get IPv4 
addresses and/or kludge your way around them to make v4 applications 
or hosts work even long after the IANA IPv4 runout.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 02 Sep 2010 10:47:12 -0700

On 9/2/10 10:31 AM, Pekka Savola wrote:
> In the same universe where there will be IPv4 public addresses and NAT44
> still in 20 years, I suppose?  I guess it's in the eye of the beholder
> how difficult you expect it to be to be able to get IPv4 addresses
> and/or kludge your way around them to make v4 applications or hosts work
> even long after the IANA IPv4 runout.

When it becomes difficult to use them the incentive to switch, or build
functional (probably application layer) workarounds for devices that
cannot be upgraded will greatly increase, in many respects that is a
feature and not bug.

I doubt very much that you and I and this mailing list will be
discussing what to do with the stubborn holdouts in 2030, or even 2020
(and yes they will exist, and not they won't be consumers).

---

From: Gert Doering <[email-masked]>
Date: Thu, 2 Sep 2010 20:17:43 +0200

Hi,

On Thu, Sep 02, 2010 at 08:31:59PM +0300, Pekka Savola wrote:
> NAT44 still in 20 years, I suppose?  

Yes.  Some parts of that universe will cling to IPv4 forever.

Other parts (the fast-growing bits) like mobile, and DSL/cable/etc in
not-yet-saturated markets will (hopefully) have abandoned IPv4 in a
not so distant future.

> I guess it's in the eye of the 

For those networks, I expect it to be nearly impossible to get IPv4
addresses, and NAT4444 is going to cause more application breakage 
than NAT64.

Gert Doering
        -- NetMaster

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Sep 2010 12:02:53 +0800

Hi Gert,

I agree with you that IPv4 only applications/website will run out. But it 
will happen some years later.

Because different operators face a lack of IPv4 addresses not the same case. 
Not all operators support IPv6 at the same time and not all operators deploy 
the same technology in their network when transit to IPv6. So the host will 
be various (IPv4 only, IPv6 only, dual stack) and the time that applications 
support IPv6 or support across NAT64 will not be at the same time. This is 
why we need so many tunnel/translate technologies for IP version transition. 
(e.g.draft-ietf-softwire-dual-stack-lite, RFC5569, RFC5214, 
draft-ietf-behave-v6v4-xlate-stateful, RFC3089, etc.)

If an operator deploys native IPv6 in its network first and deploys NAT64, 
many applications will not be served till these applications support IPv6 or 
across NAT64, this will lead the losing of subscribers for operators.

Another idealistic solution to solve the problems is that all networks, 
applications, host support IPv6 immediately. Then there is no problem for IP 
version transition. Is this is possible?

For example, an ICP (Internet Content Provider) which is in USA supports 
IPv4 and across NAT44, and its customers are mainly from USA. If the 
operators in USA don't deploy IPv6 now, and only one Chinese operator deploy 
native IPv6. Only a few customers of the ICP are subscribers for operators, 
the ICP will not support IPv6 immediately. This will lead to the losing of 
subscribers for this IPv6 operator.

B. R.
Tina
http://tinatsou.weebly.com

----- Original Message ----- 
From: "Gert Doering" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "'Fred Baker'" <[email-masked]>; "YangGL" <[email-masked]>; 
<[email-masked]>; "'IPv6 v6ops'" <[email-masked]>; "'Kurt 
Erik Lindqvist'" <[email-masked]>; "'Behave WG'" <[email-masked]>
Sent: Thursday, September 02, 2010 10:32 PM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Sep 2010 21:35:22 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tina TSOU
> Sent: Thursday, September 02, 2010 9:03 PM
> To: Gert Doering
> Cc: 'Behave WG'; YangGL; 'Fred Baker'; 'IPv6 v6ops';
> Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-
> guidelines WGLC
> 
> Hi Gert,
> 
> 
> 

You're saying an operator deploys IPv6-only (and not IPv4).  Yes,
that will break applications that require IPv4 -- almost all games, 
bittorrent, skype, and many other applications.

> across NAT64, this will lead the losing of subscribers for operators.

The problem is not solely the fault of NAT64.  Rather, the problem is
the fault of the application (and oftentimes the underlying host
operating system) which cannot support running IPv6-only.

> applications, host support IPv6 immediately. Then there is no problem
> for IP version transition. Is this is possible?

No.

> subscribers for this IPv6 operator.

So you're saying the content, being served by that IPv4-only content
provider, is inaccessible via NAT64.  Can you explain how that content
is delivered that doesn't work across NAT64?   HTTP?  IMAP?  SMTP?  
RTSP??  I am interested in what breaks.

Secondly, if -- as you say -- that content provider is losing customers 
(customers which cannot get to their IPv4-only content), the content 
provider seems to havea financial incentive to support IPv6 so that
IPv6-only subscribers can view the content.  

-d

> >> NAT64. Since these applications are existing applications, no one
> has
> >> right
> >> 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
> > [..]
> >
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Sep 2010 13:08:30 +0800

B. R.
Tina
http://tinatsou.weebly.com/index.html

On Sep 3, 2010, at 12:35 PM, Dan Wing wrote:

>> I agree with you that IPv4 only applications/website will run out.  
>> But
>> it
>> Because different operators face a lack of IPv4 addresses not the  
>> same
>> case.
>> the same technology in their network when transit to IPv6. So the  
>> host
>> will
>> support IPv6 or support across NAT64 will not be at the same time.  
>> This
>> is
> The problem is not solely the fault of NAT64.
No, I didn't say that. NAT64 is wonderful.
> Rather, the problem is the fault of the application (and oftentimes  
> the underlying host
>> the ICP will not support IPv6 immediately. This will lead to the  
>> losing
>> of
>> Erik Lindqvist'" <[email-masked]>; "'Behave WG'" <[email-masked] 
>> >
>> Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition- 
>> guidelines
>> WGLC
>>
>>
>>> Hi,
>>>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Sep 2010 13:08:47 +0800

B. R.
Tina

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Sep 2010 01:43:27 -0400

> draft-ietf-behave-v6v4-xlate-stateful, RFC3089, etc.)

these are all well known problems that have been here for ... since
IPng happened. You make a new protocol that's not compatable on the
wire with the old one and, you'll surely have an interesting time
transitioning. Deprecate the only feasible transition technology and
... well you have what we have today.

I'm not sure I see, aside from a few well documented straightforward
cases, why there needs to be a lot more added to the set of ways we
can provide v6 to the existing v4 user base. I'm not sure how much
more we have to deliberate the 'if you only have ipv6 you can't see
anything on the current internet" discussion either.

> across NAT64, this will lead the losing of subscribers for operators.

sure, this also isn't huge news. Folks will only deploy when they are
ready and when there is a financial incentive for them to do the work
required... UNLESS they see that there is a coming end-time and they
MUST be prepared for it, and that preparing NOW when you can do it
leisurely is far better than doing it under the gun tomorrow.
(today/tomorrow of course are 5 years ago and last week, but...)

> version transition. Is this is possible?

how's it worked out so far?

> subscribers for this IPv6 operator.

this didn't come across quite as plainly as you wanted, I suspect...
perhaps you meant:

"A content provider in one locale deploys only ipv4 accessible
services, an ISP in another locale (with perhaps no users of the
content provider's content) deploys native ipv6 (you don't mention if
they already have ipv4, I'll assume you mean 'only ipv6'). The ISP
will lose subscribers since they can't access the content providers
content."

There are quite a few problems with your supposition, mainly that
since the users on the ipv6 only network weren't users of the content
there's no reason for them to even know that it exists.

I think you really mean something like: All consumer ISP networks
today should be able to support ipv6 to their subscribers in one form
or another. There will be cost (capex or opex) for them to deploy,
but... that cost should be shown to be lower than the lost revenues
due to the eventual exodus of their customers when the ipv6 content
providers reign.

I still don't see the above as a problem since eventually (in a
crunch) the ISP will deploy ipv6 because "Some Important Service" to
their customers will be inaccessible. The only option will be to
deploy ipv6 to these customers... It will suddenly be obvious that the
cost to deploy is lower than the cost to NOT deploy (lost subs). This
problem is self-correcting, I think.

Additionally, if the content provider starts losing customers, and
those customers make up a noticeable portion of their revenue stream
they will deploy v6 accessible versions of the content... content
providers today are doing this very thing, actually.

Again, I think it behooves us to speak about 'transit' or 'backbone'
ISP networks apart from 'consumer' ISP networks. There are
significantly different challenges in these two arenas. None are
insurmountable, but v6ops can (and has to some extent) document some
deployment "BCP's".

DanWing has said some similar things as well... although it seems to
me that much of the issue here is a 'follow the money' problem, if
there is monetary reason to do ipv6, it gets done. To date, there has
not been a strong enough story to deploy ipv6 from a financial
perspective (looking across 1 or 2 quarters of fiscal reporting),
where you see it being deployed folks have done so either with the
"This will pay out in the long run" (lorenzo for instance, to name a
particular person who used this reasoning) or "we should do this for
our own good, it will cost us something now, but later we'll be all
set when we HAVE to have ipv6 ready."

-Chris

> ----- Original Message ----- From: "Gert Doering" <[email-masked]>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Sep 2010 14:22:20 +0800

Dear Chris, Dan, Gert et al,
Thank you for all your comments. I started also commenting on others' email, 
couldn't remember from whom.
I'm not an operator. I spoke just like an observer, might not be a good 
observer. I might be wrong.

It's time to look at the two drafts, and comment on them.
http://tools.ietf.org/html/draft-lee-v4v6tran-problem-00
http://tools.ietf.org/html/draft-carpenter-v4v6tran-framework-00

Thanks, good weekend. Hope typhoon does not impact much on the east coast of 
the States and Asia.

B. R.
Tina

----- Original Message ----- 
From: "Christopher Morrow" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "Gert Doering" <[email-masked]>; "Fred Baker" <[email-masked]>; "YangGL" 
<[email-masked]>; <[email-masked]>; "IPv6 v6ops" 
<[email-masked]>; "Kurt Erik Lindqvist" <[email-masked]>; "Behave 
WG" <[email-masked]>
Sent: Friday, September 03, 2010 1:43 PM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

-Chris

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Sep 2010 18:42:13 +0800

B. R.
Tina
----- Original Message ----- 
From: "Christopher Morrow" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "Gert Doering" <[email-masked]>; "Fred Baker" <[email-masked]>; "YangGL" 

[Tina:
OK, I will explain this. For Chinese operators and ICPs, many contents is 
for the nation wide. If an operator with small number subscribers will 
deploy native IPv6, and other operators will deploy dual stack or DS-Lite or 
NAT44. Then most of contents will not support IPv6 at the beginning.
For world wide, some broadband users in China will use some applications 
abroad (e.g. presence application or website), some applications (In 
particular, free application) may not support IPv6. If an operator (not 
mainly operators) will deploy native IPv6, these applications may not 
support IPv6 immediately (maybe IPv6 will be support later) and these 
applications may be blocked in the IPv6 only operator. So the subscribers 
may transit to other operators which deploy dual stack or DS-Lite or NAT44.

I agree that the current IPv4 only contents will support IPv6 (or NAT64) in 
the end. But it is "in the end".

So I don't think that for the wired line operators deploying native IPv6 and 
NAT64 is the best solution at the beginning of migration from IPv4 to IPv6. 
And other solution (e.g. dual stack or DS-Lite or 6RD or dual stack+NAT444) 
may be better.
]

-Chris

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Sep 2010 18:44:47 +0800

B. R.
Tina
----- Original Message ----- 
From: "Dan Wing" <[email-masked]>
To: "'Tina TSOU'" <[email-masked]>; "'Gert Doering'" <[email-masked]>
Cc: "'Behave WG'" <[email-masked]>; "'YangGL'" <[email-masked]>; 
"'Fred Baker'" <[email-masked]>; "'IPv6 v6ops'" <[email-masked]>; 
<[email-masked]>
Sent: Friday, September 03, 2010 12:35 PM
Subject: RE: [BEHAVE] [v4tov6transition] 
draft-arkko-ipv6-transition-guidelines WGLC

> RTSP??  I am interested in what breaks.
[Tina:
Some VPN service (e.g. PPTP VPN).
Some presence applications (e.g. OICQ) don't work across NAT64 by now but 
work across NAT44 Maturely.
]
> IPv6-only subscribers can view the content.
[Tina:
What I said is that the operator which is IPv6 only (provide NAT64 for IPv4 
service) may lose subscribers, but not content provider.

If an operator with small number of subscribers directly deploy native IPv6 
and NAT64 for migration from IPv4 to IPv6, but other operators in the same 
locale deploy dual stack or DS-Lite or other technologies. The contents may 
not support IPv6 immediately. Because of the block of some service, this 
IPv6 only operator will lose of subscribers.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Sep 2010 08:47:45 -0700

> From: Tina TSOU [mailto:[email-masked]]
> Sent: Friday, September 03, 2010 3:45 AM
> To: Dan Wing; 'Gert Doering'
> Cc: 'Behave WG'; 'YangGL'; 'Fred Baker'; 'IPv6 v6ops';
> >> Not all operators support IPv6 at the same time and not all
> operators
> >> deploy
> >> operators in USA don't deploy IPv6 now, and only one Chinese
> operator
> >> deploy

I'm not an expert on PPTP, but it uses TCP for its control channel
and a modified GRE for the tunnel.  TCP will work fine across a 
NAT64.  The problem is most likely the GRE protocol (protocol 47).
Many residential-class NAT44 devices don't support GRE; those that
do, implement some tricks for handling it.  Sometimes those tricks
that work okay on a residential NAT do not work well with a large 
NAT (notably, with a lot of subscribers doing GRE, especially to 
the same VPN concentrator).

There is no standard for how to get GRE across a NAT44, or NAT64.
To my knowledge there is no public description of how this is done,
but I recall seeing GRE traversal implemented in the Linux 
masquerade code.

> Some presence applications (e.g. OICQ) don't work across NAT64 by now
> but work across NAT44 Maturely.

Does OICQ work on an IPv6-only client?  

Searching online, I see several things that appear to be 'OICQ'.  Can
you provide a specific pointer to the specific code you're testing?

> not support IPv6 immediately. Because of the block of some service,
> this IPv6 only operator will lose of subscribers.

Yes, I agree an operator that does not support IPv4 will lose subscribers
that need IPv4.

> I agree that the current IPv4 only contents will support IPv6 (or
> NAT64) in the end. But it is "in the end".

If there is a subscriber need for IPv4, then, yes, subscribers should
be given access to IPv4.  However, that can be provided with a tunnel
such as Dual-Stack Lite.  

I don't see the problem.  What is missing?

-d

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Sep 2010 13:10:44 -0400

> Yes, I agree an operator that does not support IPv4 will lose subscribers

and when either they see that happening, or think it'll start
happening... the money argument kicks in and they will deploy
solutions.

> I don't see the problem.  What is missing?

I'm not seeing what's missing either ;(

-chris

---

From: "YangGL" <[email-masked]>
Date: Fri, 3 Sep 2010 09:59:31 +0800

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:[email-masked]] 
Sent: Friday, September 03, 2010 1:14 AM
To: YangGL
Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; [email-masked]; Kurt

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?

> 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.
but
of
network,
a
customer
but

---

From: "YangGL" <[email-masked]>
Date: Fri, 3 Sep 2010 10:20:08 +0800

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:[email-masked]] 
Sent: Friday, September 03, 2010 1:08 AM
To: 'YangGL'; 'Fred Baker'
Cc: 'Yiu L. Lee'; 'huang cancan'; 'IPv6 v6ops'; [email-masked];
'Kurt Erik Lindqvist'; 'Behave WG'
Subject: RE: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

-d

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 3 Sep 2010 13:17:32 -0700

> happening... the money argument kicks in and they will deploy

Good thing operators don't have to make the binary decision to be
either entirely IPv4 or entirely IPv6.  In many access types,
including mobile, the network operator can choose / engineer / design
a service to be either IPv4, IPv6, or both depending on various
factors (user need, device constraints, ....) that make sense to the
operator and its customers.

I wish we did not need to state the obvious, but clearly we do,
operators will not intentionally deploy services that grossly misalign
with customer expectations.

Cameron

---

From: Rémi Després <[email-masked]>
Date: Sat, 4 Sep 2010 09:18:30 +0200

Le 3 sept. 2010 à 04:20, YangGL a écrit :
> ...
> ...

To progress in this discussion, and in similar ones, a more precise terminology is IMHO needed. 

Here is one proposal to show that problems that seem hard to solve may not be that hard:

- "DS-capable host": a host that has APIs for both v4 and v6 applications.
(Variants depend on how v4 and v6 are supported, natively AND/OR with transition mechanisms such as vX/vY tunnels and NATxy translations).

- "DS-enabled host": a DS-capable host that, where it is, can establish both v4 and v6 connections.

- "DS host": (ambiguous) a DS-capable host OR DS-enabled host (the context should determine which one, but doesn't always do it).

- "IPvX-only routing network": network having only IPvX routing tables.

- "DS routing network": network having both IPv4 and IPv6 routing tables.

- "IPvX-only DS network": a network that has only IPvX routing tables AND whose provider supports a transition mechanism for IPvY.
(Variants depend on which transition mechanisms are supported).

- "IPvX-only non-DS network": a network that has only IPvX routing tables AND whose provider supports NO transition mechanism for IPvY.

- "IPvX-only network": (ambiguous) IPvX-only non-DS network OR IPvX-only DS network (the context should determine which one, but doesn't always do it)

- "DS network": (ambiguous) DS-routing network OR IPv4-only DS network, or IPv6-only DS network 

WITH THIS TERMINOLOGY: a *DS-capable host*, attached an *IPv6-only routing network* can be a *DS-enabled host* (and support unchanged IPv4-capable applications).

This is the case, for example, if:
- The network supports NAT64/DNS64 with its well-known prefix 64:ff9b::/96.
- The host treats all transport connections whose remote IPv6 addresses are IPv4-embedded IPv6 addresses (addresses that start with the WKP) as IPv4 connections at the application API. At the application API, local addresses of these connections may be any IPv4 private address of RFC 1918 (e.g. 192.168.0.1).
Thus, IPv4-capable applications cannot distinguish these connections from IPv4-only connections that traverse NAT44s (and don't need to).
 
NOTE: if connections that traverse NAT64s would be treated at the application API as IPv6 connections, this would break the IPv6 insurance that IPv6 connections having public addresses at bot ends are e2e transparent. 
This would be a step backward.
IPv6-only hosts that may need to communicate with IPv4-only hosts SHOULD therefore always distinguish IPv4-embedded IPv6 addresses and treat them at application APIs as IPv4 addresses .

Regards,
RD

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 4 Sep 2010 12:12:45 -0400

> with customer expectations.

yes. I guess I too assumed that people understood they deployment
scenario (save the most pathological case) would be dual-stack, with
"native" v6 to the user. transport of the "native" v6 may be handled
in different ways depending on the provider's design(s), but really
why would an operator cut off the arm that makes money?

-Chris

---

From: Xing Li <[email-masked]>
Date: Fri, 10 Sep 2010 21:53:14 +0800

> is no big difference between NAT-PT and later technology.

IVI requires ALG, but dIVI (double IVI) does not require ALG. xing

>> So far I cannot find a stateless/stateful solution to solve the problems
>>     
> as above.
>   
>> Best regards,
>> Yang Guoliang
>>
>>
>> Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines
>>     
> WGLC
>   
>> </chair> <!-- v6ops -->

---

From: Xing Li <[email-masked]>
Date: Sat, 11 Sep 2010 08:31:40 +0800

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

> From: Xing Li [mailto:[email-masked]] 
> Sent: Friday, September 10, 2010 9:53 PM
> To: YangGL
> Cc: 'Fred Baker'; 'Behave WG'; 'huang cancan'; 'Yiu L. Lee'; 'IPv6 v6ops';
> Subject: Re: [BEHAVE] [v4tov6transition]
>> Sorry, please let me emphasize my point again: I tested a deprecated
>>     
> NAT-PT
>   
>> 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
>   
>> I don't want to argue again. Since many people question my test result, I
>>     
> am
>   
>> 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
>   
>> behave technology that uses the stateless mode, and the stateful mode of
>>     
> the
>   
> P2P.
>>>> 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.
>>   
>>     
>> work on IPv4-only network with single level and double level NAT44, such
>>     
> as
>   
>> 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
>   
>> with NAT64, the web traffic will go through the NAT once. If his web
>>     
> client
>   
> NAT64,
> run

---

From: "YangGL" <[email-masked]>
Date: Fri, 10 Sep 2010 23:39:40 +0800

Best regards,
Yang Guoliang

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Friday, September 10, 2010 9:53 PM
To: YangGL
Cc: 'Fred Baker'; 'Behave WG'; 'huang cancan'; 'Yiu L. Lee'; 'IPv6 v6ops';

NAT-PT
is
there

am
WGLC
a
the
the
P2P.
on
WEB
we
is
good
as
come
is
70%
IPv6-only
client

NAT64,
run

---

From: "YangGL" <[email-masked]>
Date: Sat, 11 Sep 2010 09:10:42 +0800

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.

Best regards,
Yang Guoliang

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Saturday, September 11, 2010 8:32 AM
To: YangGL
Cc: 'Fred Baker'; 'Behave WG'; 'huang cancan'; 'Yiu L. Lee'; 'IPv6 v6ops';

Regards,

xing

>>> Cc: Yiu L. Lee; huang cancan; IPv6 v6ops; [email-masked];
Kurt
>> running the stateful mode, that what you're reporting is what we have
been
>>>> Tests also prove that almost all of popular applications on Internet
can
>> website. If his web client and PC support IPv6 and on an IPv6-only
network
on
the
>>>> Life cycle of mobile equipments could be every 2-3 years, but life
cycle
NAT64,

---

From: Xing Li <[email-masked]>
Date: Mon, 13 Sep 2010 18:43:35 +0800

> dual-stack, not IPv6-only.

If dIVI is implemented in host, then the host is IPv6 single stack
connecting to the IPv6-only network. The sockets API is dual stack for
the applications running in the host.

regards,

xing

---

From: Xing Li <[email-masked]>
Date: Mon, 13 Sep 2010 18:45:53 +0800

> 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

>> Sure, dIVI does not require ALG, because it work like a tunnel technology
>>     
> in
>   
>>> So you tested one implementation, one that uses a technology that the
>>>       
> IETF
>   
>>> identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to
>>>       
> connect
>   
>>> 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
>   
>>>>  "DNS64: DNS extensions for Network Address Translation from IPv6
>>>>         
> Clients
>   
>>>>  Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch
>>>>         
> van
>   
>>>>> 主题: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines
>>>>>           
> WGLC
>   
>>> content. From this perspective, both experience “could be” very
>>>       
> similar.
>   
>>>     
>>>       
>>   
>>     
>>>   
>>>     
>>>

---

From: "YangGL" <[email-masked]>
Date: Tue, 14 Sep 2010 14:01:49 +0800

Yes, just like ds-lite.

Best regards,
Yang Guoliang

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Monday, September 13, 2010 6:44 PM
To: YangGL
Cc: 'Behave WG'; 'huang cancan'; 'Fred Baker'; 'Yiu L. Lee'; 'IPv6 v6ops';

in

regards,

xing

IETF
Kurt
connect
either
direct
common
been
Clients
van
can
WGLC
network
similar.
on
the
cycle
NAT64,