2.3.14 Mobility for IPv6 (mip6)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-15


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-05.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-00.txt
  • draft-ietf-mip6-bootstrap-ps-01.txt
  • draft-ietf-mip6-nai-option-00.txt
  • draft-ietf-mip6-firewalls-00.txt
  • draft-ietf-mip6-ikev2-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

    IETF61, Washington DC
    Nov 12th, Friday 2004
    9 AM - 1130 AM

    Chairs: Basavaraj Patil and Gopal Dometty

    Minutes provided by: Samita Chakrabarti and John Loughney

    1. Agenda bashing and WG doc status update

    - MIPv6 Socket API - completed last call - now on AD review
    - Firewall issues I-D completed LC
    - MIP6 MIB status: MIBdoctor pass1 completed; pass2 ongoing

    - TAHI test suite will release version 3.0 in December which is fully compliant with RFC3775/3776
    URL: http://www.tahi.org/mipv6/

    2. Auth I-D discussion
    A consensus call on standardizing this I-D was held on the WG ML. Chairs believe consensus was to progress the I-D as a proposed standard. An issue tracker for the I-D has been created. Comments are welcome.

    Thomas Narten: There is an appeal to the Consensus call result now.
    Consensus was rough, nice if it was clearer.
    We don't formally vote. Packing the room is something to look for, but lurkers can be informed / posters can be uninformed.
    Counting company votes is dangerous.

    Question / choices:
    1. Do not publish at all - has consequences for the relevance of the IETF
    2. Publish on standards track - sends signal that this has IETF support
    3. Publish as info - Does get IETF review & has been done in other cases, e.g. - 3GPP

    James K - has interoperability concerns, but if just for 3GPP2, then its OK. 3GPP2 has come to the IETF, so we should do it. Concerned about standards track, because it might cause interoperability issues due to multiple mechanisms. Would like MIP community to work better with 3GPP2.

    Thomas Narten - we've had a relationship for 3 years with 3GPP and have engineer to engineer working, agrees that would be nice to have with 3GPP2.

    Basavaraj - disagrees that there will be interop problems. People who want to deploy it are from 3gpp2, but could have wider possibly applicability. Haven't heard about what the concerns of folks who don't want this work to be standardized.

    Pervez Yegani - 3GPP2 needs this work, working with Thomas on liason statement. Doesn't see an interop issue.

    James K - Explained twice already. IETF can specify two mechanisms, but operator can deploy just one. If you have a terminal that supports both mechanisms, it may be confused which one can be used. Problem is a deployment.

    Hesham - it's not an interop problem but a deployment problem. In similar circumstantes, sometimes a higher order mechanism is needed for negotiation. Wants third option.

    Gopal - Disagrees with James. We cannot control deployments. This is not 3GPP specific.

    Thomas - should be careful about calling it an interop problem. Its not black or white. It might be that 3GPP2 wants to avoid the IPsec mechanism. There can be a cost with multiple mechanisms.

    Eric Nordmark - unwise to have multiple mechanisms; we will have to implement both or circumstances will not work. Thinks that some assumptions are wrong. If we have multiple mechanisms, then we should have a good reason for this.

    Basavaraj - saying that the HA will need to implement both, terminal will only need one.

    Jari Arkko - it doesn't have to be a weaker option. interop issue - distintion is that 2 random nodes will authenticate to each other.

    Pete McCann - this mechanism is needed to interface with existing credentials, removed IPsec from current architecture because IPsec / IKE v1 cannot interface with existing credentials

    James - thinks we should go back to 3GPP2 and get them to find out about what is needed for IKEv2

    Someone - wonder if this could be handled in IPv6 host or MIPv6 host.

    Pervez - only argument we have heard against this is interoperability. Don't we have rough consensus.

    Thomas - we don't vote, some people are debating the validity of the consensus.

    Pervez - from the business perspective, saying it won't interoperate isn't convincing.

    Basavaraj - doesn't see the benefit of publishing this as info.

    Greg Daley - tried to stay out of this discussion. Thinks we need encryption between the HA & MN, but how to get the key? Thinks we should work on this, doesn't care about the status of the document, but would like do work on this. We need an AS on this mechanism. Concerned that the Security Area will barf on this.

    Thomas - 3GPP2 needs this soon, so we need to complete this.

    Greg - then we need to get people involved in it. Concerned about there is no ESP here. Need a checklist for this. Need strong applicability statement on the features - multicast traffic might be spoofed, etc.

    Gopal - if we do go info, we will have deployment, then future work can be dependent on it.

    Thomas - thinks this will be an ongoing topic for discussion.

    Pascal - thinks there is an impact on other MIP related topics. We will have 2 solutions on the handset.

    How many people don't want it at all - noone
    Do this as a standards track - 9
    Publish as informational - 30

    Greg Daily- Release this as an experimental doc, but work on it still.

    Thomas Narten- reasonable to pub as info, but work on it still

    Hesham - can't have a contract promising anything, shouldn't be a problem releasing it as info.

    Thomas Narten - 3GPP2 would prefer standards track.

    Pekka Savola - we cannot make a contract, publish as info/exp. because of timing requirements, and then analyze the problem more.

    3. IKEv2 on MIP6 (Vijay Devarapalli)
    I-D: draft-ietf-mip6-ikev2-ipsec-00.txt

    RFC3776 describes IPsec on MIP6
    Changes in IPsec architecture (2401bis), and IKEv2

    - New draft to incorporate these changes
    - SPD and SAD config and packet formats
    - required processing steps on the MN and HA
    - describes the use of IKEv2

    Key negotiation
    - Manual keying must be supported
    Dynamic keying though should be supported

    Dynamic key shoud or may?

    Comment - do you mean public key certificate?
    - we have manual key for pre-shared key
    Jari Arkko: The draft talks about how to use IKEv2 but this is optional- no need to support it. In that case there is no issue.

    SPD config
    New selectors
    Mobility header msg type
    ICMPv6 message type

    If IPsec specifieds mobility header as a selector, then MIP6 should support it.

    Question: How do you make interfaces of IKEv1 and IKEv2 work together in IPsec?
    Vijay - The new IPsec will not be interoperable with the older one
    Hesham Soliman - Are we going to step away from per-interface SPDs Moving away from current interfaces is a good move.
    Vijay - We still need to distinguish payloads in different cases, tunnel, without tunnel etc.

    PAD configuration
    Peer auth data base provides a link bet key protocol and SPD

    SAD config
    Use of IKEv2 to negotiate keys
    MN initiates IKEv2 exchange
    Identity is included in IKE_AUTH

    Use of EAP

    - MN indicates it wants to use EAP by leaving IKE_AUTH field unfilled IKE_AUTH should be done after EAP exchange
    - takes 4 round trips instead of 2
    - Should work with other EAP and AAA-HA interface
    - Should we say HA MUST/MAY require this interface?

    Home address configuration:
    Must or May ?
    Jim Kempf - It should be "SHOULD"
    Erik N. - It looks like a bootstrapping solution. It should be linked with bootstrap to have a single solution
    Jari Arkko - thinks bootstrapping support here is a good thing.

    4. Using IPsec to protect signaling between MN and CN (Francis Dupont)
    I-D: draft-dupont-mipv6-cn-ipsec-01.txt

    Presented at the last IETF
    Idea : When you have IPsec bet, CN and MN, just use it Has some details in the doc what is suitable. You need SA between CN and MN etc.

    - Should it be WG item ?

    - Seperate doc for the cookie-based COA test? (optional)

    - Implementations(already one, others?)

    Vijay - Will support it to become WG doc

    Jim Kempf - We should think about how it interacts with Mobike. We should make this as wg draft.
    Suresh - It should be a wg document

    B Patil - Anyone has objection to make it wg doc ? If not we make it as wg doc
    No objection was raised at the meeting.

    4a: (Francis Dupont)
    COA cookie test

    - Initiated by CN , usable by CN which does not have built-in COA test/trust
    - A state cookie is used in order to avoid DOS attacks
    - non-empty IANA consideration section

    Next step:

    Which RO protection mechanism do we need?

    Vijay - it can be an optional care-of-addr test

    WG item? More discussion needed before we make a wg doc.

    Christian V: We had mailing list discussion but it modifies the way base spec does.
    Jim Kempf - We should be more systematic in thinking about one solution or piecemeal soln

    Erik - Don't see how we tie in with RO cookie test. If the threat is third party bombing attack, then how does it help? What are the security requirements?

    Jari - I'd rather have Charlie's draft do COA addr test. Also take a look at the draft we produced in Mobopts

    5. AAA AND MOBILE IPV6 (Giaretta Gerardo)
    5.1 I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt &
    I-D: draft-yegin-mip6-aaa-fwk-00.txt

    Dynamic MIP6 conf
    MN-HA sec association
    AAA-HA interface
    - Interface between AAA of the MSP and HA (HA is a kind of access server)

    Basic security model

    MN --------------------MSP AAA -----------------------HA

    Usage scenario - bootstrapping directly with HA

    MN -----NAS------AAA-MSP-----HA

    Junghoon - Given EAP exchange is there any network access server?
    We first need to have access through NAS then the second step
    Ans:It is a direct interaction with HA

    Pete M : We can separate out network access from MIP access. We should not tie them together.

    Junghoon : What is the meaning of performing IKEv2 before network access service ? If a MN can access(like, performing IKEv2) the visted domain network without granting the network access, it can result in a possbile attack to that network.

    Usage scenario 2

    MN --- NAS--------AAA-MSP -------------HA
    MIp6 within
    EAP -> <---AAA-HA ------> A)

    <-- PANA, L2
    extension->< RADIS/DIA-><---AAA-HA--> B)

    Hesham - Make it generic
    Comment - Focus should not only focus AAA-HA protocol, but also NAS-MSP-AAA
    Greg D - Did not read the draft. If you have security across NAS, AAA-MSP, HA- Do you already have security association between MSP and HA?

    Hesham - This is a good way to use IPsec in MIP6

    James - This solution is not going to work if you don't have AAA infrastructure

    Usage scenario3
    MN---------NAS_____________AAA-MSP -------HA

    Security, Accounting etc.

    Next steps
    Should we identify a protocol that fulfil the goals?

    Similar draft by Alper on AAA-HA interfaces - Raj has sent out the pointer to the slides. In the interest of time, the draft was not presented. Raj described briefly the highlights of Alpers I-D.

    Hesham : What is the requirement? - Should the requirements go to AAA, midco
    m ?
    No reason to put requirement for midcom wg

    James Kempf - likes this, would like to remind people that there are hotspots without link security and authenticates via web page. This solution won't work if you don't have a AAA infra. Should we work on this?

    Hesham Soliman - what is the intention of this?

    Basavaraj Patil - development requirements for AAA work.

    I-D: draft-giaretta-mip6-authorization-eap-02.txt Giaretta Gerardo

    someone - how to define aaa server between ha & aaa server?

    Pasi Eronen - lots of info that would like to provision to user. EAP isn't the right approach.

    Jari Arkko - agrees with Pasi. There are procedural issues as well as technical. This approach might not require AP changes, but changes to EAP methods. If you can re-use existing protocols, this is easier. If you want to use EAP for new purposes, this is harder.

    James Kempf - would prefer to be minimalistic here.

    Hesham Soliman - agree we need to draw a limit, but there are 3 levels of auth typically. There is interest in leveraging AAA infra for this. Doesn't think this will change EAP much.

    Next step
    - Waiting for EAP wg feedback
    - WG doc?

    MN-HA Ipsec SA can be estblished from a shared secret using IKE with PSK auth
    EAP method can be used to exchange PSK

    Jari A- There are some other requirements in EAP methods.

    I-D: draft-giaretta-mip6-amsk-00.txt Giaretta Gerardo

    Jari Arkko - question on changes to EAP framework. As a whole, there are more requirements than just on EAP methods, may be changing EAP API.

    Hesham Soliman - does EAP SIM produce an AMSK?

    Jari Arkko - I think so.

    I-D: draft-jee-mip6-bootstrap-pana-00.txt
    I-D: draft-tschofenig-mip6-bootstrapping-pana-00.txt

    Junghoon Jee, Hannes Tschofenig

    PANA is used between MN and HA
    Used to bootstrap mip6-auth

    Pac <<<PANA message exch----> HA

    Does wg think PANA is appropriate to deliver bootstrapping info ?

    New DIAMETER bootstrapping scenario?

    James K - PANA can work with EAP. Has a problem defining PANA to go
    beyond 1st hop link. ICMP often doesn't work after 1st hop.
    Yoshihiro Ohba - PANA is based on UDP
    James - OK, so I guess that is not a problem.

    I-D: draft-ohba-mip6-boot-arch-dhcp-00 Yoshihiro Ohba

    Model 1 - DHCP server AAA-MS client
    Model 2 - NAS as AAA-MS client

    Draft describes how this arch map to bootstrapping scenario

    James Kempf - Ralph Droms mentioned that backending DHCP server into AAA server is not a good idea. Same problem about NAS pushing stuff into DHCP server. OK to put Home Address into DHCP server. Concerned about the complications & bittleness of this.

    I-D: draft-deng-mip6-bootstrap-bcf-00.txt Hui Deng
    - Introduced new network element (BCF)

    AAA ------- HA1
    | |
    MN -----BCF -------- ---- HA2
    --------- HA3

    Discuss on list with rest of the bootstrapping stuff. Possible design team issue.

    Q: Why is it necessary to separate network access from the bootstrapping function?
    A: Because the operators already have an access authentication mechanism in place. Adding MIP6 to the same, will increase the risk and also complicate the network.

    Hui: Can we separate bootstrap solution into: IASP and MSP?

    I-D: draft-ietf-mip6-precfgkbm-01.txt
    Vijay Devarapalli

    - Proceed with this document.

    I-D: draft-qiu-mip6-rr-improvement-00.txt
    Jianying ZHOU

    DOS attack, session hijacking, movement halting attack
    Problem HOTI/COTI - independent of COA and HoA

    use HOA in COTI and COA in HOTI for authentication and signals

    Christian V.- Even if you combine the two, the attacker will have ability to attack

    Yes - but it is much more difficult, as it needs to know both addr

    Erik - If we do this, we can't keep the same home keygen when COA changes

    Jari - What's the point becuase the packets are flying by anyway and has same limitation that Erik mentioned

    11. Next steps for WG

    - Bring closure to Auth and Identifier
    - Taking transition problem as wg doc
    - DT for bootstrapping
    - Revise charter based on privacy bar bof

    12. Multihoming in MIP6
    Thierry Ernst
    I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt

    Motivation for multihoming
    Applied to fixed hosts, mobile hosts and routers

    Seeking sense from the room

    Shall we include support multiple interfaces in MIP6 WG ?

    Thomas Narten: A problem statement for multihoming is required first. Multi-homing working group is working on different issues - so the problem statement document would indicate the non-mobility cases and carefully consider the mobility cases. Once we identify those, we can then consider whether and what this group needs to address.

    Gabriel: I have a question: if you are going to characterize the multihoming problem then are you also going to consider the case in which you have multiple IPv4 as well as multiple IPv6 addresses? Will get hairy, but at least mentioning might be in order.

    13. Load Balance for Distributed Home Agents in Mobile IPv6
    I-D: draft-deng-mip6-ha-loadbalance-02.txt
    Hui Deng

    Problem: There are many reasons a home agent might want to reduce the number of mobile nodes it is currently supporting. For example, it might be overloaded, it wants to achieve better load-balancing between a peer home agent, or it is going offline for service.

    Idea: New Load Balance Information Option
    New Home Agent Handoff Message

    Question to WG:
    - Should it be WG item ?


    Appeal of MIP6 Consensus Call
    Mobile IPv6 with IKEv2 and revised IPsec architecture
    IPsec between MN and CN
    Care-of address test using a state cookie
    AAA Mobile IPv6 Application Framework
    MIPv6 authorization and configuration based on EAP
    Application Master Session Key (AMSK) for Mobile IPv6
    Mobile IPv6 Bootstrapping using PANA
    Mobile IPv6 Bootstrapping Architecture using DHCP
    Bootstrap Control Function mechanism for Mobile IPv6 Bootstrap
    Preconfigured keys for Mobile IPv6
    Improvement of Return Routability Protocol
    Multihoming in MIP6
    Load Balance for Distributed Home Agents in Mobile IPv6
    Goals for AAA-HA interface