RE: WG Last Call: 3GPP Analysis Document

[Soliman Hesham <H.Soliman@flarion.com>]

 > 2- No transition mechanism on the UE
 > 
 > (no tunelling, no translation on the UE)
 > This is one of the main recommendation. The philosophy
 > here is to say, those are new devices and new networks,
 > so we can put the burden of transition on the network itself
 > to make the devices simpler/more reliable.
 > 
 > I think this tradeoff is right but should be discussed more clearly
 > in the document.

=> I think tunnelling from the UE is a useful thing
for roaming nodes at least. We already saw that some operators
are agreeing with this. So, I don't think we should
have strong statements that completely discount tunnelling.

 > 3- Dual stack vs IPv6-only UE
 > 
 > This is the other key recommendation. The tradeoffs should 
 > be discussed 
 > more:
 > 
 > - v6only device: easier to build/manage. Require all 
 > services to be v6 
 > ready.
 >    If the supported "legacy" services are limited to 
 > web/mail, they can 
 > be easily proxied,
 >    if not, the situation is more complex.
 > 
 > - dual stack: require management of 2 networks (v4&v6)
 >    The philosophy is that "legacy" applications keep using v4
 >    for the foreseeable future and new applications requiring
 >    end-to-end connectivity (peer2peer & friends) will use v6
 >    This second scenario is somehow what we see hapening
 >    on the "classic" non 3GPP internet.
 >    In that scenario, if someone want to participate in the new
 >    applications requiring end to end, they upgrade as transparently
 >    as they can to v6. This is what we are seeing with 
 > Microsoft three 
 > degree.

=> Agreed.

 > 
 > So, IMHO recommending dual stack UE for now sound reasonable
 > but in these tradeoffs should be  discussed more clearly.

=> The dual stack is the recommended approach. Perhaps
more analysis would make that more justified.

 > 3- Seamless connectivity with IPv4 legacy node.
 > 
 >    For 'traditional' applications, if we recommend the dual 
 > stack approach,
 >    this is not needed.
 > 
 >    The point that is really specific to 3GPP is that 3GPP chose to
 >    mandate that the IMS is IPv6 only.
 > 
 >    Trying to achieve seamless connectivity between v6-only nodes
 >    and legacy v4 nodes for those applications requiring end-to-end
 >    IP connectivity seems to me a non starter. If this was possible
 >    to make this work and scale, there will be no need for 
 >    IPv6, period.

=> Hmm. It's not meant to really scale, more below.


 > 
 >    The analysis document is making the point that:
 >     "It is assumed that the solution described here is used 
 > for limited 
 > cases, in which
 >      communications with a small number of legacy IPv4 SIP 
 > equipment are
 >      needed."
 >     However, this claim is not substanciated.
 >     If it is the case that such communications are only required in 
 > limited environments,
 >     why not recommending that those environments upgrade to v6?

=> I'd love to do that. However, how does this happen in 
practice? Let's say 3GPP went with IPv6 only and 3GPP2
did dual stack or IPv4 only for their IMS. And let's 
say that some operators decide to enable IPv4 only
in their 3GPP2 networks, or in their fixed broadband
networks. Now a 3GPP operator has three options:

1. Tell the others to upgrade to v6
2. Tell its subscribers that they can't contact certain
   networks.
3. Provide a mechanism that allows subscribers to talk
   to those v4 only people. 

1) is unrealistic. If it can be done, then why hasn't
it been done already? 2) doesn't seem realistic either
from a commercial point of view.

Hesham