Subject: [Mip6] Revised Charter

From: [email-masked]
Date: Fri, 5 Sep 2003 11:18:12 -0500

Hello,

Below is the most recent or updated charter that has also
had the benefit of AD review:

-Basavaraj

Charter:
--------

  Internet Area (int)
       Thomas Narten ([email-masked])
       Margaret Wasserman ([email-masked])

  Chairs:

       Mailing list: [email-masked]
       To subscribe: https://www.ietf.org/mailman/listinfo/mip6
       To post: [email-masked]
       Archive: 
http://www1.ietf.org/mail-archive/working-groups/mip6/current/

  Mobile IPv6 (MIPv6) specifies routing support to permit an IPv6 host 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-mobileip-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 will be to enhance base
  IPv6 mobility by continuing work on developments that are required for
  wide-scale deployments. Additionally the working group will ensure
  that any issues identified by the interop testing of the MIPv6
  specifications are addressed quickly. Specific work items with this
  goal in mind are listed below:

  1) Create and maintain an issue list that is generated on the basis of
     interop testing and address these issues as enhancements to the
     base protocol

  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 mechanisms of Mobile IPv6.

  3) A number of enhancements to basic IPv6 mobility were identified
     during the development of the base specification. These
     enhancements will 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 Mobile Node (MN) and Home Agent (HA) that would
        enable easier deployment of Mobile IPv6. This bootstrap
        mechanism is intended to be used when the device is turned on
        the very first time and activates MIPv6. The WG should
        investigate and define the scope before solving the problem.

     - Improving home agent reliability: in the event of a home agent
       crashing, this would allow another home agent to continue
       providing service to a given mobile node.

     - Support for a Mobile Node changing its home address, either
       because of renumbering in its home network or because it
       periodically changes addresses (perhaps via RFC3041)

     - Route optimization will require security mechanisms for
       trusting and updating the binding information. Return-routability
       is the basic mechanism for route-optimization. Mechanisms 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.

     - 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.

  ------------------------------------------

  Sep 03 Charter approval

  Nov 03 Problem statement documents (to IESG)
           - Issues with firewall
           - Mobile IPv6 transition between v4/v6 networks

  Jan 03 Bootstrapping problem statement to IESG

  Feb 04 Submit MIPv6 MIB to IESG

  Mar 04 Submit alternate security mechanisms for securing the
	 signaling message between Mobile Node (MN) and Home Agent
	 (HA) to IESG 

  Mar 04 Alternate Route Optimization scheme to IESG

  May 04 Home agent reliability to IESG

  Aug 04 Bootstrapping solution to IESG

  Nov 04 Separate specs for Home Agent (HA) Discovery, Route Optimization,
         Renumbering to IESG

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Pekka Savola <[email-masked]>
Date: Sat, 6 Sep 2003 08:52:11 +0300 (EEST)

a couple of quick comments..

it has been a while since I looked at MIPv6 spec, so I may have forgotten 
something, but I'm wondering what are the immediate problems at least in 
two work items that require getting addressed soon.

>        providing service to a given mobile node.

I'm not sure what this is going to mean?  Would this mean a 
HA state-sharing protocol between HA's, or something else?

I'm concerned how well this work item might fit in MIP6 WG, and whether 
doing such would create significant amount of new complexity.
 
>        periodically changes addresses (perhaps via RFC3041)

Isn't this already supported?  Why else are we doing DHAAD as we speak?  
Couldn't one connect to another HA (or to the same one twice) to obtain 
two addresses, end of story?

Note: using RFC3041 on home addresses is probably very bad idea.  The 
prefix stays static, so in practice this will not give much additional 
privacy, unless there are thousands of MN's under the same HA prefix.

General note: the charter milestones are quite fast-tracked.  For this to 
succeed, I think we have to have a clear commitment from the WG and the 
document editors, and no major issues raised.

It's OK as is, but I would be a bit more pessimistic about the delivery 
dates.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 07 Sep 2003 08:54:59 -0700

Pekka Savola wrote:

> Isn't this already supported?  

it is.

what is missing is how to authorize Binding Updates for the new HoA
configured from RFC 3041. the HA should be able to verify if the MN
owns the home address.

Vijay

Why else are we doing DHAAD as we speak?

---

From: Pekka Savola <[email-masked]>
Date: Sun, 7 Sep 2003 21:55:04 +0300 (EEST)

> configured from RFC 3041. the HA should be able to verify if the MN

Authorize to *whom*?

For CN?

Why can't one perform the return routability test for each one used?
Shouldn't that fix the problem?

For HA?

Why don't the current methods work?  Because the MN has created the 
RFC3041 address independently, without consulting Home Agent, and needs to 
sync up that with the HA?

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 07 Sep 2003 20:33:56 -0700

to the HA. the HA needs to prevent a misbehaving MN from claiming
another MN's home address. the HA doesnt know about the MN's new
RFC3041 home address.

this is not needed in all deployment scenarios though.

Vijay