Subject: [Softwires] Host based translation: v4-v6

From: Hui Deng <[email-masked]>
Date: Tue, 1 Dec 2009 23:21:42 +0800

Dear Alain and Sri,

Based on previous discussion with you two,
I found there is a fundamental mis-understanding about our requirement.

Back to last Behave working group meeting, I personally think that I
presented clearly about our
scenario and requirement about host to host communication is about v4
appliation (host A) talk with v6 application (host B).

I try to figure out what you would like to propose about v4-v4 during
that meeting with you in this list.
But anyhow, could you help to explain how your proposal could work in
our requirement and scenarios,

Many thanks

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Dec 2009 08:13:30 -0800

Hi Hui,

Now, we are closing down on identifying the gap.

1.) IPv6 App communicating with an IPv6 App
2.) IPv4 App communicating with an IPv4 App
3.) IPv6 App communicating with a legacy IPv4 App
4.) IPv4 legacy App communicating with a future IPv6 App

Mainly, the gap seems to be #4 and you want to do host translation for that
scenario. I agree, we do not support that scenario at this point. Surely,
host translation is one option if you want to support that case. Or, one can
do implicit tunnels (Per Alain/Dan's approach). But, I'm not convinced about
that use-case. Your network is IPv6-only network, your host has IPv6-only
transport, but why IPv6 cant be used ? If you give the legacy argument, that
you cannot modify the application, its fine, but this is the case of a
legacy app requiring to talk to a future IPv6 app. You will have to justify
this requirement, given that there are no host to host applications (IPv4 to
IPv6) deployed today. You can off course, simple add IPv4 support to the
peer and done with it and that is a simple solution.

So, the motivation for that is not convincing and you end up modifying the
entire host architecture, take the burden of ALG management and stack
management on million operating systems for years to come. But, why and what
cost ?

Sri

---

From: Simon Perreault <[email-masked]>
Date: Tue, 01 Dec 2009 11:33:13 -0500

> 4.) IPv4 legacy App communicating with a future IPv6 App

I haven't fully followed the discussion up to this point, but here goes...

New "IPv6 apps" are usually not IPv6-only. They are version-independent. See
e.g. RFC4038. So your future app will try IPv4 if it cannot get IPv6
connectivity. Which, it seems to me, would make case 4 fold into case 2.

How that ties into the DS-Lite/PNAT discussion, I leave up to you. ;)

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Dec 2009 08:45:58 -0800

Hi Simon,

Thanks. I guess, Hui will suggest, the host running the future IPv6 app will
not have IPv4 support and it can only use IPv6 transport. And this
application needs to talk to a peer which is a legacy IPv4 application. That
legacy peer application is running on a host which has only IPv6 transport,
but the application is a legacy application and it only open a IPv4
transport and not use IPv6 transport. Might be confusing, but that is the
argument I heard and so I listed it separately, else to most part we can
fold them to #1 or #2, and in some case to #3.

Regards
Sri

On 12/1/09 8:33 AM, "Simon Perreault" <[email-masked]> wrote:

> ly not IPv6-only. They are version-independent. See
> connectivity. Which, it seems to me, would ma

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 01 Dec 2009 12:04:04 -0500

Why go through all that trouble when you could make the server app
dual-stack capable in the first place?
That could be done with or without assigning a unique v4 address to it,
simply running v4 over v6...
Not you¹d be back to a v4 app talking to a v4 app on hosts only having v6
addresses configured natively.

   - Alain.

On 12/1/09 11:45 AM, "Sri Gundavelli" <[email-masked]> wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Dec 2009 09:21:09 -0800

I agree. When there is a case of v4 legacy app unable to use IPv6 transport
for what ever reasons, its rather better to go enable IPv4 on the peer,
still supporting IPv6-only network over dual-stack lite network.  Or, modify
the app to use IPv6 transport and avoid the huge cost and management of
dealing with a modified stack and on all OS variants. We are mainly mixing a
true legacy requirement with new requirements which are debatable.

Sri

On 12/1/09 9:04 AM, "Durand, Alain" <[email-masked]> wrote:

> Why go through all that trouble when you could make the server app dual-stack
> capable in the first place?
> That could be done with or without assigning a unique v4 address to it, simply
> running v4 over v6...

---

From: Hui Deng <[email-masked]>
Date: Wed, 2 Dec 2009 23:20:08 +0800

Hi, Sri,

inline please,

> peer and done with it and that is a simple solution.
Thanks for your clear statement, not support the case,
I understand that you are not familiar with operation and application.
There are
several reasons which have happened such as platform upgrading issue,
host application upgrading issues.
This is the fundamental driving force for us to do it.

> management on million operating systems for years to come. But, why and what
I read throught today DS-Lite and NAT64, none of them support
explicitly ALG, and how does it work.
you would better argue them other than here.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 2 Dec 2009 23:32:01 +0800

Ok, You don't support it as well based on your statement,

you are doubting why we do like this. but this is a seperate topic
I will reply follow sri's email.

-Hui

2009/12/2 Durand, Alain <[email-masked]>:
> Not you’d be back to a v4 app talking to a v4 app on hosts only having v6

---

From: Hui Deng <[email-masked]>
Date: Wed, 2 Dec 2009 23:35:36 +0800

we have multiple reasons to do this,
there are lots of operator are planning to do IPv6 only, most of
people already see that.

one key point, we are doing IPv6, not IPv4,
you are proposing that let's support IPv4, and assign them unlimited
IPv4 address.
finally nobody use IPv6.

Thanks

-Hui

---

From: "Nick Heatley" <[email-masked]>
Date: Wed, 2 Dec 2009 16:40:27 -0000

Hi, Good day to you all.
I hope you don't mind me commenting in your discussion.
Could I ask you please to clarify whether you are discussing UE to UE applications or UE application to hosted App servers?

If it is UE to App server, then surely the App server will need to be dual stacked as a prerequisite? 
IMHO the reasons for why an app server can be IPv6-only are similar reasons to why IPv4 Port Address Translation breaks services - the need for nice unique realms of IP addressing - does that make the use case of IPv4 legacy UE to IPv6 only App server academic (assuming all GI-DSL and P-NAT ultimately require some flavour of port address translation)? I doubt anyone in the operator's network or externally will create an IPv6 only App server just for the sake of it; which I guess supports Alain's and Sri's conclusion previously.

UE to UE is a little different I guess, so is this the driver Hui?
Hui, if you are considering UE to UE do you know of any UE to UE applications implemented today?

Is the key use case (and differentiator) the UE to UE use case with mixed IPv6 and legacy IPv4-bound apps?
To be honest my personal thought is that we could drive UE to UE to be via IPv6 Apps at the UE and an IPv6 bearer only; is this wrong?

Thanks and Regards,
Nick
T-Mobile

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hui Deng
Sent: 02 December 2009 15:36
To: Sri Gundavelli
Cc: [email-masked]
Subject: Re: [Softwires] Host based translation: v4-v6

Thanks

-Hui

2009/12/2 Sri Gundavelli <[email-masked]>:
> Not you'd be back to a v4 app talking to a v4 app on hosts only having v6
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires
T-Mobile (UK) Limited
Company Registered Number: 02382161
Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW
Registered in England and Wales
 
