2.3.9 Mobility for IPv6 (mip6)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

Chair(s):
Basavaraj Patil <basavaraj.patil@nokia.com>
Gopal Dommety <gdommety@cisco.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.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
Internet-Drafts:
  • - draft-ietf-mobileip-ipv6-24.txt
  • - draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
  • - draft-ietf-mip6-mipv6-mib-01.txt
  • - draft-ietf-mip6-mipext-advapi-00.txt
  • No Request For Comments

    Current Meeting Report

    
    Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59
    
    ----------------------------------------------------------
    
    Meeting notes courtesy of: Behcet Sarikaya and Glenn Keeni (Thank you). 
    
    Monday, March 1 at 1300-1500
    CHAIRS: Basavaraj Patil <Basavaraj.Patil@nokia.com>
            Gopal Dommety <gdommety@cisco.com>
    
    
    1. Agenda, Bluesheets, Note takers
    **********************************
    
    - Some reshuffling of the agenda posted for the WG meeting earlier based on 
    prioritization of work items.
    - Added Charles Perkins' I-D 
    draft-perkins-mip6-precfgKbm-00.txt to the agenda
    
    2. WG Docs status update
    ************************
    Basavaraj Patil
    
    - Base Mobile IPv6 specification moving forward after having been stuck 
    with IANA for a long time. Thanks to Jari Arkko for his efforts to get the 
    IANA issue resolved. The I-D is headed now to the RFC editors queue.
    
    - Revision 01 of the MIB document for MIP6 completed. Intent is to go to WG 
    last call mid-April after one more revision. There is also a demo of the 
    current MIB implementation by Glenn Keeni for anyone who would like to see 
    it.
    
    - The API I-D has received some comments on the list and also 
    discussed at Connectathon. Will go to WG LC with the next revision. 
    
    - MIPv6 test suites are at the URL shown in the slides
    
    Gabriel: Has there been a WG LC on Pekka Nikander's I-D 
    <draft-nikander-mobileip-v6-ro-sec-02>?
    Raj: Do not remember. But will check and follow up. The intent is to 
    publish this as an informational I-D.
    
    3. Bootstrapping Problem
    ************************
    Presenter: James Kempf 
    <draft-kempf-mip6-bootstrap-00.txt >
    
    - What is dymanic bootstraping? Two things: Dynamically allocating HA and 
    Home network prefix discovery, and dynamically setting up an IPsec SA 
    between MN and HA.  Benefits. Enables wider address assignment choices, 
    Better configuration and, Load balancing.
    
    Hesham: Dynamic HA discovery does load balancing, not 
    necessarily	dynamic HA assignment using AAA.  
    James: Agree. AAA based approach supports new business models, allows 
    nonsubscriber based access.  
    Raj: Bootstrapping should be independent of AAA infrastructure. 
    Jari: But we do need something for bootstrapping.
    James: One alternative is AAA.
    Charlie: Why not use DHCP like mechanism that we have here at 
    the	IETF-59 venue. Why require AAA? 
    Hesham: Should not mandate AAA.
    James: Current spec is based on manual keying or IKEv1 SA 
    establishment. 
    
    Francis: Disagreement with statement on statically assigned addresses in the 
    slides. But ofcourse it just makes life easier. Mobile node does not get the 
    information if the device is switched off. [ E.g. renumbering 
    information]. Old info needs to be maintained. 
    Hesham: The same is applicable in the case MN is un-reachable.
    James: Benefits include reduced RTT and others. Current support for 
    pushing prefix changes to dormant MNs has drawbacks. 
    TJ: This problem has been discussed. Renumbering should be kept for 
    sometime, dormant mobile has to bootstrap after it wakes up. 
    Raj: Bootstrapping not a solution for the renumbering problem.
    James: Prefix problem needs to be solved.
    James: HA discovery uses ICMP and some ISPs disable ICMP.
    Four bootstrapping scenarios. Out of four 2,3 and 4 are of interest.
    Conclusion. Dynamic bootstrapping is useful. Current IPsec SA 
    mechanism does not allow dynamic bootstrapping.
    Greg: Option 2, 3, 4 is of primary scope
    James: Disagrees
    Greg: Which security assocs we will we use? What are the scenarios being 
    considered for bootstrapping? 
    Raj: There is a design team that is working on the bootstrapping 
    problem. Scenarios and scope will be further clarified therein. 
    
    4. HA reliability problem statement
    ***********************************
    Presenter: Ryuji Wakikawa 
    <draft-jfaizan-mipv6-ha-reliability-01.txt>
    
    - HA failure. Home link failure. Failure detection, how an MN detects 
    failure. Current base spec is not clear. Service interruption. 
    Recovery? Who initiates recovery. IPsec SA assoc. establishment. Correct 
    ordering, if HA changes, new HA does not know the order.  
    - HA reliability is in current milestones, we need a problem 
    statement. 
    
    Deng Hui: Round robin load balancing can be used, i.e. redundancy is built 
    into the HA machine. Also reliability can be accomplished by having a 
    multi-blade server type of machine as the HA.
    Gopal. Reliability solution should be built into the protocol. Hardware 
    solutions are another approach to reliability.
    Raj. Reliability is a WG charter item. Once we have consensus on the 
    problem statement and scope we will move to solutions. The problem 
    statement I-D will be made a WG item after obtaining consensus on the WG ML. 
    
    
    5. Dual stack Mobile IPv6
    *************************
    Presenter: Hesham Soliman 
    <draft-soliman-v4v6-mipv4-00.txt> 
    
    - Problem has been discussed in I-D: 
    draft-tsirtsis-dsmip-problem-02.txt and the discussion today is one 
    possible solution
    - Problem: MIPv4 and mipv6, IPv4 and IPv6 coexist. If MN uses MIP on a dual 
    stack machine and moves. MN needs to have both. Optimisation overhead. When 
    both mipv4/v6 are used handover signaling, RO signaling needs 
    optimization. Fast handover/LMM signaling. 
    - Proposed solution. Allow each protocol to manage mobility, mipv4 to 
    handle both v4/v6 HoAs to bind to an IPv4 CoA. Draft is about mipv6 as 
    migration tool. Use tunneling to carry ipv4 and ipv6 traffic over the same 
    mipv6 tunnel. Extensions needed to do this. The details are in the draft. 
    One binding update that binds both v4/v6 CoA. Also IPsec SAs.  
    
    James: Have you implemented? 
    Hesham: no.
    James. It sounds complicated. IPv6 stack deals with v4 addresses. 
    Hesham: Not really.
    Pascal: What happens if there are NATs? 
    Hesham: We do not deal with NAT traversal.
    Greg: Are we talking of static or dynamic allocations, Dynamic 
    allocation of MIpv4 and static allocations for MIPv6 ? 
    Hesham: Bind the HoAV(4 or,6) to my CoAV(6 or V4). (Dual is not MIPv6 or 
    MIPv4 it is IPv4 or IPv6) 
    XYZ: Mipv6 node makes 6to4 address, would'nt that be easier? 
    Hesham. We do not assume that the visited network will provide 
    anything, e.g. 6to4 relay.  Create dualstack bindings in mipv6. we need 
    extensions to mipv6. 
    XYZ: NTT runs IPv6 worldwide network. MIPv6 HA can have tunnel server, 
    v6/v4 tunnel, MN in IPv4 network. Tunnel server is known and exists, why not 
    use it?  
    Henrik: Mipv4/v6 to setup these tunnels makes sense. There are 
    commercial deployments.  
    Raj: There is a bar bof tonight at 10pm to discuss this topic further.
    Pascal: Which mobility solution to use?
    Raj: We need one mobility solution. It will be mipv4 or mipv6. So this 
    draft is saying use only mipv6.  
    Pascal: Why IETF is proposing two mobility solutions?
    Raj: You have a solution for IPv4 and another one for IPv6. Its upto you 
    which one you implement/deploy.
    
    
    6. Issues with firewalls
    ************************
    Presenter: Franck Le 
    <draft-le-mip6-firewalls-00.txt>
    
    - Issues listed in presentation.
    
    James: Generic problem with firewalls and ESP. Solution is nsis. 
    Jari: Is problem nat or firewall? The solution depends on what. There is nat 
    traversal for IPsec. 
    Frank: Issue is with firewalls. Its the reachability aspect.
    Hesham: How come you assume BU and BAck will go thru?
    Franck: We assume creating state in the firewall. Without using ESP. I am 
    assuming ESP issue is resolved some other way.  
    
    Raj: Problems described here applies to GPRS/UMTS networks as well 
    because GGSN has packet filters similar to firewalls. Xiabao Chen has an I-D 
    that discusses these issues. The I-D is: 
    draft-chen-mip6-gprs-00.txt  Franck's draft and Xiabao's drafts are 
    informational documents that are useful from MIP6 deployment 
    perspective.. 
    
    Question to WG: Firewall issues: Do they need to be documented? Maybe 
    advanced as informational RFC? Go back to ML and discuss. 
    
    
    7. NAI Option
    *************
    Presenter: Kent Leung 
    <draft-patel-mipv6-nai-option-01.txt>
    
    James: There is a shared secret key between the HA and MN. We need to have a 
    design team and do things bottom-up instead of pieces. This relates to the 
    bootStrap option. Approximately 3 persons have read the draft. 
    Kent: Yes some issues are related to bootstrapping. 
    Raj:  The proposal is to use NAI 
    Kent: There is infrastructure that utilizes NAI. 
    Alper: There are other identifiers, like FQDN, opaque names. 
    Raj: AAA mechanisms deployed today indicate that NAI is a good option. 
    Charlie: NAI in mipv4 is good because IPv4 addresses were not unique, but in 
    MIPv6 they are unique. Why not use network prefix? Why shouldn't we take a 
    network address and use it as an identifier?
    
    
    8. Authentication Option for MIP6
    *********************************
    Presenter: Kent Leung 
    <draft-patel-mipv6-auth-protocol-01.txt>
    
    -  MN-HA authentication function, using NAI for identifying MN. AAA 
    servers identify clients using NAI. Some mipv6 modifications are 
    proposed.  
    
    Raj: Alternate key mechanisms should not weaken security. BU is secured by 
    somethingelse not by ipsec.  
    James:  Key distribution. IKE for key distribution. Draft should talk 
    about a specific key distribution.  
    Raj:  This draft assumes shared keys but their distribution is not an 
    issue for this draft.  
    Gopal: Alternative authentication should talk about key 
    distribution?
    Alper: We should not require additional signaling on MIPv6 that does not 
    exist. 
    Charlie: Base MIPv4 replay protection. We can have better key 
    distribution schemes as time goes on. So requiring key distribution may not 
    be a bad idea. Key distribution can be handled later and or 
    orthogonally.
    
    9. AAA Problem Statement
    ************************
    Presenter: Hiroyuki Ohnishi 
    <draft-ohnishi-mip6-aaa-problem-statement-00.txt>
    
    Raj: Integration of MIPv6 with AAA. Additionally AAA can be used for 
    bootstrapping. The AAA WG decided that it is upto mipv6 WG to 
    determine if a MIP6 AAA App is needed.  
    Hesham: It does not look like an integration.
    John: Another WG like AAA can get work from MIPv6 WG if mipv6 wants it. 
    MSAAA can be done in MIPv6 and then diameter mipv6 application  can be done 
    at AAA WG. 
    Jari: Deployments that have AAA and MIPv6 requiring new things at link and 
    netwoprk layer like on 802.11 networks we need to be careful. 
    Raj: This should be an option.
    Pete: Differentiate access authentication and the use of mipv6.
    Charlie: Why not use the AAA solution for MIPv4 for MIPv6 also?
    Raj: Not directly mappable. Since there does not exist the FA.
    
    10. Binding Update Backhauling      
    ******************************
    Presenter: Wasim Haddad 
    <draft-haddad-mipv6-bub-01.txt>
    
    - Bub reduces signalling. BUBC message is used to agree on bub  mode. 
    
    Eric. In the case where the RR test is done the first time: The first time is 
    it secure? Man in the middle attacks can be done. Bub has this problem, 
    maybe it is  more secure but not any more secure.  
    Raj. But Security relies on the esp tunnel between HA and MN. 
    Jari. This is already done in the base spec.
    Raj. Not enough time to discuss further.
        The proposal here is an enhancement to Route Optimization when two 
    end-points are  mobile. Does this I-D address any security issue that is 
    inherent within the the current RR scheme?
    
    11. Optimizing Mobile IPv6 
    **************************
    Presenter: Wasim Haddad 
    <draft-haddad-mipv6-omipv6-01.txt>
    
    Jari: Defining optimization is great. DF RR is good, man in the middle will 
    have only a limited term effect. OMIPv6 might increase the times of 
    effect. 
          Jari feels that there are issues with such an approach. 
    Erik. Agrees with Jari. Latency optimizations are OK but it should like 
    compromise security. Completely getting rid of coti/cot messages not a good 
    idea.  
    
    Attendee: Bub and omipv6 looks same, what is the difference?
    Haddad. Bub is for one end point. And it has bubc message.
    
    
    
    ---------------------------------------------------------
    
    With time running out, Raj provided pointers to Charles Perkins' I-D about RO 
    with preconfigured keys. Discussion of this will be taken up on the list.
    
    Gopal summarized next steps for the WG.
    

    Slides

    Agenda
    Mobile IPv6 Bootstrapping Problem Statement
    Problem Statement: HA Reliability
    Mobility in a Dual Stack Internet
    Mobile IPv6 issues in the presence of Firewalls
    Network Access Identifier Option for Mobile IPv6
    MIPv6-AAA problem statement
    Binding Update Backhauling (BUB)
    Optimizing Mobile IPv6
    Alternative Authentication mechanisms for MN-HA Authentication in Mobile IPv6
    Preconfigured Kbm between Mobile and CN
    MIPv6 Interactions with GPRS/UMTS Networks