[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internal WG Review:: Internal WG Review: Mobility for IPv6 (mip6)
Based on the history of MIPv6 (c.f. 2 years to finish up after the basic
problem with route optimization security was discovered) and the number of
work items this proposed WG is attempting to cover, the proposed schedule
looks hopelessly optimistic to me. I think 3 years is probably a much better
estimate.
Other than that, I have just one comment (embedded).
----- Original Message -----
From: "Internet Drafts Administrator" <internet-drafts@ietf.org>
To: "iesg" <iesg@ietf.org>; <iab@iab.org>; <gab@sun.com>;
<basavaraj.patil@nokia.com>
Sent: Friday, August 15, 2003 12:39 PM
Subject: Internal WG Review:: Internal WG Review: Mobility for IPv6 (mip6)
> A new IETF working group is being considered in the Interent Area. The
> draft charter for this working group is provided below for your review
> and comment.
>
> Review time is one week.
>
> The IETF Secretariat
>
> --------------------------------
> Charter:
> --------
>
> Internet Area (int)
> Thomas Narten (narten@us.ibm.com)
> Margaret Wasserman (mrw@windriver.com)
>
> Chairs:
>
> Mailing list: mip6@ietf.org
> To subscribe: https://www.ietf.org/mailman/listinfo/mip6
> To post: mip6@ietf.org
> Archive:
> http://www1.ietf.org/mail-archive/working-groups/mip6/current/
>
> Mobile IPv6 (MIPv6) specifies routing support to permit IPv6 hosts to
> continue using its "permanent" home address as it moves around
> the Internet. Mobile IPv6 supports transparency above the IP
> layer, including maintenance of active TCP connections and UDP port
> bindings. The specifications for these mechanisms consist of:
>
> draft-ietf-mobileip-ipv6-24 and
> draft-ietf-mobleip-mipv6-ha-ipsec-06
>
> The protocol as specified in the above two documents can be considered
> as the baseline or minimum protocol set for implementing IPv6
> mobility. During the development phase of the base protocol, a few
> additional features were identified as necessary to facilitate
> deployment (described below).
>
> The primary goal of the MIP6 working group is to improve the base
> specification as a result of experience gained from implementation and
> interop testing and to work on items that are deemed critical to
> getting MIPv6 deployable on a large scale. Specifically,
> this ncludes:
>
> 1) Refining the base specifications based on experience of initial
> implementations and interoperability testing.
>
> 2) Features such as renumbering of the home link, home agent discovery,
> Route Optimization, which are currently a part of the base
> specification can be specified more explicitly as separate
> specifications. This will also enable modularizing the Mobile
> IPv6 specification further into the minimal subset and add-on
> features. Some of these specifications will be identified as
> base mechanisims of Mobile IPv6.
>
>
> 3) A number of enhancements to basic IPv6 mobility were identified
> during the development of the base specification. These
> enhancements would be taken up in a phased manner depending on the
> priority identified with each. Below are listed the work items to
> be taken up by the WG:
>
> - A bootstrap mechanism for setting up security associations
> between the MN and HA that would enable easier deployment of
> Mobile IPv6. This bootstrap mechanisim is intended to be used
> when the device is turned on the very first time and activates
> MIP. The WG should investigate and define the scope before
> solving the problem.
>
> - Improving home agent reliability: in the even of a home agent
> crashing, this would allow another home agent to continue
> providing service to a given mobile node.
>
> - Support for the MN's changing addresses either because of
> renumbering in its home network or because it periodically
> changes addresses (perhaps via rfc3041)
>
> - Route optimization will require security mechanisims for
> trusting and updating the binding information. Return-routability
> is the basic mechanism for route-optimization. Mechanisims using
> a shared secret Key/Security Association will be considered.
> Methods for establishing a security association between the mobile
> node and the correspondent node are out of the scope of the WG.
>
I'm unclear about what is being proposed in this work item. Clearly, the
task of setting up a full IPsec security association (which is what I
presume is meant by "security association") is out of scope, because that is
already done by IKE. Was the intent to eliminate any asymmetric key-based
mechanism at all, even something like TLS? In that case, the restriction
would seem to limit discussion to some AAA-based mechanism, and this work
item should explicitly say that.
If that is not the intent, then the work item should explicitly state that
various proposed alternatives to RR will be considered, and one selected, or
possibly that requirements will be generated and an alternative selected
based on requirements.
> - The working group will also document problem statements
> associated with deploying Mobile IPv6 in the following areas:
> a. Mobile IPv6 issues in the presence of firewalls
> b. Mobile IPv6 deployment and transition issues in the presence
> of IPv4/IPv6 networks
> c. Multicast issues
>
> It should be noted that there are potential optimizations that might
> make mobile IP more attractive for use by certain applications (e.g.,
> making handovers "faster"). The latter category of optimizations is
> explicitly out-of-scope at this time; this WG will focus on issues
> for which there is strong consensus that the work is needed to get
> basic mobility deployable on a large scale.
>
>
> ------------------------------------------
>
>
> Aug 03 Charter approval
>
> Nov 03 Problem statement documents (to IESG)
> - Issues with firewall
> - Mobile IPv6 transition between v4/v6 networks
>
> Nov 03 Bootstrapping problem statement to IESG
>
> Feb 04 Submit MIPv6 MIB to IESG
>
> Feb 04 Submit alternate security mechanisms for CN-MN to IESG
>
> Mar 04 Submit alternate security mechanisms for HA-MN to IESG
>
> Mar 04 Alternate Route Optimization scheme to IESG
>
> May 04 Home agent reliability to IESG
>
> Jul 04 Bootstrapping solution to IESG
>
> Nov 04 Separate specs for HA Discovery, Route Optimization,
> Renumbering to IESG
>
jak