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 protected]>
To: "Nick Heatley" <[email protected]>; "Hui Deng" <[email protected]>; "Sri Gundavelli" <[email protected]>;
<[email protected]>
Cc: <[email protected]>
Sent: Thursday, December 03, 2009 10:03 AM
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 protected]>
To: "Hui Deng" <[email protected]>; "Sri Gundavelli" <[email protected]>;
<[email protected]>
Cc: <[email protected]>
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 protected] [mailto:[email protected]] On Behalf
Of Hui Deng
Sent: 02 December 2009 15:36
To: Sri Gundavelli
Cc: [email protected]
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 protected]>:
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 protected]> 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 protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
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 protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
