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

From: Fred Baker <[email-masked]>
Date: Sat, 28 Aug 2010 23:08:58 -0700

</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: huang cancan <[email-masked]>
Date: Mon, 30 Aug 2010 17:04:04 +0800

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

2010/8/29 Fred Baker <[email-masked]>

> 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.
> >
> >
> > 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:
> > On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked] <
> http://[email-masked]> > wrote:
> >

---

From: huang cancan <[email-masked]>
Date: Mon, 30 Aug 2010 17:26:26 +0800

Another reason why we don't test stateless NAT64 is that there are few
application clients support IPv6, we can only test web or mail applications
which are also OK with the stateful one.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Aug 2010 10:38:10 +1200

Hi,

> which are also OK with the stateful one.

But you reported other applications failing. How can they fail with NAT64 if
they have no IPv6 support in the first place?

   Brian

> ------------------------------------------------------------------------
>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 31 Aug 2010 11:12:58 +0800

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" <[email-masked]>
To: "'Fred Baker'" <[email-masked]>
Cc: "'Behave WG'" <[email-masked]>; "'Kurt Erik Lindqvist'" 
<[email-masked]>; "'IPv6 v6ops'" <[email-masked]>; 
<[email-masked]>
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 -->
>> 发件人: [email-masked]
> [mailto:[email-masked]] 代表 Yiu L. Lee
>> 发送时间: 2010年8月25日 22:05
>> 收件人: huang cancan
> 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 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:
>>

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 30 Aug 2010 21:23:36 -0700

Just a few observations without the wg-cochair hat on.

On 8/30/10 8:12 PM, Tina TSOU wrote:
> 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.

Legacy ipv4 only apps aren't going to support v6 period, it has nothing
to do with when operators support or don't support ipv6. legacy
applications do not become new again. see (3) for dicussion of rights.

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

An application that supports nat64 traversal is fact a native ipv6
application that isn't dependent on layer violations for it's signaling
of among other things ip address port numbers or security bindings. You
sort of characterized this in (3).

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

The word "right" is a challenge to me here. Supporting a protocol on a
network is a business decision(for example, when do I add ipv6 aaaa
records to a service in my network). It is is in the interests of
internet service providers to induce as little deliberate breakage into
the network as possible. As a content and services provider (which is
what I do) if I don't adhere to this axiom I get to look for a new job.

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

There is going to be a time where ipv4 only users cannot access a
resource because it only accessible via v6, in superficial cases this
happens all the time. It is in the interests of most if perhaps not all
network operators, application vendors and end users, to push the time
in which that occurs routinely, beyond the window in which ipv6
deployment largely occurs. That said it seems like that workarounds
associated with ipv4 support post-runout will result in a gradually less
usable ipv4 network, which is if anything and incentive against holding
out to the bitter end.

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

p2p applications have a built-in assumption of the existence of usable
endpoint identifiers. To the extent that ipv4 identifiers become
progressively less usable, p2p applications will prefer ipv6, that will
require upgrade or substitution.

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

It is useful to understand what on a v6 native host is not going to work
well through a 6to4 gateway. It is not so useful to have an
existence-proof for problems with ipv4 only applications, given that we
have ipv4-only-hosts to support into the immediately forseeable future.
The assumption that I make with those devices be they embedded systems,
pc's, mobile phones, etc, Is that I have the luxury of zero stack change.

> ----- Original Message ----- From: "YangGL" <[email-masked]>
>>> > experience of IPv4-only + NAT444 could be the same as IPv6-only + >
>>> NAT64,
>> but
>>> there are technologies such as DS-lite and Softwire Mesh available to
>>> run
>> a
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: "YangGL" <[email-masked]>
Date: Tue, 31 Aug 2010 10:27:10 +0800

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

May I ask a question?

---

From: huang cancan <[email-masked]>
Date: Tue, 31 Aug 2010 09:38:34 +0800

hi, Brian:
   Yes, we didn't test the applications with clients installed in people's
PC no matter the NAT64 is a stateful one or a stateless one.
    I think we have a little different understanding about the original
question:"why customer experience of IPv4-only + NAT444 could be the same as
IPv6-only + NAT64? Do you have any test data?" I asked this question for the
sake of making up our migration strategy.
    What we focus on is the customer experiences, so if now the clients
cannot support IPv6, we think the customer experience when we using NAT64 in
our network in the first phase is worse than using NAT444+IPv4 because most
clients supporting NAT444.
   And what you focus on is the NAT64, the technology itself, so you think
if there is no test on NAT64, we cannot draw the conclusion that NAT444 is
better than NAT64.
   By the way, we also think it NAT444+IPv4-only cannot solve the problem
ultimately, NAT444+IPv6 should be better in the first phase.

  Thanks.

On Tue, Aug 31, 2010 at 6:38 AM, Brian E Carpenter <
[email-masked]> wrote:

> agree
> >>> 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:
> >> NAT64, but
> >>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked]<
> >>> Life cycle of mobile equipments could be every 2-3 years, but life
> cycle
> >> of