Hi Sri,
please see inline.
Xiangsong
----- Original Message -----
[......]
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 :)
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.
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
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.
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.
[......]
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