NOTICE AND DISCLAIMER
 
This email (including attachments) is confidential. If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Dec 2009 08:41:17 -0800

Hi Hui,

> I understand that you are not familiar with operation and application.

Fine. Explain why you need to support the case of a legacy IPv4 application
communicating with a IPv6 future application. This scenario is not there
today. And, why in such scenario you cannot enable IPv4 on the peer ? Or,
simply use IPv6. No matter what, you are supporting dual-stack terminals as
well, you may forward a translated IPv6 packet on the air interface and on
the access and core, but you are supporting IPv4 application and allowing
them to communicate with IPv4 internet and so you are leading those packets
to the NAT64 gateway.

> This is the fundamental driving force for us to do it.

May be in your PS document, you need to provide a detailed explanation for
this. As far I see, no one is convinced about this argument, but I could be
wrong. Enlighten me please.

> you would better argue them other than here.

What ever you do on the host, they tunnel it and just do it at the gateway.
I don't see the difference, and they don't change the host stack.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Dec 2009 08:41:40 -0800

Hi Hui,

> there are lots of operator are planning to do IPv6 only, most of

I agree, yes, some operators for operational reasons are considering
IPv6-only network. Will they achieve that ? May or may be not. But, lets go
with that assumption for this discussion.

> you are proposing that let's support IPv4, and assign them unlimited

No, you are offering IPv4-only for the applications :)

I'm saying, support the case of IPv6-only operational network, 3GPP access
does support that, the core network can be IPv6 only as well. So, we have
IPv6-only network all across.

- Allow the applications to use IPv6 for host to host applications
- allow legacy IPv4 applications to communicate over IPv4 (per your argument
that only binaries exist for those applications),
- allow v6-only nodes to communicate with v4 internet peers using NAT64.

But, don't deal with the case of IPv4 legacy application communicating with
a IPv6 future application using IPv4. By allowing that one case which has no
justification, you have to deal with the resulting baggage of host
translation and UE changes. Instead use IPv6 for host to host as you say.
This is not a legacy issue.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Dec 2009 08:46:27 -0800

Hi Nick,

On 12/2/09 8:40 AM, "Nick Heatley" <[email-masked]> wrote:

> Could I ask you please to clarify whether you are discussing UE to UE
> applications or UE application to hosted App servers?
> 
> IMHO the reasons for why an app server can be IPv6-only are similar reasons to
> why IPv4 Port Address Translation breaks services - the need for nice unique
> realms of IP addressing - does that make the use case of IPv4 legacy UE to
> IPv6 only App server academic (assuming all GI-DSL and P-NAT ultimately
> require some flavour of port address translation)? I doubt anyone in the
> operator's network or externally will create an IPv6 only App server just for
> the sake of it; which I guess supports Alain's and Sri's conclusion
> previously.
> 
> To be honest my personal thought is that we could drive UE to UE to be via
> IPv6 Apps at the UE and an IPv6 bearer only; is this wrong?
>

Thanks for your comments.

I agree. Use IPv6 as a transport in all peer to peer applications and for
non legacy applications.

Regards
Sri

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 2 Dec 2009 09:29:50 -0800

> you are proposing that let's support IPv4, and assign them unlimited

This is a backwards looking statement not inline with the direction
major content providers like Google, Netflix, Limelight and others.
Yes, IPv6 content is limited today, but it is growing.  It must growh.
  The only way to restore the end-to-end principle is to push native
IPv6, which will invariably be a better service than any LSN or
tunneling technique for users, operators, and content alike.

As a key contributor at a very large network, you and your colleagues
have a very powerful position in in accelerating IPv6 adoption.

As pointed out in this NANOG deck, content has consolidated.  That
said, it only takes a few major players on the content side to make a
dramatic difference

http://www.nanog.org/meetings/nanog47/abstracts.php?pt=MTQ1MyZuYW5vZzQ3&nm=nanog47

And Google, the largest content player, has dramatically increased the
available IPv6 content.

http://www.google.com/intl/en/ipv6/

Cameron Byrne
T-Mobile USA

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 2 Dec 2009 17:42:40 -0500

Hi Hui,

I think Sri has a point. Why we want an v4 app communicates to a future
v6-only app host-to-host? If we start doing this, we will discourage the v4
apps to migrate to v6. Isn't it against what we want the applications to
migrate to v6?

Thanks,
Yiu

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 03 Dec 2009 10:03:19 +0800

Hi all,

I have some comments on this topic, please see inline.
If I have some mistakes please let me know, thanks!

Regards
Xiangsong

----- Original Message ----- 
From: "Nick Heatley" <[email-masked]>
To: "Hui Deng" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 03, 2009 12:40 AM
Subject: Re: [Softwires] Host based translation: v4-v6

Hi, Good day to you all.
[Xiangsong] +1

If it is UE to App server, then surely the App server will need to be dual 
stacked as a prerequisite?

[Xiangsong] I don't think so, for the case IPv4 UE => IPv6 App server,
I think it fits section 2.2 of 
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-03
in this scenario, IVI stateless translation may be considered, but the 
address space of
the IPv6 App server is limited. of course, DS App is better :)
More question is who is pushing IPv6 transition? although we are studying 
the solutions.
In my understanding, there are three players in this field, user, carrier 
and ISP,
#1 USER is the driving power? This seems what we are doing now, many UE&PC 
OS
     can support IPv6, but IP service is few, sorry I only know Google on 
IPv6 service.
     In this case, stateful translation is the most important candidate 
solution.
     But in my mind, Users do not care IPv4 or IPv6, they are invisible to 
users.
#2 CARRIER is the driving power? This is also an important direction,
     especially for the IPv4 address shortage issue, I think DS lite is for 
this case,
     many other tunnel solution may be considered.
#3 ISP is the driving power? I think ISP's involvement will quicken the 
transition procedure.
     But maybe we have not pay enough attention to this case? I don't know 
well the reason.
     Is that because ISP is marketing driven but not technology driven?
     ISP would more care what benefits they can get during the IPv6 
transition?
     In http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-03, it 
is looked hard case,
     and only IVI translation is mentioned (with some limitation), shall we 
pay more attention
     on this item?   Does Hui's approach cover this case?
Because these three players are independent, IMHO, two-players-drivern 
transition is more
complex.       As to UE to UE scenario, I have no idea.

Regards
Xiangsong

IMHO the reasons for why an app server can be IPv6-only are similar reasons 
to why IPv4 Port Address Translation breaks services - the need for nice 
unique realms of IP addressing - does that make the use case of IPv4 legacy 
UE to IPv6 only App server academic (assuming all GI-DSL and P-NAT 
ultimately require some flavour of port address translation)? I doubt anyone 
in the operator's network or externally will create an IPv6 only App server 
just for the sake of it; which I guess supports Alain's and Sri's conclusion 
previously.

UE to UE is a little different I guess, so is this the driver Hui?
Hui, if you are considering UE to UE do you know of any UE to UE 
applications implemented today?

Is the key use case (and differentiator) the UE to UE use case with mixed 
IPv6 and legacy IPv4-bound apps?
To be honest my personal thought is that we could drive UE to UE to be via 
IPv6 Apps at the UE and an IPv6 bearer only; is this wrong?

