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 protected]>
To: "Xiangsong Cui" <[email protected]>; "Nick Heatley" <[email protected]>; "Hui Deng" <[email protected]>;
<[email protected]>
Cc: <[email protected]>
Sent: Thursday, December 03, 2009 12:22 PM
Subject: Re: [Softwires] Host based translation: v4-v6
Hi Xiangsong,
Please see inline for one clarification.
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.
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
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
