From mext-bounces@ietf.org Mon Jun 25 08:48:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nzf-0002E1-Pr; Mon, 25 Jun 2007 08:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nze-0002Dw-5f for mext@ietf.org; Mon, 25 Jun 2007 08:48:34 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2nzb-0000ay-GS for mext@ietf.org; Mon, 25 Jun 2007 08:48:34 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AB9551986A6 for ; Mon, 25 Jun 2007 15:48:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5E7A219868B for ; Mon, 25 Jun 2007 15:48:30 +0300 (EEST) Message-ID: <467FB99E.3000105@piuha.net> Date: Mon, 25 Jun 2007 15:48:30 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: mext@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: 9e5c23589e6cce06555030c0194c9e2b Subject: [MEXT] new charter version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Testing the new list... this list should have all the subscribers of the existing three lists. For now, please continue your technical discussions in the existing lists, except for charter discussion which we can move here. In general, you do not need to take any action with regards to list changes, once we are ready to move complete away from the old lists we can deal with the from the secretariat. Here's a pointer to the list page: https://www1.ietf.org/mailman/listinfo/mext Here's the new charter, revised according to comments from many of you (thanks!) and the rest of the IESG. The charter will go out soon for public IETF review. ------ Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: https://www1.ietf.org/mailman/listinfo/mext http://www1.ietf.org/mail-archive/web/mext/current/index.html 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 3963 o RFC 4877 The MEXT Working Group continues the work of the MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, and (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping. 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 needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. 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 uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather 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. The solution involves two specifications, one for the policy format and another for its transport [both 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 Basic Support nodes and nodes served by them. 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 extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. 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 (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. 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: Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Aug 2007 Submit Multiple CoA Registration to IESG Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Oct 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Jan 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Jan 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Feb 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. May 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard May 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Aug 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 26 17:05:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3IEC-0003As-C0; Tue, 26 Jun 2007 17:05:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3HDE-0005Hq-LX; Tue, 26 Jun 2007 16:00:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3HDE-000743-6r; Tue, 26 Jun 2007 16:00:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D608A175CA; Tue, 26 Jun 2007 20:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3HCj-0006C0-Ex; Tue, 26 Jun 2007 16:00:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 26 Jun 2007 16:00:01 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 X-Mailman-Approved-At: Tue, 26 Jun 2007 17:05:35 -0400 Cc: mext@ietf.org Subject: [MEXT] WG Review: Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by July 2. +++ Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: mext@ietf.org https://www1.ietf.org/mailman/listinfo/mext http://www1.ietf.org/mail-archive/web/mext/current/index.html 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 3963 o RFC 4877 The MEXT Working Group continues the work of the MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, and (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping. 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 needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. 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 uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather 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. The solution involves two specifications, one for the policy format and another for its transport [both 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 Basic Support nodes and nodes served by them. 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 extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. 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 (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. 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: Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Aug 2007 Submit Multiple CoA Registration to IESG Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Oct 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Jan 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Jan 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Feb 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. May 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard May 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Aug 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 27 06:08:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3URQ-0002WZ-Gd; Wed, 27 Jun 2007 06:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3URE-00022q-GJ for mext@ietf.org; Wed, 27 Jun 2007 06:07:52 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3UQJ-0005O9-N7 for mext@ietf.org; Wed, 27 Jun 2007 06:07:52 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1182938811!2338471!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 6441 invoked from network); 27 Jun 2007 10:06:52 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-7.tower-153.messagelabs.com with SMTP; 27 Jun 2007 10:06:52 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5RA6pn7027274 for ; Wed, 27 Jun 2007 05:06:51 -0500 (CDT) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5RA6ow8011429 for ; Wed, 27 Jun 2007 05:06:50 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.1.41]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5RA6nGV011410 for ; Wed, 27 Jun 2007 05:06:49 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 27 Jun 2007 11:06:47 +0100 Message-ID: <468236AE.8060805@gmail.com> Date: Wed, 27 Jun 2007 12:06:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jari Arkko Subject: Re: some dates (was: [MEXT] new charter version) References: <467FB99E.3000105@piuha.net> In-Reply-To: <467FB99E.3000105@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-1, 26/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 27 Jun 2007 10:06:47.0881 (UTC) FILETIME=[DF978390:01C7B8A2] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Just to say some dates should be updated to 2008 instead of 2007. Jari Arkko wrote: [...] > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational ^here. > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 27 06:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UkM-0008NK-CI; Wed, 27 Jun 2007 06:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UkH-0008Db-F5 for mext@ietf.org; Wed, 27 Jun 2007 06:27:33 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Ujd-0002nW-I3 for mext@ietf.org; Wed, 27 Jun 2007 06:27:33 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 54A331986A6; Wed, 27 Jun 2007 13:26:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0E526198691; Wed, 27 Jun 2007 13:26:52 +0300 (EEST) Message-ID: <46823B6B.9020600@piuha.net> Date: Wed, 27 Jun 2007 13:26:51 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Alexandru Petrescu References: <467FB99E.3000105@piuha.net> <468236AE.8060805@gmail.com> In-Reply-To: <468236AE.8060805@gmail.com> 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: 52e1467c2184c31006318542db5614d5 Cc: mext@ietf.org Subject: [MEXT] Re: some dates X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ah, of course. Thanks for catching this. Jari Alexandru Petrescu kirjoitti: > Just to say some dates should be updated to 2008 instead of 2007. > > Jari Arkko wrote: > [...] >> Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem >> Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG >> for publication as a Proposed Standard. >> Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the >> IESG, for Proposed Standard >> >> Jan 2007 Submit final doc on Route Optimization Needs for Automobile >> and Highway Deployments, for Informational >> Jan 2007 Submit final doc on Route Optimization needs for Personal >> Mobile Router, for Informational > > ^here. > >> Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for >> publication as a proposed standard. >> Feb 2008 Determine how to proceed with remaining automotive/Personal >> Mobile Router solutions > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 29 17:29:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4O1e-0004n0-Vo; Fri, 29 Jun 2007 17:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4O1d-0004hb-Ee for mext@ietf.org; Fri, 29 Jun 2007 17:29:09 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4O0j-0004Xn-Uq for mext@ietf.org; Fri, 29 Jun 2007 17:29:09 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5TLVjTL026544; Fri, 29 Jun 2007 16:31:45 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 16:28:12 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 16:28:12 -0500 Message-ID: <46857923.3080302@ericsson.com> Date: Fri, 29 Jun 2007 17:26:59 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] new charter version References: <467FB99E.3000105@piuha.net> In-Reply-To: <467FB99E.3000105@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2007 21:28:12.0270 (UTC) FILETIME=[6569B0E0:01C7BA94] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, The items A.2 and A.3 are reversed in the following descriptive text "Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents,..." whereas in the following bulleted list A.2 talks about HA reliability and A.3 talks about multiple interfaces in MNs. Cheers Suresh Jari Arkko wrote: > Testing the new list... this list should have all the subscribers > of the existing three lists. For now, please continue your > technical discussions in the existing lists, except for charter > discussion which we can move here. In general, you do not > need to take any action with regards to list changes, once > we are ready to move complete away from the old lists we > can deal with the from the secretariat. Here's a pointer > to the list page: > > https://www1.ietf.org/mailman/listinfo/mext > > Here's the new charter, revised according to comments > from many of you (thanks!) and the rest of the IESG. > > The charter will go out soon for public IETF review. > > ------ > > Mobility EXTensions for IPv6 (MEXT) > > Chair(s): > TBD > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > https://www1.ietf.org/mailman/listinfo/mext > http://www1.ietf.org/mail-archive/web/mext/current/index.html > > > 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 3963 > o RFC 4877 > > The MEXT Working Group continues the work of the MIP6, NEMO, and > MONAMI6 Working Groups. > > The primary goal of MEXT will be to (A) enhance base IPv6 mobility by > continuing work on developments that are required for wide-scale > deployments and specific deployment scenarios. Additionally, (B) the > working group will ensure that any issues identified by implementation > and interoperability experience are addressed, and that the base > specifications are maintained. (C) The group will also produce > informational documentation, such as design rationale documents or > description of specific issues within the protocol. > > Deployment considerations call for (A.1) solutions to enable > dual-stack operation, (A.2) allowing the use of multiple interfaces in > mobile nodes, (A.3) mechanisms to support high-availability home > agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, > (A.5) address the specific needs of automotive and aviation > communities for route optimisation in network mobility, and (A.6) > support for AAA is needed as a continuation of earlier work on > bootstrapping. > > 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 needs to > be taken offline for maintenance. > > (A.3) Use of multiple interfaces. > > Today, the protocols do not provide suppport for simultaneous > differentiated use of multiple access technologies. 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 uses existing tunneling mechanisms defined for Mobile > IPv6. The involved nodes need to select which tunnel instance > to use when multiple ones are available due to multiple > addresses on either end. But the WG does not plan to define a > new mechanism for this, but rather 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. The solution involves two > specifications, one for the policy format and another for its > transport [both 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 Basic Support nodes > and nodes served by them. > > 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 extensions to routing protocols. The > group will not consider general multi-homing problems that are > not related to the deployment and maintenance of Mobile IPv6 or > NEMO Basic Support protocols. The group will also not consider > general route optimization, or other problems that are not > related to the deployment and maintenance of NEMO Basic Support > protocols. 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 > > (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG > require AAA support for Mobile IPv6. Part of this work is > already being done in the DIME WG, but the MEXT WG is chartered > to complete a design for RADIUS. > > > 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: > > Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft > and Spacecraft Deployments > Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile > and Highway Deployments > Aug 2007 Submit Multiple CoA Registration to IESG > > Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard > Oct 2007 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > > Nov 2007 Submit final doc on Route Optimization Needs for Aircraft > and Spacecraft Deployments, for Informational > Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions > > Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the > IESG, for Proposed Standard > Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > for publication as Informational. > > Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard > Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed > Standard > Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to > IESG for publication as a Proposed Standard. > > May 2008 Submit final doc for solution to aircraft/spacecraft problem > to the IESG, for Proposed Standard > May 2008 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > > Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, > for Informational > Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of > Addresses and Home Agent addresses, for Informational > > Aug 2008 Submit I-D(s) related to specific updates and corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication > as a Proposed Standard. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 29 18:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4P31-0005Y7-TT; Fri, 29 Jun 2007 18:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4P30-0005Xc-IL for mext@ietf.org; Fri, 29 Jun 2007 18:34:38 -0400 Received: from web84106.mail.mud.yahoo.com ([68.142.206.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4P2u-0004To-Kx for mext@ietf.org; Fri, 29 Jun 2007 18:34:38 -0400 Received: (qmail 44804 invoked by uid 60001); 29 Jun 2007 22:34:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ymMdslFbjk2WgYIVQpqTM2wvozSG9Oa1E+vWdFSCsPaimUjJBvTx/IwkjtLZQU3UzZd1vtpnJKEmlDiQum14CuoQTo3ODRTsUklbsrZ463zgGtr+hN3D6neLH4k9pT3S6455mw8120U8Nnm2XxfAN5zQQTZSF7ILa00pfibCgck=; X-YMail-OSG: DZWOWDEVM1m1TSRnjz.7zH0hyQPweR_nrJzLGQBjkXD997R7boesSbJtUBP.UK9S5Y_Tsy_Ce9WOFqYh.D1vi89YLDPv34mXrgsrZenAxLVp61TXUew- Received: from [206.16.17.212] by web84106.mail.mud.yahoo.com via HTTP; Fri, 29 Jun 2007 15:34:32 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Fri, 29 Jun 2007 15:34:32 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [MEXT] new charter version To: Jari Arkko MIME-Version: 1.0 Message-ID: <84929.44768.qm@web84106.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0222891421==" Errors-To: mext-bounces@ietf.org --===============0222891421== Content-Type: multipart/alternative; boundary="0-1884647686-1183156472=:44768" --0-1884647686-1183156472=:44768 Content-Type: text/plain; charset=ascii Hi Jari, In fact HA reliability work is almost over. I think the current draft is expected to go for WGLC soon and the subteam is almost closed. I don't think it would take Aug 08 to complete this work. HA reliability could be completely removed from this charter. Kind regards, Behcet ----- Original Message ---- From: Suresh Krishnan To: Jari Arkko Cc: mext@ietf.org Sent: Friday, June 29, 2007 4:26:59 PM Subject: Re: [MEXT] new charter version Hi Jari, The items A.2 and A.3 are reversed in the following descriptive text "Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents,..." whereas in the following bulleted list A.2 talks about HA reliability and A.3 talks about multiple interfaces in MNs. Cheers Suresh Jari Arkko wrote: > Testing the new list... this list should have all the subscribers > of the existing three lists. For now, please continue your > technical discussions in the existing lists, except for charter > discussion which we can move here. In general, you do not > need to take any action with regards to list changes, once > we are ready to move complete away from the old lists we > can deal with the from the secretariat. Here's a pointer > to the list page: > > https://www1.ietf.org/mailman/listinfo/mext > > Here's the new charter, revised according to comments > from many of you (thanks!) and the rest of the IESG. > > The charter will go out soon for public IETF review. > > ------ > > Mobility EXTensions for IPv6 (MEXT) > > Chair(s): > TBD > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > https://www1.ietf.org/mailman/listinfo/mext > http://www1.ietf.org/mail-archive/web/mext/current/index.html > > > 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 3963 > o RFC 4877 > > The MEXT Working Group continues the work of the MIP6, NEMO, and > MONAMI6 Working Groups. > > The primary goal of MEXT will be to (A) enhance base IPv6 mobility by > continuing work on developments that are required for wide-scale > deployments and specific deployment scenarios. Additionally, (B) the > working group will ensure that any issues identified by implementation > and interoperability experience are addressed, and that the base > specifications are maintained. (C) The group will also produce > informational documentation, such as design rationale documents or > description of specific issues within the protocol. > > Deployment considerations call for (A.1) solutions to enable > dual-stack operation, (A.2) allowing the use of multiple interfaces in > mobile nodes, (A.3) mechanisms to support high-availability home > agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, > (A.5) address the specific needs of automotive and aviation > communities for route optimisation in network mobility, and (A.6) > support for AAA is needed as a continuation of earlier work on > bootstrapping. > > 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 needs to > be taken offline for maintenance. > > (A.3) Use of multiple interfaces. > > Today, the protocols do not provide suppport for simultaneous > differentiated use of multiple access technologies. 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 uses existing tunneling mechanisms defined for Mobile > IPv6. The involved nodes need to select which tunnel instance > to use when multiple ones are available due to multiple > addresses on either end. But the WG does not plan to define a > new mechanism for this, but rather 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. The solution involves two > specifications, one for the policy format and another for its > transport [both 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 Basic Support nodes > and nodes served by them. > > 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 extensions to routing protocols. The > group will not consider general multi-homing problems that are > not related to the deployment and maintenance of Mobile IPv6 or > NEMO Basic Support protocols. The group will also not consider > general route optimization, or other problems that are not > related to the deployment and maintenance of NEMO Basic Support > protocols. 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 > > (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG > require AAA support for Mobile IPv6. Part of this work is > already being done in the DIME WG, but the MEXT WG is chartered > to complete a design for RADIUS. > > > 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: > > Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft > and Spacecraft Deployments > Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile > and Highway Deployments > Aug 2007 Submit Multiple CoA Registration to IESG > > Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard > Oct 2007 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > > Nov 2007 Submit final doc on Route Optimization Needs for Aircraft > and Spacecraft Deployments, for Informational > Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions > > Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the > IESG, for Proposed Standard > Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > for publication as Informational. > > Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard > Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed > Standard > Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to > IESG for publication as a Proposed Standard. > > May 2008 Submit final doc for solution to aircraft/spacecraft problem > to the IESG, for Proposed Standard > May 2008 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > > Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, > for Informational > Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of > Addresses and Home Agent addresses, for Informational > > Aug 2008 Submit I-D(s) related to specific updates and corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication > as a Proposed Standard. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-1884647686-1183156472=:44768 Content-Type: text/html; charset=ascii
Hi Jari,
  In fact HA reliability work is almost over. I think the current draft is expected to go for WGLC soon and the subteam is almost closed. I don't think it would take Aug 08 to complete this work. HA reliability could be completely removed from this charter.