Thanks and Regards,
Nick
T-Mobile

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Hui Deng
Sent: 02 December 2009 15:36
To: Sri Gundavelli
Cc: [email-masked]
Subject: Re: [Softwires] Host based translation: v4-v6

Thanks

-Hui

Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, 
AL10 9BW

NOTICE AND DISCLAIMER

This email (including attachments) is confidential. If you are not the 
intended recipient, notify the sender immediately, delete this email from 
your system and do not disclose or use for any purpose.
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 03 Dec 2009 10:50:18 +0800

Sorry all, I have found a mistake in my mail :(
When I said ISP in my previous mail,  I actually wanted to
mean *Application Service Provider* or *Internet Content Provider*

Thanks and Regards
Xiangsong

----- Original Message ----- 
From: "Xiangsong Cui" <[email-masked]>
To: "Nick Heatley" <[email-masked]>; "Hui Deng" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 03, 2009 10:03 AM
Subject: Re: [Softwires] Host based translation: v4-v6

> To: "Hui Deng" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> I think it fits section 2.2 of http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-03
> in this scenario, IVI stateless translation may be considered, but the address space of
> More question is who is pushing IPv6 transition? although we are studying the solutions.
> In my understanding, there are three players in this field, user, carrier and ISP,
> #1 USER is the driving power? This seems what we are doing now, many UE&PC OS
>     can support IPv6, but IP service is few, sorry I only know Google on IPv6 service.
>     In this case, stateful translation is the most important candidate solution.
>     But in my mind, Users do not care IPv4 or IPv6, they are invisible to users.
>     especially for the IPv4 address shortage issue, I think DS lite is for this case,
> #3 ISP is the driving power? I think ISP's involvement will quicken the transition procedure.
>     But maybe we have not pay enough attention to this case? I don't know well the reason.
>     ISP would more care what benefits they can get during the IPv6 transition?
>     In http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-03, it is looked hard case,
>     and only IVI translation is mentioned (with some limitation), shall we pay more attention
> Because these three players are independent, IMHO, two-players-drivern transition is more
> IMHO the reasons for why an app server can be IPv6-only are similar reasons to why IPv4 Port Address Translation breaks services - 
> the need for nice unique realms of IP addressing - does that make the use case of IPv4 legacy UE to IPv6 only App server academic 
> (assuming all GI-DSL and P-NAT ultimately require some flavour of port address translation)? I doubt anyone in the operator's 
> network or externally will create an IPv6 only App server just for the sake of it; which I guess supports Alain's and Sri's 
> conclusion previously.
>
> This email (including attachments) is confidential. If you are not the intended recipient, notify the sender immediately, delete 
> this email from your system and do not disclose or use for any purpose.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Dec 2009 19:27:30 -0800

Hi Xiangsong,

Please see inline.

> the IPv6 App server is limited. of course, DS App is better :)

I agree, generally for this scenario of IPv4 UE to IPv6 App server, the
stateless IVI can be used, or simply enable dual-stack on the server. But,
bringing this to the context of the discussion, the host in this scenario is
not a legacy IPv4 host, but has only IPv6 transport. So, for all practical
purposes, the host can simply initiate an IPv6 session. The discussion was a
very specific case, a legacy IPv4 application running on a IPv6-only
transport platform and establishing an IPv6 session, which is the only
standing case for supporting a host based translation solution.

> complex.       As to UE to UE scenario, I have no idea.

Good points. The motivation for the discussion is to identify the key UE to
UE scenarios, validate them to see what are the real requirements and note
the available solutions for those cases. I listed the scenario's in my
earlier mail, I'm hesitant to agree with one case, which is the only
standing point for the entire PNAT solution.

Regards
Sri

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 03 Dec 2009 12:04:37 +0800

Hi Sri,

please see inline.

Xiangsong

----- Original Message ----- 

[......]
> standing case for supporting a host based translation solution.
I think I can understand this scenario,
As I said, there are three players, Carrier and SP have already been in 
IPv6 phase, and UEs are on the way, I think this should be a late phase
in IPv6 transition. Mayne the scenario 4 of 
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-03
If the network where the SP server lies in is IPv6 only,
DS Server + tunnel over IPv6 is troublesome, so we can think SP server
uses IPv6-only manner for these sessions.

In this situation, NAT is necessary, I do agree your opinion that PNAT
is moving NAT function from network to UEs, but this approach may be
good or bad.

Advantage: it can improve end-to-end transparency and simplify network,
                  especially administration, and others.
Disadvantage: it improve the UE cost explicitly, and others.

What I am not sure, is this approach easy to implement?
Is there any cheap middle-ware that UE can implement? if UEs can 
download some middle-ware from their operator, there is no problemt.
Of course, this requires UEs to support this function. or if UEs like, they
can in-build this function when they are manufactured.
Another case is custom-built UEs, this is a normal case, operator insert
something in the UEs, all IPv4 applications may be re-used, and IPv6-only
applications and IPv6-only network are both OK.

Does that make sense?

Regards
Xiangsong
> standing point for the entire PNAT solution.

[......]

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Dec 2009 20:22:22 -0800

Hi Xiangsong,

Please see inline for one clarification.

>                   especially administration, and others.

The discussion slightly digressed. But, its fine and for this comment, its
not really true that host translation will preserve end-to-end transparency.
That is a myth. Any time Hui's PNAT host with its IPv6 transport
communicates with an IPv4 host on the internet, Hui will move the IPv6
packet translated from the IPv4 packet to the NAT64 gateway (to be precise,
PNAT64) anyways, and there the IPv6 to IPv4 packet translation will be done.
In fact, per Hui its only header translation on the host and the payload
translation is done on the CGN gateway. So, there goes the end-to-end
transparency and the simplified network argument.

> Disadvantage: it improve the UE cost explicitly, and others.

And exponentially, consider all the OS's and version variants. But, on a
lighter note, there is one more advantage point that you missed, employment
for many folks for years to come for managing the PNAT stack on many OS's :)

Regards
Sri

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 03 Dec 2009 13:02:07 +0800

Hi Sri,

I just want to show the perhaps scenario for this topic :)

I do not know well the advantage/disadvantage of this approach,
and I also don't know whether it is easy to implement,
but these aspects are so core issues...

What I do know is that the operator will have to pay partial or
even total cost for this solution, otherwise, more expensive device
will lead to less subscribers.

That all my thought on this item.

Thanks and Regards
Xiangsong

----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; "Nick Heatley" <[email-masked]>; "Hui Deng" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 03, 2009 12:22 PM
Subject: Re: [Softwires] Host based translation: v4-v6

---

From: bo zhou <[email-masked]>
Date: Thu, 3 Dec 2009 13:09:08 +0800

Reply in line.

> transparency and the simplified network argument.

[Bo] If in 4-6-4 scenario PNAT goes the E2E transparency argument. I
believe DS-lite will goes the argument as well. DS-Lite need the AFTR has
the capability of 44 translation, also against the concept of E2E
transparency.

> for many folks for years to come for managing the PNAT stack on many OS's
   [Bo] If it is true, it is really a good solution not only for the company
