[Mip6] Merged WG charter

Jari Arkko <jari.arkko@piuha.net> Mon, 18 June 2007 22:02 UTC

Return-path: <mip6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PIu-00028d-Cm; Mon, 18 Jun 2007 18:02:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PIs-00028R-FL; Mon, 18 Jun 2007 18:02:30 -0400
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0PIp-00081z-Iv; Mon, 18 Jun 2007 18:02:30 -0400
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B829D1986A7; Tue, 19 Jun 2007 01:02:26 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4A34F1986A6; Tue, 19 Jun 2007 01:02:26 +0300 (EEST)
Message-ID: <467700F2.4060204@piuha.net>
Date: Tue, 19 Jun 2007 01:02:26 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Mobile IPv6 Mailing List <mip6@ietf.org>, IETF NEMO WG <nemo@ietf.org>, Monami6 WG <monami6@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b
Cc:
Subject: [Mip6] Merged WG charter
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Mobile IPv6 Mailing List <mip6@ietf.org>
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Errors-To: mip6-bounces@ietf.org

Hi all,

Please find below the first draft charter for the merged
WG. Comments appreciated.

Note that the charter has changed only in terms of merging
material from the three working groups into one, shortening
the text here and there, and removing completed items. I've
taken bootstrapping away as a completed item even if we are
still a few weeks away from sending the last document (the
option) to the IESG.

Replies set to mip6 list.

Jari

----

Mobility EXTensions for IPv6 (MEXT)

Chair(s):
TBD

Internet Area Director(s):
Jari Arkko <jari.arkko@piuha.net>
Mark Townsley <townsley@cisco.com>

Internet Area Advisor:
Jari Arkko <jari.arkko@piuha.net>

Mailing Lists:
TBD

Description of Working Group:

Mobile IPv6 specifies routing support which permits an IPv6 host to
continue using its home address as it moves around the Internet,
enabling continuity of sessions. Mobile IPv6 supports transparency
above the IP layer, including maintenance of active transport level
sessions. In addition, NEMO network mobility mechanisms built on top
of Mobile IPv6 allow managing the mobility of an entire network, as it
changes its point of attachment to the Internet. The base
specifications consist of:

o RFC 3775
o RFC 3776
o RFC 3963

The primary goal of the MEXT working group will be to enhance base
IPv6 mobility by continuing work on developments that are required for
wide-scale deployments and specific deployment scenarios
(A). Additionally the working group will ensure that any issues
identified by implementation and interoperability experience are
addressed, and that the base specifications are maintained (B). The
group will also produce informational documentation, such as design
rationale documents or description of specific issues within the
protocol (C).

Deployment considerations call for solutions to enable
dual-stack operation (A.1), allow the use of multiple interfaces in
mobile nodes (A.2), mechanisms to support high-availabity home agents
(A.3), and ways to employ Mobile IPv6 in the presence of firewalls
(A.4). In addition, there are specific needs of the automotive and
aviation communities with regards to route optimization of network
mobility (A.5).

Work items related to large scale deployment include:

(A.1) A Solution for MIP6 session continuity for dual stack hosts which
      attach to IPv4 access networks. Additionally provide a mechanism
      for carrying IPv4 packets via the Home agent for MIP6 capable
      dual-stack hosts.

(A.2) A protocol based solution for enhancing the reliability of home
      agents and a method to force a host to switch home agents.

      A mechanism to force an MN to switch the HA that is currently
      serving it. This is required in deployments where the HA may need to
      be taken offline for maintenance.

(A.3) Use of multiple interfaces.
    
      The protocols do not today provide support for simultaneous
      differentiated use of multiple access technologies, although
      several proposals exist for such support, and some of them have
      been implemented and tested.
    
      When a mobile host/router uses multiple network interfaces
      simultaneously, or when multiple prefixes are available on a
      single network interface, the mobile host/router would end up
      with multiple Care-of Addresses (CoAs). In addition, the Home
      Agent might be attached to multiple network interfaces, or to a
      single network interface with multiple prefixes, hence resulting
      in the option to use multiple IP addresses for the Home
      Agent. This could result in the possibility of using a multitude
      of bi-directional tunnels between pairs of {Home Agent address,
      CoA} and a number of associated issues: establishment, selection
      and modification of multiple simultaneous tunnels.
    
      The objective of the WG is to produce a clear problem statement
      and to produce standard track specifications to the problems
      associated with the simultaneous use of multiple addresses for
      either mobile hosts using Mobile IPv6 or mobile routers using
      NEMO Basic Support and their variants (FMIPv6, HMIPv6,
      etc). Where the effects of having multiple prefixes on a single
      interface is identical to the effects of having multiple
      interfaces each with a single prefix, the WG will consider a
      generalized approach to cater for multiple prefixes available to
      a mobile host/router.
    
      The WG does not plan to define a tunnel selection mechanism, but
      may document how to use existing mechanisms based upon
      preferences or policies. In particular, the WG will consider
      that a tunnel is alive as long as packets can be exchanged with
      the corresponding peer. In addition, local information, such as
      interface up/down events, or other failure detection mechanisms
      can be used to quickly detect failure of tunnel(s).
    
      Deliverables related to this include
    
      - A document explaining the motivations for a node using multiple
        interfaces and the scenarios where it may end up with multiple
        global addresses on its interfaces [Informational]
    
      - An analysis document explaining what are the limitations for
        mobile hosts using multiple simultaneous Care-of Addresses and Home
        Agent addresses using Mobile IPv6, whether issues are specific to
        Mobile IPv6 or not [Informational].
    
      - A protocol extension to support the registration of multiple
        Care-of Addresses at a given Home Agent address [Standard
        Track].
    
      - A "Flow/binding policies exchange" solution for an exchange of
        policies from the mobile host/router to the Home Agent and from the
        Home Agent to the mobile host/router influencing the choice of the
        Care-of Address and Home Agent address [Standard Track].

