Subject: [Softwires] Transition roadmap // Re: Host based translation: v4-v6

From: Xiangsong Cui <[email-masked]>
Date: Fri, 04 Dec 2009 11:05:16 +0800

Dear Nick,

Thank you very much for your detailed clarification!!

> Your comment raises more requirements/assumptions that need to be
> established.

OMG, I just wanted to simplify the discussion, that is not my intention :)
Since our discussion goes to another direction now, I would rename the subject.

I do agree that the pace is very important, and in my understanding, you mean
transition mainly starts from UEs, then bearer network, then App Server, is that correct?

follow this rule, I have some additional questions,
1) for UEs, do you mean Dual Stack is very necessary? or recommended?
2) for bearer network, is it possible that IPv4 only network changes to IPv6 only network
    directly? if DS bearer network is taken as a middle phase, may DS functionality only be
    provided by some key gateways?
3) for the App Servers, is the exhaustion of IP address a severe issue?

In this roadmap, the key point is the UE, UEs need to support more function.
But, in fact, if the UEs do that, the price will be increased, it seems that the users and
UE vendors don't like that, so the transition goes slowly?

In my mind, I am thinking another roadmap,
transition starts from the bearer network, and then UEs, and then App Servers.
As you said, the main driver for IPv6 transition is the exhaustion of IP address,
operator is the most related player on this issue.
And since the bearer network has to go to IPv6 in any approaches, why not do it firstly?

In this approach, UEs maybe get benefits after the bearer network has already been IPv6,
For example, if the users can reduce the traffic amount, comparing to first approach, tunnel is
reduced, so the traffic amount may also be reduced, this can save users' money, so users
would like to pay a bit more money for these updated UEs, and the UE vendors would
like to accept this roadmap, too. So IPv6 transition would goes easier. Maybe operators
may also get additional benefit from this fast IPv6 transition.
I am not sure is that correct, because it depends on accounting and other aspects.

What do you think about that?

Thanks and regards
Xiangsong

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

Dear Xiangsong,
Your comment raises more requirements/assumptions that need to be
established.

There seems to be two sets of drivers:
1) exhaustion of IP addressing for UEs only
2) exhaustion of IP addressing for UEs and Servers

1) could be exhaustion of private addressing or public addressing.

2) leads to an additional focus on supporting the IPv6-only App server,
where as 1) does not.

I would suggest that currently operators may be in different positions
in relation to these drivers. This really drives whether they wish to go
straight to IPv6-only bearer networks (potentially higher demand for
IPv6 content) or go through a phase of dual stack bearer network
support.
(Does Gateway-Initiated Dual Stack-lite stop the move to IPv6? IMHO the
answer is NO, but it is not an aggressive move to IPv6-only. P-NAT is an
aggressive move to IPv6-only bearer network.)

A second assumption for an operator - will the operator provide access
to IPv6-only Apps via an IPv4-only bearer network? My opinion: I expect
many operators will not. This is my assumption. (IMHO this decision
ensures there remains a valid reason for every operator to move to
support IPv6, with the Content Providers setting the pace. But if
IPv6-only content is niche in your market, then it may not happen at the
same pace as UE address exhaustion.)

My opinions: As a mobile operator I suggest that both "user" and
"carrier" drivers (as you state) are somewhat in my control.
I have a lot of control over the UEs and what they support.
My primary goal: I must guarantee the user experience. And yes I agree,
the end customer mainly does not care for IPv6 or IPv4, just good
service, right?

So points of interest in the App Server debate are these use cases:
A) IPv4 only-app -> Dual Stack UE -> IPv6-only bearer -> IPv6 only
server
B) IPv4 only-app -> Dual Stack UE -> IPv6 only bearer -> IPv4 only
server

If the bearer network is dual-stacked then B) is trivial.
If you believe your eco-system follows drivers in 1) then you can dual
stack your server and network and A) becomes simple. Or in other words
IPv6-only App servers are niche.

But if you follow drivers 2) then you expect IPv6-only servers to be
common place for your mass-market.

To summarise, operators need to think about whether they go for an
aggressive move to an IPv6-only bearer network approach or not. To make
that decision I would say one of the factors is about content provider
networks and the relative pace at which IPv6-only content is appearing
compared to UE IP address exhaustion. (UEs functionality plays a massive
part as well!).