but also for the global economy crisis. How to encourage company hire more
employees is a big headache of governments, like Obama pointed out couple
weeks ago.
Go back to the earth, I am not sure which solution make more cost, update
the host stack by a tiny software upgrade or buy hundreds of hardware
equipments which cost hundred million dollars.  suppose you can show us some
financial validation result as your evidence. if not, please do not make
this as a challenge point here.

Regards,

Bo

Regards
Sri

-- 
Regards,

Bo Zhou
China Mobile

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 2 Dec 2009 21:20:59 -0800 (PST)

Hi Bo,

> [Bo] If in 4-6-4 scenario PNAT goes the E2E transparency argument. I believe DS-lite will goes the argument as well. DS-Lite need the AFTR has the capability of 44 translation, also against the concept of E2E transparency.
>

Agree. I dont believe DS-lite makes E2E transparency argument. So, we
both agree, host-based translation does not have E2E advantage in
this case.

>   [Bo] If it is true, it is really a good solution not only for the company but also for the global economy crisis.

:)

Regards
Sri

---

From: bo zhou <[email-masked]>
Date: Thu, 3 Dec 2009 14:54:41 +0800

Reply in line.

> both agree, host-based translation does not have E2E advantage in

[Bo] I agree "DS-lite makes E2E transparency argument." But left part I do
not agree. Host-based translation can make the applications running through
the transport network transparency, never care what kind of transport
network (IPv4, IPv6) running. Considering of E2E concept, sort out issues at
the end is better than in the middle of network.
By the way, I think there is a tricky point in DS-lite, DS-lite can assign
unlimited IPv4 address to the host, the concept behind this point is very
similar as A+P: *save IPv4*, I believe DS-lite is a good solution to save
IPv4, but I am not sure it is a good solution for IPv6 migration and
deployment. People use DS-lite solution never want to update their service
to support IPv6, because no risk of IPv4 address exhaustion exist if DS-lite
running well.

>> but also for the global economy crisis.
>>
>
> :)
>
>
> Regards
> Sri
>
>

-- 
Regards,

Bo Zhou
China Mobile

---

From: Hui Deng <[email-masked]>
Date: Thu, 3 Dec 2009 20:32:09 +0800

Hi, Nick,

Thanks for the discussion.

> Could I ask you please to clarify whether you are discussing UE to UE applications or UE application to hosted App servers?
==> we are doing both.

> If it is UE to App server, then surely the App server will need to be dual stacked as a prerequisite?
==> not always true, some are dual stack, other could be only.

> IMHO the reasons for why an app server can be IPv6-only are similar reasons to why IPv4 Port Address Translation breaks services - the need for nice unique realms of IP addressing - does that make…
==> Here your assumption is not true, for host to host communication,
I don't see the necessity of port address translation.
IPv6 only app server is design mainly be visited by inside the network
other than outside.

> Hui, if you are considering UE to UE do you know of any UE to UE applications implemented today?
==> it does exist in our work, and doesn't this sound fancy
application which would encourage the growth of mobile internet?

> Is the key use case (and differentiator) the UE to UE use case with mixed IPv6 and legacy IPv4-bound apps?
==> at this moment, legacy IPv4-bound apps is mandate to support since
some of key application is not easily to be upgraded.

> To be honest my personal thought is that we could drive UE to UE to be via IPv6 Apps at the UE and an IPv6 bearer only; is this wrong?
==> you are making the second Internet, it is not migration of the
current Internet, I would not say it is wrong.

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 3 Dec 2009 20:37:18 +0800

Hi, Sri,

Inline please,

> them to communicate with IPv4 internet and so you are leading those packets
There are some IPv4 applications charged because of codec or whatever
reason, they
exist in this network, and they need visit future IPv application.

why we don't enable IPv4 on the peer? because peers don't have such
huge scalable IPv4 address.

> wrong. Enlighten me please.
Above.

> I don't see the difference, and they don't change the host stack.
you are backing to v4-v4

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 3 Dec 2009 20:43:52 +0800

Hi, Sri,

Inline please,

> This is not a legacy issue.
You are making two different seperated world, it won't success.
You didn't answer my previous two emails in seperated line.
I could ask here again, you are assigning unlimited IPv4 address to the host,
and encouraging me to install IPv4 appliation server, I feel what you proposed
is more like prolong IPv4 world and solveing the problem of IPv4
address exhaustion but not IPv6 migration.
Based on your proposal, IETF would better to setup a working group about
IPv4 address exhaustion about it, other than IPv6 migration.

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 3 Dec 2009 20:51:47 +0800

inline please,

> tunneling technique for users, operators, and content alike.
Are you predicting how many years? 10-20?
It may also important that we need consider developers more than
content provider.

> http://www.nanog.org/meetings/nanog47/abstracts.php?pt=MTQ1MyZuYW5vZzQ3&nm=nanog47
thanks,

---

From: Hui Deng <[email-masked]>
Date: Thu, 3 Dec 2009 20:53:25 +0800

Hi, Yiu,

I replied in his email, thanks for your remindness.
our key is that we need support developers.

thanks

-Hui

---

From: Zhen Cao <[email-masked]>
Date: Thu, 3 Dec 2009 22:06:00 +0800

Hi Sri,

I think this scenario is practical. In the host to host communication,
some users have upgraded their IPv4 app, but some do not. You cannot
guarantee that all the users have updated their apps.

Thanks,
Zhen

---

From: Zhen Cao <[email-masked]>
Date: Thu, 3 Dec 2009 22:10:06 +0800

> connectivity. Which, it seems to me, would make case 4 fold into case 2.

Hi Simon, I checked 4038 and found it is informational. And I do not
think applications developers will indeed follow this. For example,
RFC4294 defines IPsec as a MUST for IPv6 node, but from our equipment
test, we found this is a myth.

Thanks,
Zhen

---

From: Zhen Cao <[email-masked]>
Date: Thu, 3 Dec 2009 22:19:55 +0800

Hi Alain,

Dual stack capable application servers absolutely add to the
development cost. It does NOT get through all that trouble.

Thanks,
Zhen

---

From: Simon Perreault <[email-masked]>
Date: Thu, 03 Dec 2009 09:25:21 -0500

Zhen Cao wrote, on 2009-12-03 09:10:
> think applications developers will indeed follow this.

The fact that it is information is irrelevant. This is how applications are
being developed *right now*. We have experience with this, having ported many
applications to IPv6. This method is taught in seminars, books, etc. There is no
speculation here.

> For example,

How is IPsec relevant to an application?

As far as I know, the IPsec API is still in early stages:
http://tools.ietf.org/html/draft-ietf-btns-c-api-04
http://tools.ietf.org/html/draft-mglt-btns-ipsec-api-requirements-00

Simon

---

From: "Durand, Alain" <[email-masked]>
Date: Thu, 03 Dec 2009 09:25:06 -0500