(A.4) Work on solutions to deal with firewalls and the problems that
      firewalls cause as identified in RFC 4487.

(A.5) Route optimization of network mobility.

      Three use cases have been identified for this. These are called
      the Aviation case, the Automotive case, and the Personal Mobile
      Router (consumer electronics) case, though the actual technical
      problems are characterized by the type of movements and
      environments more than by the specific industry using the
      technology. The group will explore these cases to gather
      requirements and proceed with solving the open issues.
    
      (1) Airline and spacecraft community, who are deploying NEMO for
      control systems, as well as Internet connectivity and
      entertainment systems. This use case is characterized by fast (~
      1000 km/h) moving objects over large distances (across
      continents). The main technical problem is that tunneling-based
      solutions imply a roundtrip to another continent and that BGP
      based solutions imply significant churn in the global Internet
      routing table.
    
      (2) Automotive industry who are deploying NEMO for in-car
      communication, entertainment, and data gathering, possible
      control systems use, and communication to roadside devices. This
      use case is characterized by moderately fast (~ 100-300 km/h)
      moving objects that employ local or cellular networks for
      connectivity.
    
      (3) Personal Mobile Routers, which are consumer devices that
      allow the user to bring a NEMO network with the user while
      mobile, and communicate with peer NEMO networks/MNNs.
    
      After gathering the requirements for these types of deployments,
      the working group will evaluate what type of route optimization
      needs to be performed (if any), and formulate a solution to
      those problems.
    
      If no requirements for those scenarios can be collected by the
      deadline, it will be assumed that the work is premature, and
      that type of deployment will be dropped from the WG.
    
      The group will only consider airline and spacecraft solutions
      that combine tunneling solutions for small movements with either
      federated tunnel servers or slowly changing end host prefixes.
      The group will only consider personal mobile router requirements
      about optimized routes to another mobile router belonging to the
      same operator. The group will only consider automotive industry
      requirements to allow MR-attached hosts to directly access the
      network where MR has attached to. Work on automotive and
      personal mobile router solutions requires rechartering.
    
      The WG will not consider routing issues inside the mobile
      network. Existing routing protocols (including MANET protocols)
      can be used to solve these problems. The group will also not
      consider general route optimization, multihoming, or other
      problems that are not related to the deployment and maintenance
      of NEMO networks. Similarly, the group will not consider or rely
      on the results of general routing architecture, Internet
      architecture, or identifier-locator split issues that are
      discussed in separate, long term efforts elsewhere in the
      IETF. Finally, the group will not consider solutions that
      require changes from correspondent nodes in the general Internet


Work items related to base specification maintenance include:

(B.1) Create and maintain issue lists that are generated on the basis
      of implementation and interoperability experience. Address
      specific issues with specific updates or revisions of the base
      specification. One specific area of concern that should be
      analyzed and addressed relates to multilink subnets.

      This work item relates only to corrections and
      clarifications. The working group shall not revisit design
      decisions or change the protocol.

(B.2) Update the IANA considerations of RFC 3775 to allow extensions for
      experimental purposes as well passing of optional vendor-specific
      information.

(B.3) Finish working group documents that are currently in process, and
      submit for RFC. This includes prefix delegation protocol mechanism
      for network mobility, and a MIB for NEMO Basic Support.


Work items related to informational documentation include:

(C.1) Produce a design rationale that documents the historical
      thinking behind the introduction of an alternative security
      mechanism, the Authentication Protocol (RFC 4285).


Goals and Milestones:


Jul 2007	Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments
Jul 2007	Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments
Jul 2007	Submit -00 draft on Route Optimization needs for Personal Mobile Router
Aug 2007	Submit Multiple CoA Registration to IESG
Aug 2007	Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational.
Aug 2007	Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational.
Sep 2007	Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard.
Sep 2007	Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses in Mobile IPv6
Sep 2007	Submit -00 draft for solution to aircraft/spacecraft problem
Sep 2007	Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard.
Sep 2007	Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard.
Oct 2007	Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational
Oct 2007	Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard
Nov 2007	Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational
Nov 2007	Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational
Nov 2007	Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational
Dec 2007	Determine how to proceed with remaining automotive/Personal Mobile Router solutions
Dec 2007	Recharter to work on the remaining automotive/Personal Mobile Router solutions
Dec 2007	Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard.
Dec 2007	Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard.
Dec 2007	Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard
Dec 2007	Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard
Feb 2008	Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard
Feb 2008	Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational.
Feb 2008	Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. 
Mar 2008	Submit Flow/binding policies exchange to IESG



_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6