Kind regards,

Behcet



----- Original Message ----
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Jari Arkko <jari.arkko@piuha.net>
Cc: mext@ietf.org
Sent: Friday, June 29, 2007 4:26:59 PM
Subject: Re: [MEXT] new charter version

Hi Jari,
   The items A.2 and A.3 are reversed in the following descriptive text

"Deployment considerations call for (A.1) solutions to enable
dual-stack operation, (A.2) allowing the use of multiple interfaces in
mobile nodes, (A.3) mechanisms to support high-availability home
agents,..."

whereas in the following bulleted list A.2 talks about HA reliability
and A.3 talks about multiple interfaces in MNs.

Cheers
Suresh

Jari Arkko wrote:
> Testing the new list... this list should have all the subscribers
> of the existing three lists. For now, please continue your
> technical discussions in the existing lists, except for charter
> discussion which we can move here. In general, you do not
> need to take any action with regards to list changes, once
> we are ready to move complete away from the old lists we
> can deal with the from the secretariat. Here's a pointer
> to the list page:
>
>    https://www1.ietf.org/mailman/listinfo/mext
>
> Here's the new charter, revised according to comments
> from many of you (thanks!) and the rest of the IESG.
>
> The charter will go out soon for public IETF review.
>
> ------
>
> 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:
> https://www1.ietf.org/mailman/listinfo/mext
> http://www1.ietf.org/mail-archive/web/mext/current/index.html
>
>
> 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 3963
> o RFC 4877
>
> The MEXT Working Group continues the work of the MIP6, NEMO, and
> MONAMI6 Working Groups.
>
> The primary goal of MEXT will be to (A) enhance base IPv6 mobility by
> continuing work on developments that are required for wide-scale
> deployments and specific deployment scenarios.  Additionally, (B) the
> working group will ensure that any issues identified by implementation
> and interoperability experience are addressed, and that the base
> specifications are maintained. (C) The group will also produce
> informational documentation, such as design rationale documents or
> description of specific issues within the protocol.
>
> Deployment considerations call for (A.1) solutions to enable
> dual-stack operation, (A.2) allowing the use of multiple interfaces in
> mobile nodes, (A.3) mechanisms to support high-availability home
> agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls,
> (A.5) address the specific needs of automotive and aviation
> communities for route optimisation in network mobility, and (A.6)
> support for AAA is needed as a continuation of earlier work on
> bootstrapping.
>
> 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 needs to
>       be taken offline for maintenance.
>
> (A.3) Use of multiple interfaces.
>
>       Today, the protocols do not provide suppport for simultaneous
>       differentiated use of multiple access technologies. 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 uses existing tunneling mechanisms defined for Mobile
>       IPv6. The involved nodes need to select which tunnel instance
>       to use when multiple ones are available due to multiple
>       addresses on either end. But the WG does not plan to define a
>       new mechanism for this, but rather 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. The solution involves two
>         specifications, one for the policy format and another for its
>         transport [both 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 Basic Support nodes
>       and nodes served by them.
>    
>       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 extensions to routing protocols. The
>       group will not consider general multi-homing problems that are
>       not related to the deployment and maintenance of Mobile IPv6 or
>       NEMO Basic Support protocols. The group will also not consider
>       general route optimization, or other problems that are not
>       related to the deployment and maintenance of NEMO Basic Support
>       protocols. 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
>
> (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG
>       require AAA support for Mobile IPv6. Part of this work is
>       already being done in the DIME WG, but the MEXT WG is chartered
>       to complete a design for RADIUS.
>
>
> 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:
>
> Aug 2007    Submit -00 draft on Route Optimization Needs for Aircraft
> and Spacecraft Deployments
> Aug 2007    Submit -00 draft on Route Optimization Needs for Automobile
> and Highway Deployments
> Aug 2007    Submit Multiple CoA Registration to IESG
>
> Sep 2007    Submit I-D 'Motivation for Authentication I-D' to IESG for
> publication as Informational.
> Sep 2007    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
> publication as a Proposed Standard.
>
> Oct 2007    Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for
> publication as a Proposed Standard
> Oct 2007    Submit -00 draft on Route Optimization needs for Personal
> Mobile Router
>
> Nov 2007    Submit final doc on Route Optimization Needs for Aircraft
> and Spacecraft Deployments, for Informational
> Nov 2007    Submit I-D 'Goals for AAA HA Interface' to IESG for
> publication as Informational.
>
> Dec 2007    Submit -00 draft for solution to aircraft/spacecraft problem
> Dec 2007    Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG
> for publication as a Proposed Standard.
> Dec 2007    Submit the final doc on Prefix Delegation for NEMO to the
> IESG, for Proposed Standard
>
> Jan 2007    Submit final doc on Route Optimization Needs for Automobile
> and Highway Deployments, for Informational
> Jan 2007    Submit final doc on Route Optimization needs for Personal
> Mobile Router, for Informational
>
> Feb 2008    Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
> publication as a proposed standard.
> Feb 2008    Determine how to proceed with remaining automotive/Personal
> Mobile Router solutions
>
> Mar 2008    Submit the final doc on MIB for NEMO Basic Support to the
> IESG, for Proposed Standard
> Mar 2008    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
> for publication as Informational.
>
> Apr 2008    Submit Flow/binding policy format to IESG, for Proposed Standard
> Apr 2008    Submit Flow/binding policy transport to IESG, for Proposed
> Standard
> Apr 2007    Submit I-D 'Mobility Header Home Agent Switch Message' to
> IESG for publication as a Proposed Standard.
>
> May 2008    Submit final doc for solution to aircraft/spacecraft problem
> to the IESG, for Proposed Standard
> May 2008    Recharter to work on the remaining automotive/Personal
> Mobile Router solutions
>
> Jul 2007    Submit Multiple Interfaces Motivations and Scenario to IESG,
> for Informational
> Jul 2007    Submit Analysis of the use of Multiple Simultaneous Care-of
> Addresses and Home Agent addresses, for Informational
>
> Aug 2008    Submit I-D(s) related to specific updates and corrections of
> RFC 3775 to IESG for publication as Proposed Standard.
> Aug 2008    Submit I-D 'Home agent reliability' to IESG for publication
> as a Proposed Standard.
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www1.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext

--0-1884647686-1183156472=:44768-- --===============0222891421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0222891421==-- From mext-bounces@ietf.org Sat Jun 30 13:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4gSh-0008GV-Ma; Sat, 30 Jun 2007 13:10:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4gSg-0008GN-S7 for mext@ietf.org; Sat, 30 Jun 2007 13:10:18 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4gSZ-0001Wn-Vf for mext@ietf.org; Sat, 30 Jun 2007 13:10:18 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 61E561986A7 for ; Sat, 30 Jun 2007 20:10:11 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1E6D119866D for ; Sat, 30 Jun 2007 20:10:11 +0300 (EEST) Message-ID: <46868E73.3080705@piuha.net> Date: Sat, 30 Jun 2007 20:10:11 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: mext@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: 2870a44b67ee17965ce5ad0177e150f4 Subject: [MEXT] test X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Testing a list problem, please ignore. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext