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
