2.3.10 Mobility for IPv6 (mip6)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

Basavaraj Patil <basavaraj.patil@nokia.com>
Goral Dommety <gdommety@cisco.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: mip6@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/mip6
Archive: http://www1.ietf.org/mail-archive/working-groups/mip6/current/
Description of Working Group:
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 (RFC XXX) and draft-ietf-mobileip-mipv6-ha-ipsec-06 (RFC XXX)

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.

Goals and Milestones:
Nov 03  Problem statement documents (to IESG): (1)- Issues with firewall; (2) - Mobile IPv6 transition between v4/v6 networks
Jan 04  Bootstrapping problem statement to IESG
Feb 04  Submit MIPv6 MIB 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
  • - draft-ietf-mip6-mipv6-mib-00.txt
  • No Request For Comments

    Current Meeting Report

    MIP6 WG
    Monday November 10th, 2003
    Chairs: Basavaraj Patil, Gopal Dommety
    Agenda Bashing (Basavaraj Patil)
    Document status (Basavaraj Patil)
    MIPv6 docs to be moved to the MIP6 WG from the Mobile IP WG (which is 
    IANA assignments for the base spec ongoing
    MIPv6 remote interop testing (Samita Chakrabarti)
    Connectathon 2004 was announced
    mobileip-ipv6, mipv6-ha-ipsec, perhaps nemo basic support draft will be 
    Connectathon update - new co-ordinator (UNH - Hiroshi T)
    Design team was formed to develop guidelines  for uniform remote testing 
    over IPv6 Internet.
    This effort is similar  to 6-bone testing. This effort does not replace 
    regular MIPv6 interop events
    First draft is an individual submission. Need to get WG consensus if this 
    should be a WG doc, on the interest and the Informational nature of the 
    The purpose of remote interop testing is for  some implementers to 
    dedicate stable MIPv6 systems in the Internet, other implementers can 
    check basic functionality.
    Requirements to participate:
     all nodes must register through ETSI web page, dedicated HAs, MNs & CNs in 
    the test network
    Central registration at: 
    Comment from someone (could not catch the name) about helping out with 
    reviewing the test plan.
    Continuing... (TJ Kniveton)
    Discussed issues of IPv6 address allocation, security association, 
    virtual home link, diagram of nodes, solicited more implementer's 
    comments are welcome
    Current thought is to support Security associations - three methods to auth 
    Inter-home agents protocol (HAHA) (Ryuji Wakikawa)
    Discussed the Problem statement:
     need for reliability,
     load balancing (HA can be serving large number of MNs,
     if MN not uses RO HA becomes bottleneck of communication;
     several HAs sharing the load for the same home network), redundancy (with 
    HAs on topologically different links), MN cannot currently register its 
    binding to multiple HAs simultaneously, serviceability, HA switching.
    Discussions on mailing list: applying existing protocols (VRRP/HSRP, BGP 
    model, CARP-like mechanisms)
    Goals are redundancy, load sharing, flexible HA selection
    James Kempf: Want to do ipsec between HAs? (Yes) If you use ICMP you can't 
    because the spec prevents you from doing it.
    TJ Kniveton: MN can change to be registered with best HA, how do you 
    figure out which is best?
    Ryuji: MN knows some of the HAs...
    TJ Kniveton: Needs some more thinking... MN home address will be moved
    to new HA. What if HA advertises address that is not topologically
    Q: If you route packets back to primary HA, how do you then reduce load on 
    This actually increases load on HA. Also, if two HA advertise the same 
    prefix MN will only choose one. How will second prefix enter routing 
    table? Discussion about this ending with "Don't think you get my 
    Q: Big aggregated prefix will be split into several... to reduce load you 
    don't route traffic back...
    Basavaraj Patil: Need to discuss what the problem is that the WG wants to 
    work on. Need problem statement & problem definition. Then decide this is 
    problem really relevant that we should work on. This is one solution, 
    there are probably more. We need to look at that.
    Alpesh Patel: Routing with multiple anycast addresses popping up...? Any 
    analysis on this?
    Ryuji: Will make problem statement & send to the list.
    MIPv6 advanced socket API extensions (Samita Chakrabarti)
    API is useful for debugging, tracing, policy applications etc. This is a 
    combined effort of IPv6 & MIP6 WG
    Updates & resolved issues, suggested changes.
    Next steps : Basavaraj Patil: Discussions with IPv6 WG, happy to let work be 
    done here, in conjunction with IPv6 WG, ok to make this a WG document if 
    there is WG consensus.
    Problem statement for multi-homed mobile nodes (Nicolas Montavont)
    List of current work on multi-homing
    What's missing: terminology, motivation, accurate & common goal
    Some issues are related to Mobile IP while some are not
    A MN is multi-homed when it has several addresses to choose between 
    Benefits of multi-homing: redundancy, ubiquitous computing, load 
    balancing, preference settings
    Why MIPv6?
    Open issues
    Which WG to take this to?
    James Kempf: This is what I want to talk about at bar BoF tonight. Have 
    invited people from transport area to come.
    Q: Some issues related to MIPv6, some not, those related to MIPv6 are 
    obviously for this WG.
    Basavaraj Patil: Aspects for MIPv6 are interesting. Making bigger 
    changes to current MIPv6. How important is it to get this done right now? 
    Need to also look at if problem can be solved in different way. 
    Suggestion to look at problem statement & scenarios.
    Thierry Ernst: Good to investigate problem statement, but where do we do it? 
    This WG? Nemo WG? How to coordinate activities between WGs.
    Q: Node with multiple interfaces... that's the problem.
    Raj: ADs have any comments?
    Thomas Narten: No clear answer. Clarify problem statement, and ask 
    question about which WG for each specific problem. Maybe there is no WG, 
    maybe we need BoF.
    Basavaraj Patil: This is problem also seen in nemo. Don't start new WG and 
    work on generic solution. Have to consider fact that 
    MIPv6-specific issues belong in this WG.
    Q: Some issues are very specific; which interface node picks is totally 
    internal to node. How multiple pieces are put together? Applicable to 
    MIPv6: you cannot have MN with multiple addresses work with MIPv6 today.
    Basavaraj Patil: Let's continue discussion, look at scenarios, see what 
    comes out of bar BoF.
    MIPv6 MIB (Glen)
    Purpose: monitoring operations of mip6 entities (MN, HA, CN); 
    operational statistics, errors, events 
    Configuring/controling mip6 entities
    MIB design
    Greg Daley: Don't have to bind same home address to same c/o address in all 
    cases... CN1 & CN2, you want to communicate with them on two different 
    paths, you want to have entry in table... multiple c/o address to one home 
    address, BU list tells you who you are communicating with; you have no 
    information about that in this table
    Samita Chakrabarti: What are address types
    Glen: Here type is address type
    Greg Daley: Does registered also mean re-registered?
    Glen: No
    Q: When you come back home you can de-register. This does not expire. Want to 
    make that distinction?
    Updated I-D, MIB issues: MIB review guidelines, RFC issues: security 
    Related issues, to be done, implementation
    Route optimization hint option (Keiichi Shima)
    Problem statement: MIP6 defines route optimization mechanism, there are no 
    guidelines when to start route optimization
    Things to be discussed & defined: condition on when to use RO, methods to 
    inform MN about condition.
    Example of configuration: fire-walled network
    Q: why not just configure firewall to let packets through? Firewall never 
    blocks response to request. Mobility header. Don't understand what 
    problem you are trying to solve here.
    Basavaraj Patil: Yes, this is firewall problem. Let's take this 
    Jari Arkko: Would be better to update firewall. Also, wouldn't it be 
    better to let message get dropped and inform MN there is no RO (if 
    firewall blocks). That's the way the specification currently works.
    Greg Daley: Other issues than firewall cases? What about latency between MN & 
    CN? You reduce signaling each time you move if you don't have to do RO.
    Basavaraj Patil: This draft only looks at one instance where RO should be 
    used or not. There are lot more cases, and therefore lot more work that 
    needs to be done on this.
    Q: Valid problem, but depends whether 
    organization/corporation wants to go to standardization or just 
    reconfigure / solve internally.
    Roadmap for MIP6 (Gopal Dommety)
    Home agent reliability
    Alternate RO schemes
    MIP for MIP6
    Bootstrap for SA between MN & HA
    Document issues
    Separate specs for issues such as....
    Charlie Perkins: Combine the charter of this WG with mipshop?
    Gopal Dommety: Out of scope of the roadmap discussion.
    Q: What are we planning to do with bootstrap? Where is mechanism coming for 
    Basavaraj Patil: We had lengthy discussion in Vienna.
    Jari Arkko: One thing missing is if you add new home address, setting up 
    policy entrance is not possible.
    Discussion items (Gopal Dommety)
    Identity for authentication (NAI)
    Multi-homing discussion
    Deployment issues discussion
    Vendor-specific extensions
    Authentication of MN to HA without ipsec
    Looking for people interested in working on bootstrap mechanisms.
    Thanks to Eva Gustafsson and Alpesh Patel for taking excellent meeting 


    Route Optimization hint option
    Problem Statement for Multihomed Mobile Nodes
    Inter Home Agents (HAHA) Protocol
    Mobile IPv6 Remote Interop Testing Design Team Report
    Mobile IPv6 Advanced Socket API Extensions
    Document Status
    Roadmap/Discussion Items