Document Action: 'Problem Statement: Dual Stack Mobility' to Informational RFC

The IESG <iesg-secretary@ietf.org> Wed, 13 June 2007 15:13 UTC

Return-path: <ietf-announce-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUXC-0004hl-6M; Wed, 13 Jun 2007 11:13:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUXA-0004g3-EP; Wed, 13 Jun 2007 11:13:20 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUX9-0000WN-SV; Wed, 13 Jun 2007 11:13:20 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7389F26ECB; Wed, 13 Jun 2007 15:13:19 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyUX9-0006Rr-C1; Wed, 13 Jun 2007 11:13:19 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1HyUX9-0006Rr-C1@stiedprstage1.ietf.org>
Date: Wed, 13 Jun 2007 11:13:19 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: mip6 mailing list <mip6@ietf.org>, mip6 chair <mip6-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Problem Statement: Dual Stack Mobility' 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>
Errors-To: ietf-announce-bounces@ietf.org

The IESG has approved the following document:

- 'Problem Statement: Dual Stack Mobility '
   <draft-ietf-mip6-dsmip-problem-03.txt> as an Informational RFC

This document is the product of the Mobility for IPv6 Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-03.txt

Technical Summary
 
  This draft discusses the issues associated with mobility management
  for dual stack mobile nodes. Currently, two mobility management
  protocols are defined for IPv4 and IPv6. Deploying both in a dual
  stack mobile node introduces a number of inefficiencies. Deployment
  and operational issues motivate the use of a single mobility
  management protocol. This draft discusses such motivations. The draft
  also hints on how the current MIP4 and MIP6 protocols could be
  extended so that they can support mobility management for a dual
  stack node.

Working Group Summary

  This I-D was initially produced as a problem statement for the MIP6
  WG. However subsequently it was noted that it applied to MIP4 as
  well. Hence the I-D is now considered as being applicable to the MIP4
  and MIP6 WGs. There is consensus behind this document and the need to
  address the problem.

Protocol Quality
 
  This specification has been reviewed by Jari Arkko for the IESG.

Note to RFC Editor

  Please ignore the "Intended status: Standards Track" header
  in the document. The intended status is really Informational
  RFC.

  Please change the following in Section 4.3:
  OLD: possible to optimize some of these processes.
  NEW: possible to rely on one set of set common credentials.

  Similarly, change the contents of Section 4.2 to
  the following:

    As mentioned above, a node that is IPv4 and IPv6 capable must also be

    MIPv4 and MIPv6 capable to roam within the Internet. The ability
    to employ both IP versions from one mobility protocol makes
    it possible to implement just that one protocol, assuming the
    protocol choice is known. However, in situations where the mobile
    node must be capable of working in any network it may still
    need two protocols.

  And change the contents of Section 4.5 to this:

    The IETF has standardized a number of transition mechanisms to allow
    networks and end nodes to gain IPv6 connectivity while the Internet
    is migrating from IPv4 to IPv6.  However, while some transition 
    mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none 
    of the known mechanisms have been shown to assist with the issues
    described in this document.

  In Section 4.1 title, change "impossibility" to "Impossibility".

  Please remove Section 8 prior to publication as an RFC.

  Please remove Section 1 and the associated reference (the
  document does not use RFC 2119 terms).

  Please change the following in Section 5:

  OLD
   In order to allow for a gradual transition based on
   current standards and deployment, the following work areas seem to be
   reasonable:
  NEW
   The Mobile IPv6 Working Group has reached the view that to allow
   for a gradual  transition based on current standards and 
   deployment, the following work areas would be reasonable:

  OLD
   Following the steps listed above, a vendor can choose to support
   one mobility management protocol while avoiding the 
   incompatibility and inefficiency problems listed in this 
   document. Similarly, operators can decide to continue using 
   one mobility management protocol while addressing the transition
   scenarios that a mobile node is likely to face when roaming 
   within the Internet.

  NEW
   If the IETF chooses to pursue all these paths, a vendor
   could choose to support one mobility management protocol 
   while avoiding the incompatibility and inefficiency problems
   listed in this document. Similarly, operators could decide to
   continue using one mobility management protocol throughout the
   period of IPv4 and IPv6 coexistence. However, a mobile node
   would be forced to choose one approach or the other, or 
   nevertheless to install both and use one or the other 
   according to circumstances.


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