I welcome further discussion :-)
Regards,
Nick
T-Mobile

-----Original Message-----
From: Xiangsong Cui [mailto:[email-masked]]
Sent: 03 December 2009 02:03
To: Nick Heatley; Hui Deng; Sri Gundavelli;
[email-masked]
Cc: [email-masked]
Subject: Re: [Softwires] Host based translation: v4-v6

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.
I hope you don't mind me commenting in your discussion.
[Xiangsong] +1

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?

[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

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

2009/12/2 Sri Gundavelli <[email-masked]>:
> 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...
> Not you'd be back to a v4 app talking to a v4 app on hosts only having
v6
> addresses configured natively.
>
> - Alain.
>
>
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>
_______________________________________________
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.
_______________________________________________
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: Cameron Byrne <[email-masked]>
Date: Thu, 3 Dec 2009 20:58:47 -0800

> UE vendors don't like that, so the transition goes slowly?

Many UEs from many vendors support IPv6 today (Nokia, Windows Mobile,
...).  If you include netbooks as UEs, those support IPv6 too a la
windows 7 or Linux.   UE is not the road block, the road block is the
network operator driving the change.  But, i assure you, that is
changing.
That said, solution that don't add yet another variable into the UE
environment (18 month development cycle) are considered good.

> ----- Original Message ----- From: "Nick Heatley"
> <[email-masked]>
> To: "Xiangsong Cui" <[email-masked]>; "Hui Deng"
> <[email-masked]>; "Sri Gundavelli" <[email-masked]>;
> ----- Original Message ----- From: "Nick Heatley"
> <[email-masked]>
> intended recipient, notify the sender immediately, delete this email from

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 04 Dec 2009 13:16:42 +0800

Dear Cameron,

I agree IPv6 only client is no problem, but how about dual stack?
I am wondering at the dual stack issue, in my question 1).
Most application servers are still IPv4 only now,
so how many UEs turn on their IPv6 or Dual Stack?

Regards
Xiangsong

----- Original Message ----- 
From: "Cameron Byrne" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Nick Heatley" <[email-masked]>; "Hui Deng" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, December 04, 2009 12:58 PM
Subject: Re: [Softwires] Transition roadmap // Re: Host based translation: v4-v6

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 3 Dec 2009 21:25:47 -0800

> so how many UEs turn on their IPv6 or Dual Stack?

As many as the operators wants to turn-on and support.  Dual stack is
just adding functionality and does not take  away functionality.
IPv6-only is the end-game we have to work towards (some more long term
than others) and the BEHAVE WG members are working on bridging that
gap.

>
> Regards
> Xiangsong
>
> ----- Original Message ----- From: "Cameron Byrne" <[email-masked]>
> Cc: "Nick Heatley" <[email-masked]>; "Hui Deng"
>> transition mainly starts from UEs, then bearer network, then App Server,
>> is
>> that correct?
>>
>> 2) for bearer network, is it possible that IPv4 only network changes to
>> IPv6
>> only network
>> But, in fact, if the UEs do that, the price will be increased, it seems
>> that
>> the users and
>> And since the bearer network has to go to IPv6 in any approaches, why not
>> do
>> it firstly?
>>
>> For example, if the users can reduce the traffic amount, comparing to
>> first
>> approach, tunnel is
>> would like to pay a bit more money for these updated UEs, and the UE
>> vendors
>> would

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 04 Dec 2009 13:58:34 +0800

Thanks for your explain, please see inline.

Regards
Xiangsong

----- Original Message ----- 
From: "Cameron Byrne" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Nick Heatley" <[email-masked]>; "Hui Deng" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, December 04, 2009 1:25 PM
Subject: Re: [Softwires] Transition roadmap // Re: Host based translation: v4-v6

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gap.                                                                    ^^^^^^^^^^^^^^^^^^^

[Xiangsong]  I am sorry I came to behave/softwire wgs recently and know
little about the background, I am thinking about this work, it seems we are
taking such a precondition, the bearer network or the app servers are IPv4,
so translation for IPv6 only clients is introduced, is that correct?
This seems the UE-starting transition.

But on the other hand, if we firstly migrate bearer network to IPv6 or
dual stack, then migrate app servers to IPv6, since the IPv4 UEs are the
long tail, we migrate UEs at last, in this situation, the translation for IPv6
only clients is unnecessary? because when IPv6 only UEs appear, they
would find IPv6 has been ready. What we should pay attention is translation
for IP v4 only clients, which seems just out of scope of behave wg?
This seems the UE-following transition.

What I am doing is just comparing these two approaches.

Thanks and Regards
Xiangsong

---

From: Hui Deng <[email-masked]>
Date: Fri, 4 Dec 2009 23:16:47 +0800

Correct

2009/12/4 Nick Heatley <[email-masked]>:
> I admit that that the bulk of roaming issues seem to go away if you
> never have local breakout, and all traffic passes to home network in the
> GTP tunnel, but somebody better tell that to the guys designing the next
> generation of voice.
>
> From: Nick Heatley
> Sent: 04 December 2009 10:12
> To: 'Xiangsong Cui'; Hui Deng; Sri Gundavelli;
> Subject: RE: Transition roadmap // Re: [Softwires] Host based
> translation: v4-v6
>
>
> Hi Xiangsong,
> Subject line is good, perhaps even "Mobile Transition" :-)
> (My last mail didn't redistribute so perhaps I broke the rules?)
>
> My assumptions or opinions, if I am short-sighted please let me know:
> - the operator controls the bearer network and UE to some extent, so for
> the operator the transition starts here IMHO, regardless of what happens
> regarding the Content.
> - dual stack UE is compulsory if you wish to support roaming, as visited
> networks may require a fall back to IPv4. Otherwise roaming partners
> need to allow IPv6 PDP in coordination (I don't see this "flag day" in
> any standards?).
> - bearer network can have the capacity for dual stack, but what you
> offer each UE is selected by the network, then network can choose to
> offer a dual stack UE an IPv6-only bearer. If you want to support
> roaming visitors to your network then continued support of IPv4-only UEs
> is mandatory. So a true IPv6-only bearer network seems false to me.
> - from my view in Western Europe, shortage of public addressing for App
> Servers is not an issue at all. We are concerned with exhaustion of UE
> addressing. Is that true in other markets? (Therefore dual stack of App
> Servers where app allow, seems to be a prerequisite).
> - As above UEs need to be dual stack for roaming. I would not turn off
> that functionality. But any other change to the UE better be worth it -
> I agree UE functionality should otherwise be stripped down for cost.
> - I don't understand your transition, do you mean the network literally
> can only support IPv6-only?
> - My overall customer-centric opinion: I want to move to IPv6 in the
> long-term. But I don't want the exhaustion of IPv4 addressing,
> especially the artificial and arbitrary deadline provided by the 17
> million private addressing to set my IPv6 introduction date. I want to
> do it when the customer experience offered by IPv4 is matched by IPv6.
>
> So in summary I don't support an aggressive move to IPv6 without the
> customer experience, non-standard changes to the UE client that I have
> to pay for, and I must support roamers and roaming in a universal way.
> Regards,
> Nick
>
>
>
>
> Sent: 04 December 2009 03:05
> Subject: Transition roadmap // Re: [Softwires] Host based translation:
> v4-v6
>
> Dear Nick,
>
> is that correct?
> IPv6 only network
> that the users and
> first approach, tunnel is
> vendors would
> 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: "Nick Heatley" <[email-masked]>
Date: Fri, 4 Dec 2009 14:34:16 -0000

-----Original Message-----
From: Nick Heatley 
Sent: 04 December 2009 10:12
To: 'Xiangsong Cui'; Hui Deng; Sri Gundavelli;

Hi Xiangsong,

-----Original Message-----
From: Xiangsong Cui [mailto:[email-masked]] 
Sent: 04 December 2009 03:05
To: Nick Heatley; Hui Deng; Sri Gundavelli;

Dear Nick,

> Your comment raises more requirements/assumptions that need to be

OMG, I just wanted to simplify the discussion, that is not my intention
:)
Since our discussion goes to another direction now, I would rename the
subject.

