2.3.14 Mobility for IPv6 (mip6)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-24

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-03.txt
  • - draft-ietf-mip6-mipext-advapi-02.txt
  • - draft-ietf-mip6-precfgKbm-00.txt
  • - draft-ietf-mip6-ro-sec-01.txt
  • - draft-ietf-mip6-auth-protocol-00.txt
  • - draft-ietf-mip6-bootstrap-ps-00.txt
  • - draft-ietf-mip6-nai-option-00.txt
  • Request For Comments:
    RFC3776StandardUsing IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents
    RFC3775StandardMobility Support in IPv6

    Current Meeting Report

    Mobile IPv6 (mip6) meeting minutes
    IETF 60, San Diego

    # Session 1 of 2 #
    # Tuesday August 3rd, 2004 from 9 AM - 1130 AM #


    Thanks to Samita Chakrbarti, Nick Moore and Gabriel Montenegro for taking the minutes.


    1. Agenda and Document status updates - Basavaraj Patil

    - MIP6 base specifications have been approved as PS RFC3775 and RFC3776
    - API and RO-Sec documents have completed WG LC. A few issues identified and these are being tracked via the issue tracker

    Revised IDs will be submitted to ADs.
    - MIB document being reviewed by MIB doctors. To be submitted to ADs following the review.
    - Bootstrap design team completed work on the problem statement. I-D published as WG document (draft-ietf-mip6-bootstrap-ps-00);
    Discussion archive is available (http://vesuvio.ipv6.tilab.com/pipermail/mip6-boot/);
    Future discussion on MIP6 ML.
    - Two new wg drafts
    - Mip6 issues with firewalls
    Revised version published; Will be published as WG I-D after ietf60
    - Use of IKEv2 for setting up the MN-HA SA required for MIP6

    Issues tracker for WG docs: http://www.mip4.org/issues/tracker/mip6/
    All WG I-Ds are expected to use this issue tracker.


    2. Discussion on ro-sec doc - Gabriel Montenegro

    - Update: LC Completed; I-D pursued as Informational.

    - Closed issues:
    o Improvement to spurious BUs
    o Passive attack against privacy
    o Presentation of ingress filtering
    o Issues with IPSec related text in intro
    o Caveat about questionable assumption
    o Thanks to Francis Dupont for very helpful comments
    o DNSSEC bashing
    o Added different home-addr and coaddr check. More tweaking is perhaps needed


    3. Bootstrapping problem statement - Alpesh Patel

    - Definition of the problem: obtaining enough information to setup SA with home agent, home-address, home agent.

    - Goals and non-goals are discussed.
    Adv: minimize pre-configuration, obtain hoa dynamically, anchor to HA dynamically, possible integration with AAA

    - Scope of the problem stmt and various scenarios were discussed.
    o Mobility service suscription
    o Integrated ASP network
    o Third party MSP
    o Infrastructure-less scenario ( out of scope of this doc)

    - Seed information:
    - FQDN of HA, MN's NAI and shared secret with AAA or public key (digital certificate)

    - Next steps:

    - Fix editorial comments from design team, more comments should be posted in the wg. No issues by DT.

    Christian : Any evaluation made on EAP or existing soln?
    Ans: Solutions have yet to be evaluated. Current discussion focused on problem statement only.

    Erik : Requirement of access authentication for access network? Piggybacking is not desirable and wrong path to follow.

    Ans: Could piggy back bootstrap info when changing access network (Patil, Alpesh, Jim)

    Narten : How often do we bootstrap? Bootstrapping does not need optimization
    Ans: Depends on the deployment scenarios. Could be just once or every time a mobile node powers up etc.

    Majid : looking for solution? Is this group chartered with AAA solution
    Ans: AAA is one solution. Various approaches are being evaluated.

    Jari: Separate out access network and service network authentication
    Alper: Bootstrapping for LMM scenario is required
    Vidya: Since it is auto-config it should belong to zeroconf
    Christian: MIPv6 is already complex - leave the document for flexibile solutions.

    Jim Kempf - This is no theoretical physics. We have to use based on what people are using today. This document is a good start.
    Gopal : Please send comments on this doc to ML. We will have revised doc by next IETF


    4. MN-HA authentication presentation - Alpesh

    o draft-ietf-mipv6-auth-protocol

    - Changes since last version was discussed
    MN-HA authentication options and MN-AAA options were discussed

    - Solution:
    o new Mobility options during BU
    - MN identification option
    - MN-HA and MN-AAA authentication options triggers AAA interaction HA-HAAA
    - response in the BAck

    - Pros:
    o minimum over the air signaling
    o ease deploymenbt: nai and auth infrastructure same as IPv4
    o SDO's such as PP2 require this option

    - Next steps: Add clarifying text in sec considerations
    clarify MN-AAA authetication option
    clarify the usage/details of identification option

    Christian: The design should not specify a new protocol.
    Use existing protocols like EAP. No need to invent a new one.
    - this assumes there is only one round trip
    - should not have this constraint
    - protocol should allow several round trips
    - just embed EAP and be done with it

    Charlie Perkins
    - not anything new, this is just the same as MIP4
    - but don't like the ID option used for replay protection cuz this is provided by the BU anyway

    - no need for ID option for replay protection, sequence number in the BU is enough

    - even SDO's might want to use UMTS-AKA or some such for wlan internetworking and this requires 2 round trips, so you should also support that

    Lots of pushback from Francis and others on these drafts assuming the MN won't use IPsec.

    Pete McCann
    - make sure it's clear that RO is not possible with this draft, for that you do require IPsec

    - why did we go through all the trouble of spec-ing IPsec if we now backpedal

    Patil : We are doing this draft because it would be ease deployment of the protocol. Draft version 15 discussed a similar mechanism.

    Yoshiro from Toshiba
    - no talk about rekeying, why not?

    Ans from Kuntal: in PP2 we do rekeying on a per-session basis

    Jim K : To be honest, 3GPP2 and 3G vendors need this. We should listen to our customers. Have it reviewed by Sec directors.

    Charlie : Problem with identity option

    Parviz Y- If there is nothing wrong in the sec. mechanism in this draft then please move this ID fast as 3GPP2 has deadlines
    Narten - expressed concern on adoptability of IPsec if IETF keeps allowing alternative approachs.
    Patil - It is critical for Mobile IPv6 deployment

    Consensus Question: Should the WG take up this work item?
    Consensus sought on the I-D.
    No clear consensus achieved. Consensus to be taken up on the mailing list.


    5. NAI extension - Alpesh Patel

    o draft-ietf-mipv6-nai-option

    - No open issues known to the author.

    - Alper's request to extend it contain FQDN info.

    service enabler: NAI

    Charlie: not comfortable with elevating this to the stature of THE internet identifier

    Kent: this is to easily obtain an optimal HA

    Vijay: applicability is limited to the authentication option draft, not useful beyond that. NAI is user identity only useful within AAA infrastructure

    ??: some existing identities (e.g., IMSI) don't fit into the NAI format (not supported by the BNF)

    Samita - the draft should clarify if the NAI option would be applicable for other business models. If the answer is yes, then it makes sense to proceed with this draft.


    6. Pre-configured Kbm between MN and CN - Charles Perkins

    o draft-ietf-mip6-precfgKbm

    Testing Care-of-address - requires new sub-section or new draft. It can co-exist with the existing Route optimization mechanism. Should the pre-Kbm draft be expanded to allow CN to demand coa test ? Kbm then becomes a preconfigured home keygen token, so that terminology in the draft should be changed.

    Added testing CoA's by signaling that this is required and the CoTI/CoT exchange. Care-of keygen token from this; Home keygen token using preconfig secret betwe MN and CN; In this case, the Kbm is really a preconfigured home keygen token

    Francis: care-of test problem is something he also has with IPsec MN-CN draft and have several solutions possible propose to have a document on how to do CoT initiated by CN

    Vijay: agree
    Francis: yes, make it a separate document/mechanism

    Should all BUs contain nonce-indices option for consistency?

    Jari- We have multiple mechansim to do RO security mechansim. This draft does not need to support all the options.

    Charlie's draft comments will be taken into ML


    7. Use of manually configured IPsec SA between MN & HA - Vijay Devarapalli

    - Rfc3776 supoorts both manual and dynamic IPSec keying

    - Manual IPSec Keying for Mobile IPv6

    - What is dynamic IPSec keying?

    - MIPv6 3GPP2 adoption:
    o IPSEC w IKE
    o Mobility option auth protocol

    - PP2 uses stream ciphering algorithms for all encryption cuz they're more efficient over wireless, so they use AES-CTR

    Francis: AES is NOT a stream cipher, it is a block cipher. And IPsec does not use stream ciphers, only block ciphers.


    8. Remote testing status at IPv6 plug test - Patrick Guillemin

    - Origin Madrid IPv6 summit may 2003, first remote IPv6 plug tests

    - 20 registered companies, but only few people used this.
    How many people read the draft ? Should this test continue?

    Vijay- This is very useful - we should continue with this.

    Basavaraj requested Samita And TJ Kniveton to revise the draft-kniveton for interop testing. TJ acknowledged on the microphone.


    9. MIPv6 authorization using EAP - Gerardo Giaretta

    I-D: draft-giaretta-mip6-authorization-eap

    Advantage : no changes in AP
    Both Radius/Diameter can be used between NAS and AAA server MN-HA IPSec SA can be setup from keying material exported by the EAP

    Next step:
    Extension of I_D for IKE auth


    10. Using IPsec between Mobile and Correspondent IPv6 Nodes - Francis Dupont

    No questions or issues.
    The whole issue of RO and what schemes should the WG take up needs to be revisited.


    11. Load Balance for Distributed Home Agents in Mobile IPv6 - Hui Deng

    o draft-deng-mip6-ha-loadbalance

    Traffic between MN-HA would be loadbalanced. HA will pro-actively notify MN about the change and new HA

    More improvement is needed for SA and HA handover messages

    B. Patil : Do we need a load-balancing solution in IETF ?
    If bootstrapping is considered for load-balancing, then we can first see how that solution becomes applicable to load balancing. Load balancing is not that critical


    12. Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering - Xiabao Chen

    - Potential issues for MIPv6 deployment in GPRS/UMPTS were discussed including 3 scenario cases.
    - It is an individual draft - the author asked if this should be submitted as RFC.

    Jim Kempf - This is an implementation problem. Should take it to 3GPP.
    Speaker - We are not trying to solve it at IETF. But this is for information and raising awareness.


    13. Applying Cryptographically Generated Addresses to Optimize MIPv6 - Jari Arkko

    Note: ( Ericsson is working on IPR issue)

    Techniques employed
    - CGA
    - Home routing while moving
    ( less pkt loss)
    - Minimal address testing
    (smaller latency)
    - significant signal reduction

    -- reduction of the latency

    -- Improved security

    Jim Kempf : Issue: every CN would have to implement this option
    Jari - It is optional for improvement of latency

    Chairs (B.Patil) : We should step back and see if we are able to produce multiple authentication scheme for RO.

    Jari : CGA is quite stable and we need to get to RFC to use them.


    / /
    / End of Session 1 of 2 /
    / /

    # Session 2 of 2 #
    # Tuesday August 3rd, 2004 from 5 PM - 6 PM #

    1. Roadmap for MIPV6 -- Gopal Dometty

    WG doc status
    auth drafts - Get consensus & issue last call
    prefcfg Kbm close issues
    mipv6-mib Last call after MIB expert review
    ietf-mip6-ro-sec closes issues
    mip6api proceed to IESG

    Work under consideration for WG status:
    -MIP6 bootstrap solutions
    -Firewalls problem sttmt
    -MobileIPv6/v4 interop
    -Use of IKEv2 for seting MN-HA SA

    Discussion on reqirement and scope:
    -Alternative RO scheme
    -MIPv6 integration with AAA infrastructure
    -HA load balancing/reliability
    -Mipv6 location privacy

    Jari Arkko: (Bootstrapping problem comment) should be possibility of alternative themes.

    Erik Nordmark: We should propose some alternatives to routing optimization security.

    Jari Arkko: no harm in designing alternative schemes, there is space for them. No-one's going to be hurt by alternative schemes.

    James Kempf: Is route optimization on our charter.
    (Erik: yes.)
    JK: Then I'm in favour of it but it should be a background item.

    Gopal D: charter identifies one solution, doesn't necessarily exclude others, but ...

    JK: if charter is ambiguous it should be updated.


    2. Carl Williams: IPv4/IPv6 interoperability for mobility.

    George Tsirtsis: Problem statement since a year ago. Some comments incorporated but no comments since February. Can this become WG draft?

    Raj: can we get a consensus? (not many people have read it)

    Chairs: please resubmit and we'll take it from there.


    3. HeeJin Jang: DHCP Option for HA Discovery
    o draft-jang-dhc-haopt

    Jari Arkko: is it mandatory to send the MN identifier in response to the DHCP server? You're trying to skip the ocnfiguration of some of the parameters by getting from DHCP server, but that means adding a new parameter.

    Alper Yegin: In the current impl. its mandatory for node to provide,

    Raj: is there any validation, security WRT who's requesting?

    Alper: example is incomplete, in the base MIPv6 RFC there needs to be authentication, we need to fold auth into DHCP we're hoping to use existing DHCP auth but somehow we need to map.

    Jari: it's not too dangerous to give the address of the HA to anyone who asks ... if you're doing bootstrapping you're missing security association.

    Alper: We've presented to DHCP, but DHCP WG needs MIPv6 to ask for it to be included.

    James Kempf: We've discussed whether this is for local HA or remote HA is there any distinction made.

    Alper: Yes, the MN has a way to convey which it is asking for

    James: useful for local HA,

    Charlie Perkins: about identifier, isn't it going to have a hard time picking remote HA without identifier. Is this just for local HA? If you want to get some kind of remote HA you're going to need id. There's an alternative AAA method.

    Alper: Like MIPv4, and 3GPP has decided to use DHCP.

    Ralph Droms: is that so?

    James: that's because they don't have EAP.

    Ralph: MIP6 vs DHC working group: DHCP working ground is responsible for the syntax, we work in collaboration with another WG which is responsible for the semantics: should this be a MIP6 or a DHCP WG item.
    Raj : Where is the configuration information actually stored, only in the local or only in the home network how do you retrieve that unless id ...

    Alper: this mechanism is not supposed to change the DHCP routing. information should already be at the server it'd normally contact.

    Ralph: if there's an oracle someplace through which we can get HAgent for all home networks into all foreign networks, device could get home information on foreign systems. But how is it distributed.

    Pascal T: this draft may be very useful for local info for LMM.


    4. Bootstrapping using Radius - Kuntal Chowdhury

    I-D: draft-chowdhury-mip6-bootstrap-radius-00.txt

    Pascal: everything done in MIP needs to be redone in NEMO so you get prefixes as well, could you extend this draft to think about NEMO.

    Vidya: thinks its important to work on both DIAMETER and RADIUS.

    James K: realistically, people are using RADIUS, DIAMETER would be good I don't like the idea of having the attributes be the HAddr as such. we should use EAP? If we decide to go with hop-by-hop security we'll regret it.

    Kuntal: there is an option to use end-to-end. so far we did not decide.

    JK: point is you've got to roll some custom auth, why not just use EAP.

    Kuntal: whatever, as long as you can get authed

    Jari: it seems that you are defining attributes not new RADIUS commands, with that in mind it seems existing rad -> dia methods should work.

    Ralph Droms: you mentioned the DHCP RADIUS option, my view: the existing agent option is not designed to put new info into a DHCP server which is carried to client, it lets DHCP server choose from its provisioned information ...

    Kuntal: when I wrote draft (missed ...)

    JK: that's a pretty big change in the DHCP arch. chairs would have to work out if they want to do it.

    Charlie P: we have AAAv6 submitted for consid by MIP but went to AAA and they didn't want it either ... if we're going to look at this we should consider AAAv6.

    Erik: you're assuming AAA home and routing home are same admin domain. if that isn't the case you'd need some other bootstrapping. potentially my AAA home is diff to my routing home.

    Alper: in response to james: although you can get end-to-end using EAP there are two problems, it's not used in all access nets and you need some sort of bucket in EAP and that's not in all EAP.

    Samita: can you use prefix length instead of prefix in message to save some bytes.


    5. Certificate-based Binding Update Protocol (CBU) - Jianjing Zhao
    I-D: draft-qiu-mip6-certificated-binding-update-01.txt

    Raj: consensus call: base spec has RR has auth, there are now alternatives. should the WG consider alternative schemes.

    Charlie: how is this to be partitioned between this group and mobopts. if mobopts comes up with a scheme should it go into this group or stay in mobopts.

    Raj: yes, if they got some numbers they could move into this WG.

    Jari (JA): as an example ...

    Charlie P: it was in this charter because it was removed from this draft at the last minute.

    Raj: so do we open it up?

    JA: as a practical datapoint, we have IANA considerations in the RFC, must be standards track to allocate numbers ...

    James: hows an MN supposed to know what technique its going to use. we should have it figured out.

    Thomas: if somebody wants to do experiments why do they need new code points. what is the criteria to decide when to go forward with a route optimization scheme.

    Raj: ... thus MobOpts.

    JA: we want to deploy, and we already have two methods (so floodgates already open)

    Erik: if the goal is to think carefully before have >1, its' odd that there's already 2, but 3,4,5 can't happen. Should be a more level playing field.

    Vijay D: Can we assign experimental numbers then?

    JA: about this level playing field, does this prevent the adoption of other RO schemes?

    JA: I don't think there interop issue here, we can always fall back to base RR ...

    Thomas: if you've got one mandatory and one on the side its easy enother,

    Francis D: its in the charter to investigate shared key.

    Nick Moore: is it we (mip6) or we (mobopts) who will take up this work?

    / /
    / End of Session 2 of 2 /
    / /


    Mobile IP version 6 Route Optimization Security Design Background
    Bootstrapping Problem Statement
    Authentication option for MIPv6 Status Update
    NAI option for Mobile IPv6
    Preconfigured Kbm
    Manual IPsec Keying and Mobile IPv6
    IPv4/IPv6 Interoperability for Mobility
    MIPv6 authorization and configuration based on EAP
    IPsec between MN and CN
    Problem Statements for MIPv6 Interactions with GPRS/UMTS Packet Filtering
    Optimizing Mobile IPv6
    Certificate-based Binding Update Protocol (CBU)
    Multi-homing for small scale fixed network Using Mobile IP and NEMO
    DHCP Option for HA Discovery in MIPv6
    RADIUS based MIP6 bootstrapping
    Load Balance for Distributed Home Agents in Mobile IPv6