On 12/3/09 1:54 AM, "bo zhou" <[email-masked]> wrote:
> 
> [Bo] I agree "DS-lite makes E2E transparency argument." But left part I do not
> agree. Host-based translation can make the applications running through the
> transport network transparency, never care what kind of transport network
> (IPv4, IPv6) running. Considering of E2E concept, sort out issues at the end
> is better than in the middle of network.
> similar as A+P: save IPv4, I believe DS-lite is a good solution to save IPv4,
> but I am not sure it is a good solution for IPv6 migration and deployment.
> People use DS-lite solution never want to update their service to support
> IPv6, because no risk of IPv4 address exhaustion exist if DS-lite running
> well. 
> 
> ===> Bo: 
> From a service provider perspective, what matter is NOT which flavor of IP I
> like or don¹t. What matters is the service
> I can offer to my customers. It is true that today, a v4 service has much more
> value than a v6 service. Things will certainly change, but right now, this is
> the case.
> 
> Now, I want to refute your argument than running DS-lite, you¹ll never want to
> update the service to support IPv6.
> First and foremost, DS-lite runs over IPv6. That is you MUST deploy IPv6 in
> the access network to deploy DS-lite.
> Second, this is the opportunity to break the chicken and egg problem. Now, you
> have a real v6 access network in place, you can have a serious conversation
> with application vendors & content providers  to port their stuff to IPv6.
> Third, every packet that moves over the now enabled IPv6 network is a packet
> that does not move over the DS-lite NAT AFTR IPv4 box. Ie, the more IPv6
> traffic we get, the less reliance we have on that NAT infrastructure and we
> can expect to cap the cost.
> 
> Is it a slower route than Œmandating¹ IPv6 everywhere right now? Sure. But at
> least it is a doable thing, that makes business sense.
> In the last 15 years, the argument ³let¹s just do IPv6² has not been very
> successful...
> 
>    - Alain.

---

From: "Durand, Alain" <[email-masked]>
Date: Thu, 03 Dec 2009 09:34:50 -0500

> development cost. It does NOT get through all that trouble.
===> How so? Operating systems ARE dual-stack today. All the apps I know of
have been ported to dual-stack, not IPv6-only...

   - Alain.

---

From: Zhen Cao <[email-masked]>
Date: Thu, 3 Dec 2009 22:37:09 +0800

> applications to IPv6. This method is taught in seminars, books, etc. There is no

Good. You are saying that this happens for ported applications, but
that's only part of the story. We will have many new IPv6 applications
in the future.

> How is IPsec relevant to an application?

I referred to this to prove that applications developers do not go
ahead as documented.

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Dec 2009 09:39:58 -0800

Hi Hui:

You and Bo touched a very important point. Your point is that DS-lite is
just about IPv4 address exhaust and not about migration. You already heard
from Alain and that's the best source. But, I'll comment in the context of
mobile architectures and application of GI-DS-lite.

1. DS-lite has an important property, making IPv4 address some what
irrelevant in the context of IP routing and just make it a simple state in
two places, the mobile node and the NAT44 gateway. Its allowing the network
to migrate to IPv6 day-1, remove traces of IPv4 in the core and access
network, but continue to offer IPv4 services.

If this is not migration what is it ? Now, if the technology is also
allowing multiplicity assignment of the same IPv4 address to all mobile
nodes (since, the address is just a state on the gateway and is not used for
IP routing), that's a side affect and solves the address exhaust problem to
some extent. But, there is still limitation w.r.t the public address usage
on the NAT44 gateway.

2. Lets look at PNAT. Your single biggest motivation is to allow your legacy
IPv4 applications to work on an IPv6 host that has only IPv6 transport and
on IPv6-only core network. How are you achieving this ? Your IPv4
application is using an IPv4 address (valid or invalid) and there is a
socket and translation state that is getting created on the host and on the
NAT44 gateway, your routing is all based on IPv6. You are making IPv4 just a
state in the host and on the gateway.

What is the difference between #1 and #2 ? PNAT is solving all that DS-lite
solves and also has an indirect property of solving the IPv4 address exhaust
issue. But, its coming at a huge cost and baggage i.e., Host changes.

3. When I apply DS-lite to mobile architectures which already have good
support for dual-stack and the ability to carry both IPv4 and IPv6 on
mobility tunnels, its allowing an operator to migrate their network to
IPv6-only and is also solving the address exhaust issue.

- No changes to UE
- UE can be IPv4-only or IPv6-only
- Access network can IPv6-only
- Core network (PGW-CGN) can be IPv6-only
- Allow IPv6 for UE to UE communication. Allow IPv4 to IPv4 UE to
communication when using non-overlapping IP addresses. Allow IPv6
applications to communicate with IPv4 end node using NAT64.
- Allow access network and core network to migrate to IPv6 at different
point of time.

But, its missing one hypothetical case, which the scenario is not realistic
and even otherwise, one can always enable dual-stack on the other peer, or
use IPv6 transport.

So, my friend, Dear Hui, there is no difference between what you want to
solve and what is on the table. Tell me, what I'm missing.

Regards
Sri

---

From: bo zhou <[email-masked]>
Date: Fri, 4 Dec 2009 21:04:01 +0800

Dear Alain, thank you for your comments.
I have some comments inline.

On Thu, Dec 3, 2009 at 10:25 PM, Durand, Alain <
[email-masked]> wrote:

> From a service provider perspective, what matter is NOT which flavor of IP
> I like or don’t. What matters is the service
> I can offer to my customers.
>
> [bo] Does this mean DS-lite care operator's service rather than IPv6?

>  It is true that today, a v4 service has much more value than a v6
> service. Things will certainly change, but right now, this is the case.
>
> [bo] So from the view of DS-lite, when the change will become true?

>
> Now, I want to refute your argument than running DS-lite, you’ll never want
> to update the service to support IPv6.
>
> [bo] HBT encourage v4 host to visit v6 server, but DS-lite recommend visit
IPv4 application server.

>  First and foremost, DS-lite runs over IPv6. That is you MUST deploy IPv6
> in the access network to deploy DS-lite.
>
>
[bo] DS-lite use the closed IPv6  bearer network and only tiny part of whole
Internet. This is the excuse DS-lite try to assign unlimited IPv4 address.
This closed bearer network could be any network, such as GRE tunnel.

>  Second, this is the opportunity to break the chicken and egg problem.
> Now, you have a real v6 access network in place, you can have a serious
> conversation with application vendors & content providers  to port their
> stuff to IPv6.
>
>
[bo] But DS-lite do not deploy IPv6 server, am I right?

>  Third, every packet that moves over the now enabled IPv6 network is a
> packet that does not move over the DS-lite NAT AFTR IPv4 box. Ie, the more
> IPv6 traffic we get, the less reliance we have on that NAT infrastructure
> and we can expect to cap the cost.
>
>
[bo] Because DS-lite assign unlimited IPv4 address to the UEs, so UEs will
keep using IPv4 traffic through the AFTR.

>
> Is it a slower route than ‘mandating’ IPv6 everywhere right now? Sure. But
> at least it is a doable thing, that makes business sense.
> In the last 15 years, the argument “let’s just do IPv6” has not been very
> successful...
>
>
[bo] Well, somebody do not want to do IPv6, we just want to try.

-- 
Regards,

Bo Zhou
China Mobile

---

From: Hui Deng <[email-masked]>
Date: Fri, 4 Dec 2009 22:46:02 +0800

Hi, Sri,

Thanks for the discussion, inline please

> network, but continue to offer IPv4 services.
DS-Lite is providing unlimited IPv4 address to the UE, partly modify
the small part of the bear network
which could be constructed by multiple technologies such as GRE, L2TP,
IPv6 tunnel. I don't see
those tunnels have big difference.

