Subject: WG Last Call: 3GPP Analysis Document

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Sep 2003 20:19:13 +0300 (EEST)

Hello everybody,

This is a WG Last Call for comments on sending the 3GPP Analysis 
document to the IESG for considetation as BCP RFC:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt

Please review the document carefully, and send your feedback to the list.  

In particular, there has been a lot of discussion (without necessarily
leading into a clear consensus) at least on the following:

 - whether to recommend the UE's to implement tunneling-based transition 
mechanism(s),

 - whether the strong recommendation to deploy at least a minimal amount
of IPv6 support to enable IPv6 support in the visited ("roaming") networks
is sufficient,

 - what to say about the general use of NAT-PT or other generic 
translation mechanisms (note, there is a dependency on the 
soon-to-be-published NAT-PT applicability statement work here),

 - whether to discourage the IPv6-only UE deployment until the transition
has progressed further (related to the need of generic translators, 
above),

 - whether the 3GPP networks are special (compared to the ISP) and whether
we should recommend (or list) BGP/IGP -based tunneling mechanisms (on 
top of IPv4 infrastructure) in the 3GPP operator's network

 - what kind of transition mechanism is needed for the IMS scenario, and 
whether tasking an another WG (e.g. a SIP WG) to specify it is a good 
idea.

It would be especially useful to keep these issues in mind when reviewing 
the document and providing feedback.

Please also indicate whether or not you believe that this document is
ready to go to the IESG.  Silence does NOT indicate consent.  Unless
sufficient support is demonstrated on the list, the documents will not be
send to the IESG.

The last call will end in about 2 weeks, on 14th October.

Pekka, Jonne & Bob

---------- Forwarded message ----------
Date: Mon, 29 Sep 2003 10:57:09 -0400
From: [email-masked]
To: IETF-Announce:  ;
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Analysis on IPv6 Transition in 3GPP Networks
	Author(s)	: J. Wiljakka
	Filename	: draft-ietf-v6ops-3gpp-analysis-06.txt
	Pages		: 21
	Date		: 2003-9-29
	
This document analyzes the transition to IPv6 in Third Generation 
Partnership Project (3GPP) General Packet Radio Service (GPRS)
packet networks. The focus is on analyzing different transition
scenarios, applicable transition mechanisms and finding solutions
for those transition scenarios. In these scenarios, the User
Equipment (UE) connects to other nodes, e.g. in the Internet, and
IPv6/IPv4 transition mechanisms are needed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt

---

From: Alain Durand <[email-masked]>
Date: Tue, 30 Sep 2003 12:35:04 -0700

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.