I do agree that the pace is very important, and in my understanding, you
mean
transition mainly starts from UEs, then bearer network, then App Server,
is that correct?

    directly? if DS bearer network is taken as a middle phase, may DS
functionality only be

In this roadmap, the key point is the UE, UEs need to support more
function.
But, in fact, if the UEs do that, the price will be increased, it seems
that the users and
UE vendors don't like that, so the transition goes slowly?

In my mind, I am thinking another roadmap,
transition starts from the bearer network, and then UEs, and then App
Servers.
As you said, the main driver for IPv6 transition is the exhaustion of IP
address,
operator is the most related player on this issue.
And since the bearer network has to go to IPv6 in any approaches, why
not do it firstly?

In this approach, UEs maybe get benefits after the bearer network has
already been IPv6,
For example, if the users can reduce the traffic amount, comparing to
first approach, tunnel is
reduced, so the traffic amount may also be reduced, this can save users'
money, so users
would like to pay a bit more money for these updated UEs, and the UE
vendors would
like to accept this roadmap, too. So IPv6 transition would goes easier.
Maybe operators
may also get additional benefit from this fast IPv6 transition.
I am not sure is that correct, because it depends on accounting and
other aspects.

Thanks and regards
Xiangsong

----- Original Message ----- 
From: "Nick Heatley" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; "Hui Deng"

Dear Xiangsong,

T-Mobile (UK) Limited
 
NOTICE AND DISCLAIMER

---

From: "Nick Heatley" <[email-masked]>
Date: Fri, 4 Dec 2009 10:12:02 -0000

Hi Xiangsong,

-----Original Message-----
From: Xiangsong Cui [mailto:[email-masked]] 
Sent: 04 December 2009 03:05
To: Nick Heatley; Hui Deng; Sri Gundavelli;

Dear Nick,

Thanks and regards
Xiangsong

----- Original Message ----- 
From: "Nick Heatley" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; "Hui Deng"

Dear Xiangsong,

T-Mobile (UK) Limited
 
NOTICE AND DISCLAIMER

---

From: "Durand, Alain" <[email-masked]>
Date: Fri, 04 Dec 2009 11:10:27 -0500

In our case, we have:
> * many millions of edge devices (similar to your UE)
> * thousands of routers
> * thousands of servers

With those numbers in mind, it is easy to see that the pain is in finding
IPv4 addresses for edge devices, not for routers or servers.
In our case, taking IPv4 away on routers and servers would only saves a very
small number of addresses compared to what is needed for the edge devices...
Removing IPv4 from the routers may have the side benefits of simplifying
network management, however one has to be very confident in the quality of
the v6 equipments/management software before doing so... And if the majority
of the traffic is still IPv4, one may question the validity of the approach.

The path of least resistance seems to be, at least form my perspective, to
get dual-stack to the network (already done by many  operators), then get
the servers ready for dual-stack operation so they can server any type of
UE.
On the UE front, you need dual-stack CAPABLE devices, that can be working
either in a pure legacy IPv4 access network, in a complete dual-stack access
network or in a v6-only access network, ie a dual-stack network where edge
devices can only get a v6 address.
In such scenario, with a dual-stack capable edge device configured only with
an IPv6 address,  as you have a v4 stack in your edge devices, the simplest
thing to do is to use DS-lite to connect to the rest of the IPv4 Internet,
and use IPv6 to connect to the IPv6 Internet. Communications stay in the
same address familly and things are much simpler that way.

Now, someone asked earlier why go through the pain of making the servers
dual-stack if DS-lite actually solve the IPv4 address exhaustion issue?
I previously answered in this list. This is because the more native
end-to-end IPv6 traffic there is, the less burden on the DS-lite NAT
infrastructure and other things app developers have to put in place to deal
with the presence of NAT.

   - Alain.

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 07 Dec 2009 15:04:14 +0800

Dear Nick, Hui, Alain and Cameron,

Thanks for your kind clarification!
Your comments help me understand IPv6 transition better.

> can only support IPv6-only?

I was just reading and thinking, without mature solution.
If there was something in my mind, maybe an *overlap*, an IPv6 only
network/internet was added on the basis of IPv4 only network, with some
dual stack gateways in the front of the both networks, for UE access and
app servers access.

If I would have other new idea I would talk about that again, with all of you.