> If this is not migration what is it ? Now, if the technology is also
It is "Save IPv4" as Bo said before,

> some extent. But, there is still limitation w.r.t the public address usage
yes, this is really a smart technology which could save IPv4.

> on IPv6-only core network. How are you achieving this ? Your IPv4
It has already happened, and you already see our slides.

> issue. But, its coming at a huge cost and baggage i.e., Host changes.
We spend two weeks here, and you admit that you don't support our
first scenario.
do u need I point out the mailing list link about what you said?
everybody is changing his host everyday by installing new software,
you may be scared to change your laptop, but I am not that afraid.

> - Allow access network and core network to migrate to IPv6 at different
I would say that you made a fantastic invention which really saves
IPv4, good work.
I come out of a good idea that during next IETF, we would better to
propose a BoF about "Save IPv4"
Bo could become the BoF chair (if AD allows), then invite
GW-Init-DS-Lite ... to join.

> solve and what is on the table. Tell me, what I'm missing.
Dear Sri, I really don't want to point to that link where you said a
few days ago that you don't support it.

Thanks

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 04 Dec 2009 08:58:47 -0800

Hi Hui,

> It is "Save IPv4" as Bo said before,

Hmm ... I cant beat this defense.

I don't see you disagreeing with my technical points and the similarities I
have shown in both the approaches. But, I see that you do not want to agree
and so you summarize it to say, its still just a solution for IPv4-exhaust
and not a step towards migration, with no backing by any technical
arguments. That is fine. We agree or not, its just translation vs.,
tunneling, a scheme that was adopted in the earlier versions of DS-lite and
made a conscious decision not to go with host-based translation scheme.

Bottom line, we touched about the core aspects and also one use-case that
you say is the key motivation for your chosen approach, which the use-case
itself is debatable and a clear solution exists as many folks pointed out,
enable dual-stack on the server, or use IPv6. We also talked about the key
resulting benefits in each of the solutions. As far I see it, when
DS-lite/GI-DS-lite is applied to mobile architectures, we have all the
required tools for migration.

Regards
Sri

---

From: Hui Deng <[email-masked]>
Date: Sat, 5 Dec 2009 22:39:04 +0800

Hi Sri,

> made a conscious decision not to go with host-based translation scheme.
We are discussing 4-6 scenario here, it sounds strange that it is
always deviated to another direction.
I don't see how it is related to translation vs tunneling.

> resulting benefits in each of the solutions. As far I see it, when
As far as I can see, the technical argument about our motivation
hasn't been questioned any more.
And for solutions, you already agreed that you are no supporting that.

> required tools for migration.
I guess that this is only said by one people, every other people has
different opinion on this.

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 05 Dec 2009 08:49:18 -0800

Hi Hui,

As I said and to repeat one more time, I'm not convinced about that
use-case. This is not a legacy issue, there are no deployed applications
currently operating in that mode. We talked to many operators, every one is
planning to use IPv6 transport for the UE to UE scenario. This argument that
both the hosts are IPv6-only capable, but they cant use IPv6 transport is
not going to go any where.

We are talking about four lines of code change to use an IPv6 socket. As
some one pointed out, when Apple released the new 3GS, all most 80K
applications required a re-compile. I don't get the point that you have an
IPv4 app, binaries only, but that will run on some future platform with out
recompile and talk to a future IPv6 application. May be your app development
process is broken, this is not a technical or a industry problem.

I'm not deviating from this point, as I said many times, we don't deal with
this case, its not realistic and there is a work around. If you have any
advantages in the host-based translation approach that help in IPv6
migration besides this artificial use-case, let me know.

Regards
Sri

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 5 Dec 2009 13:37:21 -0800

> different opinion on this.

Make that 2, i agree with Sri

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: Hui Deng <[email-masked]>
Date: Sun, 6 Dec 2009 18:18:50 +0800

Hi Sri,

It's quite clear same as you said here, there are binary codes and codec codes
which need additioinal payment for updating, it's a existing scenario.

What I don't understand is that there is the problem quite clear need
to be solved by someone,
but other people don't want to solve those problem just because his
solution doesn't support it, ,
and then they strongly prevent other people from solveing the problem
I don't think it is good way in IETF.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Sun, 6 Dec 2009 18:28:37 +0800

Hi Sri,

I found the difference between your WG mailing list response and
offline response,
during offline, you agreed that other opeartor also agree me there are
the same problem that they have diffculty to update their
applications.

but anyway, I think you agreed now.

thanks

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 06 Dec 2009 08:30:02 -0800

Hi Hui,

> which need additioinal payment for updating, it's a existing scenario.

I do not understand this response. I'm not a codec or a DSP expert, but I
don't see how when you change an application to use IPv6 socket from an IPv4
socket, the codec has to change. I assume the SDP protocol can handle both
the versions in media description. I'm sure, some RTP, SDP or media experts
in the list can comment on this.

> I don't think it is good way in IETF.

No. You have to convince the WG, not me. You started the thread, I disagreed
with this use-case and I don't believe this is a valid requirement. But, to
take your stand for a second, even if this is real and some how we are not
appreciating that requirement, this should be one of those rare applications
that have to be retired. You don't change the whole host architecture for
these one of a kind rare applications and bring all the host change baggage.
In migration, there is a cost as well.

Regarding your comment that I agreed offline that it is difficult to change
legacy deployed applications. *Yes*. I'm talking about *deployed*
applications, not about future applications dealing with future scenarios.
Please give the context along with the comment. All you need is one line
requirement for your application developers to use both IPv4 and IPv6
sockets for the future applications that they write, that's all. Note, this
is not a legacy deployed application requirement, its about a future
application unable to use IPv6 transport, compiled for an IPv6-only
platform.

Lets allow others to comment. We made our points and we are not converging.

Regards
Sri

---

From: Hui Deng <[email-masked]>
Date: Mon, 7 Dec 2009 10:28:41 +0800

Hi Sri,

My purpose here is just discuss whether you support it or not,
I will summarize now, thanks for your discussion.

before I leave, just one comment:
I don't see solutions here solving any IPv6 problem,
they are solving IPv4 problem by assiging unlmited Ipv4 address, it
greatly prolong the life of IPv4
such a great invention, congratulations. but we are not convinced that
IETF should standardize it.

thanks again.

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 6 Dec 2009 19:09:50 -0800 (PST)

Hi Hui,

Sure. To close this thread, its rather much more simpler to
enable IPv6 on the end-hosts first and let the applications use
that stack natively, and not use a psuedo IPv4 transport with
a re-written host stack. Believe me, its not prolonging IPv4 life,
but is enabling faster IPv6 migration still keeping some sensible
and manageable host stacks. Thanks for the discussion. I will wait
for others comments on impact to codecs due to the use of the IPv6
sockets.

Regards
Sri

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 07 Dec 2009 11:25:20 +0800

> From:  Sri Gundavelli

> As I said and to repeat one more time, I'm not convinced 
> about that use-case. This is not a legacy issue, there are no 
> deployed applications currently operating in that mode. We 
> talked to many operators, every one is planning to use IPv6 
> transport for the UE to UE scenario. This argument that both 
> the hosts are IPv6-only capable, but they cant use IPv6 
> transport is not going to go any where.

