Re: WG Last Call: 3GPP Analysis Document

[Alain Durand <Alain.Durand@Sun.COM>]

Here are some high level comments on the document.

1- backbone tunneling issue.

The document talks at lenght about tunneling in the backbone.
This is in fact just about creating an overlay topology,
with wither static or dynamic tunnels.
A number of technics, like Cisco 6PE (v6 over MPLS)
exits. But there is nothing specific to 3GPP there,
this apply to any backbone network.


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.


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.

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

Again, there seems to be little here that is 3GPP specific.


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.

  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?
   If it is not the case, and actually the number of devices/communications
   requiring translation is very large, I'm affraid that recommending 
to develop
   the suggested SIP ALG/NAT will create a lot of complexity, and I do not
   really see how introducing IPv6 did anything good at all.

   So, IMHO, the scenario IMS v6 only to v4 SIP should not be solved.

    - Alain.