Thanks and regards

Xiangsong

----- Original Message ----- 
From: "Nick Heatley" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; "Hui Deng" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 04, 2009 6:12 PM
Subject: RE: Transition roadmap // Re: [Softwires] Host based translation: v4-v6

Hi Xiangsong,

-----Original Message-----
From: Xiangsong Cui [mailto:[email-masked]]
Sent: 04 December 2009 03:05
To: Nick Heatley; Hui Deng; Sri Gundavelli;

Dear Nick,

Thanks and regards
Xiangsong

----- Original Message ----- 
From: "Nick Heatley" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; "Hui Deng"

Dear Xiangsong,

T-Mobile (UK) Limited

NOTICE AND DISCLAIMER

---

From: Rémi Després <[email-masked]>
Date: Mon, 07 Dec 2009 11:51:07 +0100

> do it when the customer experience offered by IPv4 is matched by IPv6.

I largely agree with points made.

However, rather than the question "when should one move from IPv4 to 
IPv6", the one that seems important for the short term is "when should 
one move from IPv4-only to IPv4 PLUS IPv6".

To this question, the answer is IMHO clearly "NOW", for all parties:
- OS vendors (it's largely done in PCs).
- Service providers (some have done it, or plan to do it, in particular 
with 6rd to offer native IPv6 across unchanged IPv4 infrastructures)
- CPE manufacturers (the less advanced AFAIK).

Customer experience with IPv4 PLUS IPv6 is already satisfactory, as 
shown by the regularly increasing IPv6 traffic of Free customers 
(www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free).

These customers, without having to be concerned, and without loss of 
quality, have their accesses to Google services made in IPv6 (i.e. with 
end-to-end network transparency and therefore no consumption of ports in 
any NAT).

Thoughts?

RD

---

From: Hui Deng <[email-masked]>
Date: Mon, 7 Dec 2009 19:17:25 +0800

Hi, Remi,

just one discussion for your last word.

If you have no problem to visit google IPv4 website, why you want to
do it through IPv6?

thanks

-Hui

2009/12/7 Rémi Després <[email-masked]>:
>> From: Nick Heatley Sent: 04 December 2009 10:12
>
> However, rather than the question "when should one move from IPv4 to IPv6",
> the one that seems important for the short term is "when should one move
> from IPv4-only to IPv4 PLUS IPv6".
>
> - Service providers (some have done it, or plan to do it, in particular with
> 6rd to offer native IPv6 across unchanged IPv4 infrastructures)
> Customer experience with IPv4 PLUS IPv6 is already satisfactory, as shown by
> the regularly increasing IPv6 traffic of Free customers
> end-to-end network transparency and therefore no consumption of ports in any
> NAT).
>
> Thoughts?
>
> RD
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 07 Dec 2009 18:12:50 +0100

Hui,

Thanks for your comments.
I have put back addresses of copies, forgotten in my previous answer.

Hui Deng wrote :
>> Hui Deng wrote :

>> Today, it's more that I am glad to use IPv6, thus being ready for any port
>> shortage that may come, that I do need it or do want it.

> True,

>> Using IPv6, I feel I contribute positively, together with Free and Google,
>> to the necessary transition toward IPv6.
>> (This transition is understood to be necessary to avoid hard to detect
>> troubles that will come with port shortages in NATs as IPv4 addresses become
>> scarcer and scarcer.)

> But today port hungry is still not a issue.

Right, not that I know.
(But it's hard to know anyway)

>> Note also that, although I am not myself a user of BitTorrent, I do
>> understand that this kind of peer-to-peer works a lot better between
>> IPv6-enabled hosts than between hosts that are behind NAT44s (even if not
>> cascaded yet!).
>> Not all BitTorrent uses may not be legitimate, but at least for those that
>> are, a better service is a real progress.

> this is correct, what I am thinking, IPv6 will be more focus on
> specific application,
> other than the whole Internet,

Both specific and existing applications are worth considering IMO to 
break this vicious circle:
- ISPs wait for user demand
- users wait for applications
- application vendors wait for IPv6 to be available to users (and
concentrate on IPv4 NAT traversal)

RD

>>>> IPv6",
>>>> with
>>>> any