Hi, Sri,

I believe you have talked to many operators and understand their
requirements. But I am also sure you have NOT talked with EVERY operators
and understand ALL requirements. From this thread, what I read is an
operator is taking about its requirement scenario, then you guys tried to
say there are different solutions meet other different requirements.

For my understanding, you can not shrug off the requirement from legacy
applications as easy as you said. Apple may be able to put considerable
efforts to update and recompile all there legacy applications since they are
in a walled garden and most of their applications are under their direct
development. That's not a general case. Actually, apple is so special, we
should consider it the last. Here, we are talking about thousands different
applications from thousands different ICPs. Could you make sure they all
have the extra budget for IPv6? I cannot. So, there are such reality
requirements.

Host-based translation approach actually helps these legacy applications be
able to extend their services to IPv6 network. It helps to convence people
IPv6 does not hurt you, it only brings you advantages. Eventually, it makes
IPv6 migration smoother.

BTW, this discuss should mainly be in behave wg, so I cc to both behave and
softwire.

Cheers,

Sheng
 
> We are talking about four lines of code change to use an IPv6 
> socket. As some one pointed out, when Apple released the new 
> 3GS, all most 80K applications required a re-compile. I don't 
> get the point that you have an
> IPv4 app, binaries only, but that will run on some future 
> platform with out recompile and talk to a future IPv6 
> application. May be your app development process is broken, 
> this is not a technical or a industry problem.
> 
> I'm not deviating from this point, as I said many times, we 
> don't deal with this case, its not realistic and there is a 
> work around. If you have any advantages in the host-based 
> translation approach that help in IPv6 migration besides this 
> artificial use-case, let me know.
> 
> 
> Regards
> Sri
> 
> 
> 
> >>>> irrelevant in the context of IP routing and just make it 
> a simple 
> >>>> state in two places, the mobile node and the NAT44 gateway. Its 
> >>>> allowing the network to migrate to IPv6 day-1, remove traces of 
> >>>> IPv4 in the core and access network, but continue to 
> offer IPv4 services.
> >>> the small part of the bear network which could be constructed by 
> >>> multiple technologies such as GRE, L2TP,
> >>> IPv6 tunnel. I don't see
> >> I don't see you disagreeing with my technical points and the 
> >> similarities I have shown in both the approaches. But, I 
> see that you 
> >> do not want to agree and so you summarize it to say, its 
> still just a 
> >> solution for IPv4-exhaust and not a step towards 
> migration, with no 
> >> backing by any technical arguments. That is fine. We agree or not, 
> >> its just translation vs., tunneling, a scheme that was 
> adopted in the 
> >> earlier versions of DS-lite and made a conscious decision 
> not to go with host-based translation scheme.
> >> Bottom line, we touched about the core aspects and also 
> one use-case 
> >> that you say is the key motivation for your chosen approach, which 
> >> the use-case itself is debatable and a clear solution 
> exists as many 
> >> folks pointed out, enable dual-stack on the server, or use 
> IPv6. We 
> >> also talked about the key resulting benefits in each of the 
> >> solutions. As far I see it, when
> >> DS-lite/GI-DS-lite is applied to mobile architectures, we have all 
> >> the required tools for migration.
> >>>> You and Bo touched a very important point. Your point is that 
> >>>> DS-lite is just about IPv4 address exhaust and not about 
> migration. 
> >>>> You already heard from Alain and that's the best source. 
> But, I'll 
> >>>> comment in the context of mobile architectures and 
> application of GI-DS-lite.
> >>>> 
> >>>> irrelevant in the context of IP routing and just make it 
> a simple 
> >>>> state in two places, the mobile node and the NAT44 gateway. Its 
> >>>> allowing the network to migrate to IPv6 day-1, remove traces of 
> >>>> IPv4 in the core and access network, but continue to 
> offer IPv4 services.
> >>> the small part of the bear network which could be constructed by 
> >>> multiple technologies such as GRE, L2TP,
> >>> IPv6 tunnel. I don't see
> >>>> allowing multiplicity assignment of the same IPv4 address to all 
> >>>> mobile nodes (since, the address is just a state on the 
> gateway and 
> >>>> is not used for IP routing), that's a side affect and solves the 
> >>>> address exhaust problem to some extent. But, there is still 
> >>>> limitation w.r.t the public address usage on the NAT44 gateway.
> >>>> IPv4 applications to work on an IPv6 host that has only IPv6 
> >>>> transport and on IPv6-only core network. How are you 
> achieving this 
> >>>> ? Your IPv4
> >>>> application is using an IPv4 address (valid or invalid) 
> and there 
> >>>> is a socket and translation state that is getting created on the 
> >>>> host and on the
> >>>> NAT44 gateway, your routing is all based on IPv6. You are making 
> >>>> IPv4 just a state in the host and on the gateway.
> >>>> 
> >>>> What is the difference between #1 and #2 ? PNAT is 
> solving all that 
> >>>> DS-lite solves and also has an indirect property of solving the 
> >>>> IPv4 address exhaust issue. But, its coming at a huge cost and 
> >>>> baggage i.e., Host changes.
> >>>> 3. When I apply DS-lite to mobile architectures which 
> already have 
> >>>> good support for dual-stack and the ability to carry 
> both IPv4 and 
> >>>> IPv6 on mobility tunnels, its allowing an operator to 
> migrate their 
> >>>> network to IPv6-only and is also solving the address 
> exhaust issue.
> >>>> 
> >>>> - No changes to UE
> >>>> - Allow access network and core network to migrate to IPv6 at 
> >>>> different point of time.
> >>>> But, its missing one hypothetical case, which the 
> scenario is not 
> >>>> realistic and even otherwise, one can always enable 
> dual-stack on 
> >>>> the other peer, or use IPv6 transport.
> >>>> 
> >>>> So, my friend, Dear Hui, there is no difference between what you 
> >>>> want to solve and what is on the table. Tell me, what 
> I'm missing.
> >>>>>> But, don't deal with the case of IPv4 legacy application 
> >>>>>> communicating with a IPv6 future application using IPv4. By 
> >>>>>> allowing that one case which has no justification, you have to 
> >>>>>> deal with the resulting baggage of host translation and UE 
> >>>>>> changes. Instead use IPv6 for host to host as you say.
> >>>>> I could ask here again, you are assigning unlimited 
> IPv4 address 
> >>>>> to the host, and encouraging me to install IPv4 
> appliation server, 
> >>>>> I feel what you proposed is more like prolong IPv4 world and 
> >>>>> solveing the problem of IPv4 address exhaustion but not IPv6 
> >>>>> migration.
> >>>>> Based on your proposal, IETF would better to setup a 
> working group 
> >>>>> about

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 6 Dec 2009 22:09:34 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Sunday, December 06, 2009 7:25 PM
> To: 'Sri Gundavelli'; 'Hui Deng'
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6
> 
> in a walled garden and most of their applications are under 
> their direct development. 

My iPhone has approximately 22 applications written by Apple.  The
other ~80,000 applications available for the iPhone are not written
by Apple.

> That's not a general case. Actually, apple is so 
> special, we
> applications from thousands different ICPs.

That is how the iTunes store works; most of the applications
are developed independently.  The source code is not owned or
seen by Apple.

