2.3.15 Mobility for IPv6 (mip6)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-27


Basavaraj Patil <basavaraj.patil@nokia.com>
Gopal Dommety <gdommety@cisco.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.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:

Done  Submit I-D 'Issues with firewall Problem statement' to IESG
Done  Submit I-D 'MIPv6 MIB' to IESG
Done  Submit I-D 'Extensions to Socket Advanced API for MIPv6' to IESG
Done  Submit I-D 'Alternate Route Optimization (Pre-config Key) scheme' to IESG
Jul 05  Submit Bootstrapping problem statement to IESG
Jul 05  Submit ID Submit ID 'Motivation for Authentication I-D' to IESG
Aug 05  Submit I-D 'Authentication Option for MIPv6' to IESG
Aug 05  Submit I-D 'Identificaiton Option for MIPv6' to IESG
Nov 05  Submit I-D 'MIPv6 operation with IKEV2 and the revised IPsec Architecture to IESG
Nov 05  Submit Bootstrapping solution to IESG
Dec 05  Submit Problem statement and Solution to Mobile IPv6 transition between v4/v6 networks to IESG
Feb 06  Submit I-D 'Goals for AAA HA Interface' to IESG
Aug 06  Separate specs for Home Agent (HA) Discovery, Route Optimization, Renumbering to IESG
Aug 06  Submit Home agent reliability to IESG


  • draft-ietf-mip6-mipv6-mib-07.txt
  • draft-ietf-mip6-mipext-advapi-04.txt
  • draft-ietf-mip6-precfgkbm-03.txt
  • draft-ietf-mip6-ro-sec-03.txt
  • draft-ietf-mip6-auth-protocol-04.txt
  • draft-ietf-mip6-bootstrap-ps-03.txt
  • draft-ietf-mip6-firewalls-02.txt
  • draft-ietf-mip6-ikev2-ipsec-02.txt
  • draft-ietf-mip6-mn-ident-option-02.txt
  • draft-ietf-mip6-cn-ipsec-01.txt
  • draft-ietf-mip6-aaa-ha-goals-00.txt
  • draft-ietf-mip6-bootstrapping-split-00.txt
  • draft-ietf-mip6-dsmip-problem-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

    Meeting minutes of Mobility for IPv6 (mip6) WG from IETF63
    When: August 2nd, 2005

    Credits for these minutes:
    1. Vidya Narayanan

    2. Christian Vogt

    3. TJ Kniveton (Jabber scribe)

    Chairs: Basavaraj Patil and Gopal Dommety
    1. WG Document status update

    2. ............................

      BP presented the status of various WG documents. See slides. Concerns about the auth protocol have been raised by the security ADs. Chairs have provided a response to the ADs w.r.t these concerns.

    3. Mobile IPv6 bootstrapping in split and integrated scenarios

    4. ..............................................................
      Presenter: Gerardo Giaretta
      I-D: draft-ietf-mip6-bootstrapping-split-00

      Integrated scenario: currently under study

      Objective: The main objective of bootstrapping is minimzation of pre-configured data on the MN.
      • Split Scenario: MSA and MSP are different entities

      • HS: In the roaming scenario, is the HA assigned by the local network?

      • GG: Yes, the HA may be assigned by the local network;

      • HS: Do I lookup home.com or visiting.com?

      • GG: visiting.com;

      • HS: trying to understand the purpose of this HA

      • GG: needed to solve the roaming case

      • HS: this is not just a roaming case; there is also a case where the HA service is provided by an application provider, maybe in another network, or in the home network

      • GG: this scenario is the same as the split scenario; while this is not roaming for network access, it is roaming for mobility service

      • HS: the split scenario seems to be referring to roaming

      • GD: Are you referring to dynamic HA assignment?

      • HS: No, only the location of the HA

      • HS: If this is not a roaming scenario, and I dont have an AAA server, can I use certs and use this solution?

      • GG: Not addressed by this scenario, but addressed by the solution

      • GG: MSA only authorizes the service; does not assign HA or HoA

      • HT: Address is assigned by local network; HA assigned by home network

      • HS: This is not an issue. Address can be assigned by local network; authorization does not rely on the HoA

      • BP: Take it on ML

      • Presentation continues HA address discovery (DHAAD, DHCP, DNS); bootstrapping using EAP and public keys; HoA assigned using IKEv2

      • FD: Bad interpretation of what IKEv2 configuration is for; provides no validation; it is okay to use it to update DNS

      • GG: We have used a new attribute to use for auto-configured HoAs to be used in creation of the child SA

      • JA: Is this auto-config happening often or only once?

      • GG: only once, upon bootstrap; SA depends on the lifetime of the SA

      • AP: pre-configuring prefix is not bad; DNS also requires home.com to be pre-configured

      • DT: just another option;

      • AP: Anycast can be used for load balancing

      • JK: What protocol does that?

      • AP: nothing

      • Presentation continues HoA registration with DNS;

      • HT; A draft is present to link the components to Diameter

      • EN: Today, DHCP server does DNS updates; that is the right way to do it; it may be an option to have the HA do it; it should not preclude the MN from doing it using DHCP or whatever, if it wants to

      • GG: MN only requests HA to do it using the DNS Update mobility option

      • Name?: Is dynamic HA assignment included in the integrated scenario?

      • DT: No; DNS can do dynamic HA assignment

      • ?: that doesnt do load balancing or other scenarios

      • BP: Take it on the ML

      • ??: If you use DNS to look up the HA address, is the request sent by the local network or home network?

      • GG: by definition, the split scenario doesnt address HA assignment in the local network

      • SC: Not very clear if AAA is a requirement for this solution or not

      • GG: Not a req.; either AAA or certs can be used; e.g., IKEv2 w/EAP or IKEv2 w/certs can be used

    5. Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture

    6. ......................................................................
      Presenter: Vijay Devarapalli
      I-D: draft-ietf-mip6-ikev2-ipsec-02

      • 2 Major Issues

      • 1 RFC3775 & 3776 describe SPD and SAD configs assuming MH and ICMP protocols as selectors; this makes the need for per-interface SPD; 2401bis proposes more granular selectors should we make the use of this a MUST?

      • FD: there are 2 reasons why this should not be a MUST you cant assume protocol selectors are available everywhere; SHOULD is good; implementers should have the choice of doing one or the other

      • VD: How about if it is a MUST on the HA alone? MNs that do support it can use it

      • FD: Use recommend, not MUST

      • HS: If all ICMP is protected, there is no issue

      • JA: Why is this a problem? If this is using IKEv2, and it uses 2401bis, what is the problem?

      • VD: 2401bis does not say these selctors are a MUST

      • JA: If you want to do the per-i/f SPD, not sure if you have to say all of it is supported

      • Presentation continues Major issue 2 packet formats not meant to support all possible ipsec configs; detailing tunnel mode will bloat the draft

      • HS: For HoTi and CoTi, why not tunnel the packet with a transport mode SA on the outer header?

      • VD: that can be done

      • HS: why not change 3775 to accommodate that?

      • VD/BP: May be; send email on the ML

      • FD: This is explicitly prevented in 3775 for good reason;

    7. V4 traversal for IPv6 mobility protocols - Scenarios

    8. .......................................................
      Presenter: Vijay Devarapalli
      I-D: DT still working on the I-D

      • Scenario 1 – v4 access network; v6 home network;

      • 2 same as 1, but MN is behind a NAT

      • 3 MN wants both v6 and v4 sessions

      • 4 HA does not have a v4 address; connecting a v4 network and v6 network not being addressed; nothing mobility related here;

      • NAT traversal is in the scope

      • FD: Do you want just re-addressing or full mobility with RO and everything?

      • VD: we havent come to that yet;

      • BP: Scope of the design team has been limited to a small set of scenarios to address immediate deployment scenarios

      • FD: problem is not to just get solutions; need to select good solution

      • AP: When mip4 already solves the issue of using IPv4 HoA, why solve this here?

      • VD: doesnt make sense running mip4 and mip6 at the same time; lot of issues explained in the dsmip draft

    9. Mobility management for Dual stack mobile nodes

    10. ..................................................
      Presenter: Hesham Soliman
      I-D: draft-ietf-mip6-dsmip-problem-00

      • Signaling overheads of running mip4 and mip6 at the same time

      • AP: why provide session continuity for v4 when tunneling in v6?

      • HS: still a valid problem

      • HS: problem providing reliable service

      • DTh: Is it only an efficiency issue? Or more?

      • HS: Both efficiency and connectivity; Erratic connectivity; optimized mobility management not possible

      • DTh: It does work; just not efficient enough

      • GT: optimization becomes necessary here

      • GDa: Is there any spec on v4-v6 transition?

      • DT: There is GRE

      • Presentation continues; Solution suggestions;

      • HT: NAT traversal work has been done for ikev2, ipsec

      • AP: also done for mip4

      • HS: ok. Henrick is on the DT

      • AP: binding a v4 address to a v6 address – isn’t that part of 6-to-4 tunneling?

      • HS: yes, but without anycast, this is a one-way solution; depends on how people deploy it

    11. IP Address Location Privacy and IP Mobility

    12. ..............................................
      Presenter: Rajeev Koodli
      I-D: draft-koodli-mip6-location-privacy-00

      • Address privacy and location privacy

      • FD: HoA is not visible when BUs are protected, HoA is not visible

      • RK: If BU is protected and HoTi and CoTi are used, it can be protected

      • BP: Now that Mobopts has done the work, maybe the WG should take it up and publish as informational

      • EN: those who are interested in this space can attend the Alien bof.

    13. HA reliability and load balancing

    14. ....................................
      Presenter: Li Qin
      I-D: draft-deng-mip6-vrrp-homeagent-reliability-00

      • BP: Reliability is a WG charter item and there are several solutions addressing this at the present time

      • Questions about HA allocation raised by James Kempf. There are some concerns regarding this I-D and the solution being discussed in bootstrapping.

      • Vidya N. had concerns about the fact that an HA could detect failures faster than an MN. It should be the other way around.

      Presenter: Hui Deng
      I-D: draft-deng-mip6-vrrp-homeagent-reliability-00

      • Motivations for this I-D presented. Partial and full recovery mechanisms specified.

      Presenter: Vijay Devarapalli
      I-D: draft-devarapalli-mip6-nemo-local-haha-00

      • This protocol was designed based on the needs expressed by Connexion for addressing their problem scope. But can be used for HA reliability as well.

      Presenter: James Kempf
      I-D: draft-haley-mip6-ha-switch-00

      • James said that this draft proposes a mechanism that is needed by operators deployoing MIP6. They need a mechanism by which they can shutdown an HA gracefully while ensuring that the MNs are switched to other HAs.

      Discussion about whether HA reliability works hould be taken up by the WG. Many expressed that a reliability solution is needed at this time in order to enable deployments. There were also opinions that HA vendors can have their own solutions to deal with reliability. The sense of the room was that work on this is needed. The chairs decided that the questions would be taken up on the ML and consensus determined therein about taking up this work now.

    15. Review summary of I-D draft-irtf-mobopts-ro-enhancements-01

    16. ...............................................................
      Presenter: Christian Vogt

      • GG: On 120-ms RTT.. does handover delay include movement detection delay?
        A: Yes, we are sending high frequency RtrAdv. It does not include LL handover delay. It also does not consider delay that normal IPv6 autoconf would require. We use optimistic DAD.

    17. Securing HA list in MIP6

    18. ...........................
      Presenter: Sachin Dutta
      I-D: draft-dutta-mip6-ra-00

      • Several solutions to address the problem of securing the HA list presented.

      • JA: Solution 2-SEND". What is the 2nd issue that will not be resolved?

      • A: The frequency is high. So if multiple HAs send RA frequency,..
      • JA: I'm not sure I agree. Frequent RAs are for the host. if the home link has hosts, it makes sense to have those RAs. If the HAs are on the same link, there's no need for high frequency.

      • EN: It might even be possible, even if you do have hosts and want 30ms beacons, have those RAs not include information updates, HA list, SEND stuff.

    19. New items before WG

    20. .......................

      • Application interface to exchange mobility information with Mobility subsystem

      • I-D: draft-momose-mip6-mipsock-00

        Chairs aked that the WG should take a look at this I-D and provide feedback to the authors.

      • Care-of Address Test for MIPv6 using a State Cookie

      • I-D: draft-dupont-mipv6-rrcookie-01

        The idea is to use a state cookie as in SCTP and IKE. SCTP explanations are very good. No state creation on CN, so no DoS problems with many BUs. There are IANA considerations and hence publishing this as experimental is one possible way forward. In MIPSHOP, Jari found a nice way to solve it.

    21. Next steps

    22. ..............
      Gopal discussed the next steps for the WG.

      W.r.t the Auth I-D, Margaret Wasserman: I can tell you what the status is, but not how it's going to get resolved. Both Security ADs have discusses on the document. We had a brief meeting yesterday, and there/'s not definite resolution on the table. We might be able to make some traction with an applicability statement that it's specific to 3GPP2 networks, or that it should only be used on nets with some properties. But that won't necessarily resolve the discusses. There's a lot of bad feeling because one of the ADs was on the security directorate when it was asked to review this. Nothing was communicated back to them to clear this u

      HS: Hesham Soliman
      GG: Gerardo Giaretta
      GD: Gopal Dommety
      BP: Basavaraj Patil
      JA: Jari Arrko 
      FD: Francis Dupont
      AP: Alex Petrescu
      JK: James Kempf
      DT: Design Team
      DTh: Dave Thaler
      HT: Hannes Tschofenig
      EN: Erik Nordmak
      VD: Vijay Devarapalli
      SC: Samita Chakrabarti
      GT: George Tsirtsis
      GDa: Greg Daley
      RK: Rajeev Koodli
      VN: Vidya Narayanan


    Mobile IPv6 bootstrapping in split scenario
    MIPv6 with IKEv2 and revised IPsec Status Update
    V4 traversal for IPv6 mobility protocols - Scenarios
    Mobility in a Dual Stack Internet
    IP Address Location Privacy and Mobile IPv6: Problem Statement
    Mobile IPv6 Route OptimizationEnhancements: Revision of draft-irtf-mobopts-ro-enhancements
    Reliability and Load Balance among multiple Home Agents
    HA Reliability using the HAHA Protocol
    MN-HA Signaling for HA Unavailability
    HA initiated bootstrap for MIP6
    Securing Home Agent List in MIP6
    Application interface to exchange mobility information with mobility subsystem
    Care-of address test using a state cookie
    Experimentation Results for Early Binding Updates and Credit-Based Authorization