2.3.16 Mobility for IPv6 (mip6)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-17


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://www.ietf.org/mail-archive/web/mip6/index.html

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-06.txt
  • draft-ietf-mip6-mipext-advapi-03.txt
  • draft-ietf-mip6-precfgkbm-01.txt
  • draft-ietf-mip6-ro-sec-02.txt
  • draft-ietf-mip6-auth-protocol-04.txt
  • draft-ietf-mip6-bootstrap-ps-01.txt
  • draft-ietf-mip6-firewalls-01.txt
  • draft-ietf-mip6-ikev2-ipsec-01.txt
  • draft-ietf-mip6-mn-ident-option-02.txt
  • draft-ietf-mip6-cn-ipsec-00.txt

    Request For Comments:

    RFC3775 Standard Mobility Support in IPv6
    RFC3776 Standard Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents

    Current Meeting Report

    Minutes of MIP6 WG meeting

    Minneapolis, MN USA
    Monday, March 7th 2005, 1930-2200

    Chairs: Basavaraj Patil and Gopal Dometty

    Minutes provided by: Suresh Krishnan

    Agenda bashing
    Alper: wants to change the order of item 4 and 5 since framework needs to be covered before the solutions. Patil: Thinks the order is fine as 4 is very specific and will not be affected by the choice of the framework

    Document Status
    Raj presenting

    * Authentication protocol and MN Identity options drafts completed WGLC.
    Security ADs have raised DISCUSSes
    IDs to be revised to clarify the motivation (why do we need these?)
    3gpp2 has a critical dependency (already past deadlines)

    * Preconfigured kbm draft is awaiting AD review and feedback

    * RO security was reviewed by Elywn. Gabriel and Pekka to do the fixes

    * Lots of comments about bootstrapping in the ML

    * CN IPSEC draft needs WF review before going to WGLC

    * IKEv2 ipsec needs reviews from ikev2 experts

    Extension to Sockets API for Mobile IPv6
    Samita Chakrabarti presenting
    I-D: draft-ietf-mip6-mipext-advapi-03

    No major issues left, just editorial ones. New ID to be issued to fix WGLC issues working with cairs and ADs

    AD evaluation comments pointed out that a clearer applicability statement is needed.and a switch is required on the socket apis to do source address selection. say CoA vs HoA

    Needs implementation info to make progress maybe from HUT or WIDE).
    Implementors need to contact chairs/authors

    Targeted for INFORMATIONAL

    MIP6 operation with IKEv2
    Vijay Devarapalli presenting
    I-D: draft-ietf-mip6-ikev2-ipsec-01

    A whole bunch of requirements have been relaxed
    -> Support for Peer Authorization database, HoA configuration and EAP changed to MAY
    -> Clarified that there is no need to use public key mechanism to authenticate HA if the chosen eap method already is mutual.

    Open Issues:

    SA for the BU is not created until the first CREATE_CHILD_SA (requires 3 rtt rather than 2rtt)

    SPD entries and dynamically allocated HoA (SPD uses HoA)
    3 options
    -> update SPD when the HoA changes
    -> reinstall policy entries when the HoA changes
    -> use a name in SPD and have name point to HoA

    J. Jee wants a clarification about use of preshared keys as the method. Jari talks about adding a reference to a draft Hannes and Pasi have written about not needing to use PK when EAP mutual authentication is used.He also mentions that the draft has no home currently. Vijay will add the reference

    MIP6 AAA framework
    Alper presenting
    I-D: draft-yegin-mip6-aaa-fwk-00

    The goal of the draft is to identify various frameworks where AAA is used for mip6 service and agree on one or more to standardize

    Alper talks about 4 different frameworks and the characteristics of each

    Framework 4:
    Jee is concerened about preconfiguring the HA address and thinks dynamic assignment of HA is very important. Alper will talk about it later.

    Framework 2:
    Vijay wants to know how DHCP server know which domain the MN belongs to? Alper thinks that it is immaterial. Will use DHCP ID to correlate

    Vidya wants to know what happens if the NAS and HA do not belong to the same domain as the NAS shares SA only with AAA-L(visited)? Greg thinks that this can work transparently as there is a transitive trust relationship between AAA-L and AAA-H. Raj has the same view as Greg. Gopal wants to add info about AAA-H and AAA-L.

    Framework 3:
    Jari wants to know how MN can know CoA and HA before initiating the procedure. Greg thinks that there is no need to know as the AAA can do the BU James wants to know how the AAA server can know where the prefix is.Greg thinks that it will come from the NAS. Alper thinks that this framework is workeable but complex.

    There are three requirements for a solution to fulfill. HA discovery, HoA discovery, and MN-HA key generation

    Hannes and Alper talk about how these frameworks can be mix-n-matched to satisfy these requirements

    Jari is concerened about the impact caused on network since the goal is to reuse the exisiting AAA relationship. Client software, DHCP and NAS need to be updated to implement these solution.

    Framework4: requires new aaa-mip6 application
    Framework1: requires confirmation from ip conf sec bof
    Framework2: needs new AAA attributes and PANA/DHCP options (*3gpp2 prefers this approach)
    Framework3: Very complex and may not be justifiable

    Alper wants direction from the WG to know which way to go. Gopal wants people to read the drafts and discuss on the ML

    MIP6 Bootstrapping
    James Kempf presenting
    I-D: draft-chakrabarti-mip6-bmip-00

    Tries to address situations where loose trust between serving network access provider and Mobility Service Provider(MSP).e.g. enterprise networks, hotspots (As most of them use Credit Cards to authorize and not AAA), and for infrastructureless deployments as well.

    John thinks that UAM (universal access method) is popular now but there are still backend AAA networks. He also thinks that 802.1x means more and more RADIUS as UAM does not work on small devices. James believes that CC based authentication is not going away and we need to support it. Jari thinks that this method does not fit a mobility scenario since the CC based authentication is used mainly for wireless nodes in hostpots (usually immobile).

    The basic idea is for the MN to ask for DNS SRV records to get the HA address. Then IKEv2 is used to extablish MN-HA keying. Replay protection is provided by Message identity code in DNS (RFC1035) and data integrity and origin auth provided by DNSSEC.

    Alper wants to know how the HA will authenticate the MN. James thinks it will be preprovisioned credentials like EAP username/password, preshared keys etc.
    Alper is concerned about sharing the HA address with external networks.
    James is not worried even though DNS has no authentication. He also clarifies that this is meant to be used in the absence of RADIUS.
    Raj is worried about DNS caching HA address. Thomas is also concerned.

    Hannes wants to decouple the two problems addressed in the draft 1) use IKEv2 for bootstrapping and 2) use DNS for discovery. He also suggests the possiblity of using multi hop PANA

    James wants to use DNS TSIG (RFC2845) for protecting HA addresses. Thomas thinks that nobody needs this. James thinks that if addresses are hard to get it makes DoS harder. Thomas thinks that James is very unclear. He wants to know what is really being protected. MN from bogus DNS replies or the DNS server from bogus DNS requests? James says both scenarios are protected againt. Samita clarifies that DNSSEC is not deault and is optinal. Raj thinks this makes DOS attacks easier Thomas disagrees and states that he likes this solution. This is nice and simple instead of the other complex solutions. He compares publishing the HA address to Wells Fargo advertising its 1-800 Number.

    Goals for AAA-HA interface:
    Gerardo Giaretta presenting
    I-D: draft-giaretta-mip6-aaa-ha-goals-00

    The document describes design goals and requirements on the interface between AAA and the HA. The purpose of the document is to allow matching goals and frameworks.

    Raj wants to know if the draft should become a wg item in its current form?

    James supports the document but wants to wait for the output of the Bootstrapping Design Team(BSDT) to proceed further. Vijay disagrees (he does not want to wait). Alper wants to choose framework before doing this as he thinks that we cannot choose anything other than Framework with this.

    Gopal wants to know if the goals are related mainly to bootstrapping. Gerardo says there are other goals like accounting. Patil and Gopal think that it is a good idea to do this independently as there are other goals.

    Conclusion is that the I-D will be made a Working group draft. However it will not be progressed until the bootstrap design team has completed its work. Any input from the bootstrap work will be considered in the AAA-HA ID.

    Location privacy in MIP6
    Rajeev Koodli presenting
    I-D: draft-koodli-mip6-location-privacy-00 and

    Intro- specific scope for MIPv6
    HoA - visible in all packets the MN uses it home or visited network
    COA - visible at visited networks


    Hoa COA could be profiled for activity
    COA reveals roaming of a mobile node node when HoA is used

    -can use privacy ext, to IPv6 (rfc3041)
    - Can introduce additional MIP6 signalling ( when coa changes )

    Profiling problem

    Using 3041 introduces DNS and IPSec considerations

    DNS , IPsec (rekeying for change in Hoa)

    Roaming problem
    - reverse tunnel data packets (to solve COA problem)

    Privacy Label Computation
    Don't send HoA in the BU in the clear - use in label
    Label should be computable without the knowledge of HoA

    Mobopts will discuss this initially and similar other proposals.

    Conclusion: Mobopts will pick up this work and study it further. The resulting analysis will be presented to the MIP6 WG along with recommendations for solutions or best practices suggestions.

    Raj wants to know if the wg should work on location privacy:
    yes? about 30 hands
    no? no hands

    IPv4 traversal for mip6 protocols
    Vijay Devarapalli presenting
    I-D: draft-wakikawa-nemo-v4tunnel-01

    This is useful if the MN lands on v4 only access network. The MN registers IPv4 address as CoA using a new mobility option and can setup all types of tunnels. 6 over 4, ESP, UDP etc. Use same mechanism for mip6 and nemo.

    Is there interest to do this in the wg?

    Gopal thinks that we should discuss this for the next IETF. Greg thinks that it looks interesting. He thinks we should have a bar bof.

    Next steps for WG
    Gopal Dometty presenting

    -> Address AD/IESG comments on auth option

    -> Bootstrapping solution
    solution ID by next IETF.
    Close design team shortly after next IETF
    last call and IESG by IETF64

    -> MIP6 transition issues
    Gopal wants an ID to document transition issues.
    Vijay thinks it is a bad idea to write an all encompassing problem statement. Raj and Gopal agree with Vijay. Thomas thinks that this problem has been around for long and v6 v4 transition issues should be documented by someone who ACTUALLY has a problem. Otherwise we will have a huge problem space. Gopal wants to define the problem space to be as narrow as possible. Thomas wants to agree on the scope of the problem before solving it

    ->work with mobopts to define and suggest privacy solutions
    ->propose revision to milestones

    Rajeev wants to know the timeline for the mobopts work. Gopal mentions that it should be done before the next IETF.

    A Scheme of Mobile firewall in MIP6
    Qiu Ying presenting
    I-D: draft-qiu-mip6-mobile-firewall-00

    The idea is for the HA to control the activities of the MN in a visited network.

    Raj wants to know if this is applicable only with HMIP. Qiu says it is. He also mentions that it is a scenario to illustrate out a general scheme.

    PF_KEY between MIPv6 and IPsec/IKE
    Shinta Sugimoto presenting
    I-D: draft-sugimoto-mip6-pfkey-migrate-00

    MIP6 uses IPSEC to protect signalling messages. SA pairs need to be established and tunnel mode SAs need to be updated when the CoA changes. MIP6 may not have direct access to the SADB.
    Defines a new PF_KEY message called MIGRATE
    PF_KEY MIGRATE requires update of SAD and SPD
    This has already been implemented

    Vijay thinks this is very good work. Hannes has worked on a similar document which is more generic and wants a slot to talk about it.

    Raj mentions a draft from James/Vijay about HA unavailable message which is sent when a HA is going down. It needs to be discussed in the ML (END OF MEETING)

    People referenced in minutes
    Basavaraj Patil (Raj)
    Gabriel Montenegro (Gabriel)
    Pekka Nikander (Pekka)
    Elwyn Davies (Elwyn)
    Vijay Devarapalli (Vijay)
    Junghoon Jee (Jee)
    Jari Arkko (Jari)
    Hannes Tschofenning (Hannes)
    Pasi Eronen (Pasi)
    Alper Yegin (Alper)
    Vidya Narayanan (Vidya)
    Greg Daley (Greg)
    James Kempf (James)
    John Loughney (John)
    Thomas Narten (Thomas)
    Gerardo Giaretta (Gerardo)
    Rajeev Koodli (Rajeev)
    Gopal Dommetty (Gopal)
    Qiu Ying (Qiu)
    Shinta Sugimoto (Shinta)


    Status Update
    MIPv6 operation with IKEv2 and revised Ipsec
    Bootstrapping MIP6 Using DNS and IKEv2 (BMIP)
    AAA-Mobile IPv6 Frameworks
    Goals for AAA-HA interface
    IP Address Location Privacy and Mobile IPv6
    IPv4 traversal for IPv6 mobility protocols
    A Scheme of Mobile Firewall in Mobile IPv6
    PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE
    MN-HA signaling for HA Unavailability