Yet, when Apple changed the iPhone OS between version 2 and version
3, tens of thousands of the applications were upgraded to work
with version 3 of the iPhone OS.  Hundreds weren't, and some of
those still work fine, and some don't work anymore.

> Could you make sure they all
> IPv6 does not hurt you, it only brings you advantages. 

If the original application developer is not investing in 
their application's support for IPv6, some other organization 
has to make that investment instead.  That is, some other
organization has to "pull along" an application into the
modern IPv6 era.

That is the pushback we are seeing here:  the investment to
"pull along" an application can not be carried, successfully
and in perpetuity, by another organization.  The incentives
are in the wrong place, and there are high barriers to 
success.  

This is why the industry, as a whole, has been adding NAT
traversal to applications (e.g., SIP, Skype, RTSP, and 
others) rather than building and specifying ALG, and 
rather than solely relying on UPnP IGD / NAT-PMP.

-d

> Eventually, it makes IPv6 migration smoother.
> 
> BTW, this discuss should mainly be in behave wg, so I cc to 
> both behave and softwire.
> 
> Cheers,
> 
> Sheng
>  
> > >>>> If this is not migration what is it ? Now, if the 
> technology is 
> > >>>> also
> > >>>> If this is not migration what is it ? Now, if the 
> technology is 
> > >>>> also
> > >>>> 2. Lets look at PNAT. Your single biggest motivation 
> is to allow 
> > >>>> your legacy
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Dec 2009 08:19:13 -0800 (PST)

Hi Cameron,

Pls see below.

----- Original Message ----
> From: Cameron Byrne <[email-masked]>
> To: Hui Deng <[email-masked]>
> Cc: [email-masked]
> Sent: Sat, December 5, 2009 3:37:21 PM

I think we have to be careful in reaching conclusions on this case. 

Alain wrote in his mail which I quote here:

In our case, we have:

    * many millions of edge devices (similar to your UE) 
   * thousands of routers 
   * thousands of servers

So your mileage with DS-Lite varies according to how much your network fits into the above proportions. If you exactly have the above, DS-Lite fits you best.

In mobile networks, this translates into operators asking all base stations to be IPv6-enabled and support/use IPv6 in applications like backhauling. 

Otherwise base stations are Layer 2 devices so you don't get a lot of mileage from DS-Lite. In fact it is very easy/straightforward to deploy DS-Lite in mobile networks.

There is nothing wrong with this conclusion, it is just a fact.

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 7 Dec 2009 09:23:21 -0800

> So your mileage with DS-Lite varies according to how much your network fits into the above proportions. If you exactly have the above, DS-Lite fits you best.

Yep, that sound like mobile.

> In mobile networks, this translates into operators asking all base stations to be IPv6-enabled and support/use IPv6 in applications like backhauling.

Nope, that does not sound like 3GPP mobile. 3GPP architecture is
completely based on tunneling.  The only devices that need IPv6
addresses  or IPv6 routing capability are the UEs and the GGSN, and we
have support in those devices today.  Backhaul and cell sites are in
no way impacted by IPv6 deployments to the end user.  GTP / IuPS / IuB
can all be IPv4...they are just the outside of a tunnel that may
contain IPv4 or IPv6 packets on the inside.  In fact, i have IPv6
delivered to cell phones today across my production national network
(beta testing IPv6 PDP and handsets), and the RAN teams are not
impacted at all.

> There is nothing wrong with this conclusion, it is just a fact.

I am not sure what your conclusion is, given that your facts regarding
base stations (do you mean BTS? NodeB?) and backhaul are not correct.
I frankly don't think DS-lite works well for mobile, just like I don't
think PNAT works well, both require modifications and complication to
the UE.  I prefer the GI-DS-lite or NAT64 deployments since they don't
require modifications to the UE beyond the natural evolution to the
final architecture, which is IPv6 UE.

Regards,

Cameron

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Dec 2009 12:12:24 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> Sent: Sunday, December 06, 2009 8:30 AM
> To: Hui Deng
> Cc: [email-masked]

Interworking IPv4 and IPv6 is most often handled, on deployed
networks, using the network's SBC.  Acme Packet, for example,
supports interworking IPv4 endpoints with IPv6 endpoints.

The IETF standard is to use ICE which allows SDP to express
both IPv4 address (in the m= and c= lines) and IPv6 address
(in a= lines) which provides the ideal backwards-compatibility
with IPv4-only endpoints (because SDP requires that unrecognized
a= lines be ignored by the endpoint).  Details are in 
draft-ietf-sipping-v6-transition-07 (which is approved by the
IESG and in the RFC editor's queue) and Section 2.1 of
draft-wing-behave-nat64-referrals-01.

-d

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 8 Dec 2009 09:18:42 -0800 (PST)

> > So your mileage with DS-Lite varies according to how much your network fits 
> into the above proportions. If you exactly have the above, DS-Lite fits you 
> best.
> >
> 
> have support in those devices today.  

This is what I meant, in 3GPP mobile you don't have millions of home routers that need IPv6 addresses.

I think we are agreeing on this.

> base stations (do you mean BTS? NodeB?) and backhaul are not correct.

If we can get them do IPv6, it would even be better, I think.

> I frankly don't think DS-lite works well for mobile,

I don't want to put it this way, as I said it is easy to deploy DS-Lite in mobile, maybe except for AFTR box.

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 Dec 2009 10:05:31 -0800

> I think we are agreeing on this.

Umm..... right, i have millions of edge devices that need
addresses...aka UE... and UE can grow exponentially with machine to
machine communication.  Also, with the evolution of MiFi, we'll see
that the mobile carrier UE may be a WiFi router just like the Cable
MSO operators...   Services are evolving and the differences are
fading between wireline and wireless.

> If we can get them do IPv6, it would even be better, I think.

Agreed.  I believe most LTE / 4G E-UTRAN will be native IPv6, but that
is greenfield.  My only point being that IPv6 can come to 2G/3G mobile
devices without any major technical barriers today.

> I don't want to put it this way, as I said it is easy to deploy DS-Lite in mobile, maybe except for AFTR box.

I won't say DS-lite is easy or not, but i will say native IPv6 or
native dual stack on the UE is easier than DS-Lite.

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 8 Dec 2009 13:41:06 -0500

> I don't want to put it this way, as I said it is easy to deploy
DS-Lite in mobile, maybe except for AFTR box.

[YL] I believe this is the motivation behind GW-Init-DSlite so that the
UE be v4, v6 or dual-stack.

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 08 Dec 2009 13:44:18 -0500

> native dual stack on the UE is easier than DS-Lite.

I think it really depends on the wireless architecture, how many layers of
tunnel are already in place and where those tunnels terminate.
If those L2 tunnels ends where you would naturally place your v4 NATs, there
is not much to be gained with DS-lite, you might as well go with full
dual-stack, the v4 address being a private one.
If you decide to locate your NATs elsewhere, either for scaling reason,
contractual reasons (eg who owns the address space in an NVNO type
deployment) or any other reasons, this is a different story. In that model,
DS-lite provide you a great deal of flexibility and offer you to locate your
NATs/AFTRs anywhere. You can get horizontal scaling, N+1 redundancy, traffic
volume adaptation, etc...

   - Alain.