Document Action: 'Analysis on IPv6 Transition in 3GPP Networks' to Informational RFC

The IESG <iesg-secretary@ietf.org> Mon, 29 November 2004 22:35 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21465; Mon, 29 Nov 2004 17:35:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuCB-0001Eo-Jz; Mon, 29 Nov 2004 17:40:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtzg-0002i7-4H; Mon, 29 Nov 2004 17:27:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtrv-0005vE-0s; Mon, 29 Nov 2004 17:19:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19468; Mon, 29 Nov 2004 17:19:36 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtwu-0000eH-17; Mon, 29 Nov 2004 17:24:48 -0500
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CYtWN-00038Y-2h; Mon, 29 Nov 2004 16:57:23 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1CYtWN-00038Y-2h@megatron.ietf.org>
Date: Mon, 29 Nov 2004 16:57:23 -0500
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: v6ops mailing list <v6ops@ops.ietf.org>, Internet Architecture Board <iab@iab.org>, v6ops chair <jonne.Soininen@nokia.com>, v6ops chair <pekkas@netcore.fi>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Analysis on IPv6 Transition in 3GPP Networks' to Informational RFC
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org
X-Spam-Score: 2.0 (++)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976

The IESG has approved the following document:

- 'Analysis on IPv6 Transition in 3GPP Networks '
   <draft-ietf-v6ops-3gpp-analysis-11.txt> as an Informational RFC

This document is the product of the IPv6 Operations Working Group. 

The IESG contact persons are David Kessens and Bert Wijnen.

RFC Editor Note:
                                                                               
The editor of draft-ietf-v6ops-3gpp-analysis-08.txt requests that the text:

Replace the two last paragraphs (after Figure 1) in section 4.1 of
draft-ietf-v6ops-3gpp-analysis-11.txt with the following text:
                                                                               
-----------
                                                                               
On reception of an INVITE, the SIP server reserves an IP address and a
port from the TrGW both for IPv4 and IPv6. Then, the SIP server acts
as a B2BUA (Back-to-Back User Agent) and rewrites the SDP of the
INVITE to insert the transition gateway in the middle of the media
flow between the two end-points.
                                                                               
When performing its B2BUA role, the SIP server acts as a UA (User
Agent) towards both the IMS and the IPv4 host. Consequently, the SIP
server needs to support all the extensions that apply to the session,
which are listed in the Require header fields of the SIP messages.

This approach has a number of important drawbacks, however. The
biggest drawback is that the rewriting of the SDP in the SIP signaling
prevents securing the SDP payload between the two end-points.
Additionally, it breaks the end-to-end negotiation of SIP extensions
required for each session. Therefore, the extensions to be
used in a particular session are limited by the extensions supported
by the SIP server acting as a B2BUA. That is, the introduction of a
new extension requires upgrading not only the UAs, but the B2BUAs as
well.
                                                                               
This analysis clearly shows that a new solution for IPv4-IPv6
interworking in SIP networks is needed. The ability to convey multiple
alternative addresses in SDP session descriptions [SDP ANAT] represents
a step in this direction.
                                                                               
Given the problems related to the use of B2BUAs, it is recommended that
the SIP-related Working Groups quickly work on a solution to overcome
the drawbacks of this approach.

---------

Add to Informational references:
 
[SDP ANAT] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types Semantics (ANAT) for the Session Description Protocol
(SDP) Grouping Framework", October 2004, draft-ietf-mmusic-anat-02.txt,
work in progress.
            
----------

Technical Summary
 
  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.
 
Working Group Summary
 
  This document is the product of the IPv6 Operations Working Group
 
Protocol Quality
 
  This document was reviewed for the IESG by David Kessens.


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce