2.3.8 MIPv6 Signaling and Handoff Optimization (mipshop)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

Gabriel Montenegro <gab@sun.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: mipshop@ietf.org
To Subscribe: mipshop-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/mipshop
Description of Working Group:
Mobile IPv6 specifies routing support to permit IP hosts using IPv6 to move between IP subnetworks while maintaining session continuity. Mobile IPv6 supports transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings.

To accomplish this, the mobile node notifies its home agent (and potentially also its correspondent nodes) of the current binding between its home address and its care of address. This binding allows a mobile node to maintain connectivity with the Internet as it moves between subnets.

Depending on what steps a mobile node must perform on a new subnet, the lag between when the mobile node has layer 2 connectivity and when it begins sending and receiving packets on the new link may be substantial. A mobile node must first detect at layer 3 that its point of attachment has changed, then it must perform configuration on the new link, including router discovery and configuring a new care of address. After that, the mobile node must perform binding updates with the home address and any correspondent nodes. Since many layer 2 mobility technologies require that the mobile node drop its link connectivity to the old subnet when moving, any packets between the correspondent node and the mobile node sent or in-flight during this time arrive at the old care of address, where they are dropped. Such packet loss may have significant adverse effects.

The Mobile IP Working group had previously been developing two technologies to address the issues of signaling overhead and handoff latency/packet loss:

- Hierarchical Mobile IPv6 mobility management (HMIPv6)

HMIPv6 deals with reducing the amount and latency of signaling between a MN, its Home Agent and one or more correspondents by introducing the Mobility Anchor Point (MAP) (a special node located in the network visited by the mobile node). The MAP acts somewhat like a local home agent for the visiting mobile node by limiting the amount of signaling required outside the MAP's domain.

- Fast Handovers for Mobile IPv6 (FMIPv6)

FMIPv6 reduces packet loss by providing fast IP connectivity as soon as a new link is established. It does so by fixing up the routing during link configuration and binding update, so that packets delivered to the old care of address are forwarded to the new. In addition, FMIPv6 provides support for preconfiguration of link information (such as the subnet prefix) in the new subnet while the mobile node is still attached to the old subnet. This reduces the amount of preconfiguration time in the new subnet.

These two technologies can be used separately or together to reduce or eliminate signaling overhead and packet loss due to handoff delays in Mobile IPv6.

Scope of MIPSHOP:

The MIPSHOP Working Group will complete the FMIPv6 and HMIPv6 work begun in the Mobile IP Working Group. Specifically, the WG will:

1) Complete the specification of HMIPv6 protocol.

2) Complete the specification of FMIPv6 protocol.

Because work (ongoing or originating) in other working groups may suggest changes or alternative designs for HMIPv6 and FMIPv6, these specifications will be advanced as Experimental RFCs until more experience is obtained with IP mobility in IPv6.

3) Complete work on a set of requirements for "Localized Mobility Management (LMM)", whereby a Mobile Node is able to continue receiving packets in a new subnet before the corresponding changes in either the Home Agent or Correspondent Node binding. It is the intention that the requirements be consistent with the FMIPv6 and HMIPv6 protocols; in the event that there are inconsistencies, they will be documented.

4) Complete work on the applicability of FMIPv6 in the specific case of 802.11 networks for advancement as Informational RFC.

There are security issues that arise because of the highly dynamic nature of the security relationships between, say, a mobile node and its mobility anchor points, or between a mobile node and its access routers in a fast handover scenario. The working group is not required to provide solutions to all these issues before publishing its experimental and informational protocols. The working group will document the security requirements and the shortcomings of the solutions in the corresponding protocol specifications. This will provide valuable feedback to other groups or subsequent efforts.

Goals and Milestones:
Oct 03  Working Group Last Call on draft-ietf-mipshop-hmip-xx.txt
Oct 03  Working Group Last Call on draft-ietf-mipshop-lmm-requirements-XX.txt
Nov 03  Working Group Last Call on draft-ietf-mipshop-fmipv6-xx.txt
Nov 03  Discuss Last Call comments and security analyses at IETF 58
Dec 03  Submit draft draft-ietf-mipshop-lmm-requirements-XX.txt to IESG for consideration of publication as Informational
Jan 04  Submit draft-ietf-mipshop-hmip-xx.txt to IESG for consideration of publication as Experimental
Jan 04  Submit draft-ietf-mipshop-fmipv6-xx.txt to IESG for consideration of publication as Experimental
Feb 04  Working Group Last Call on draft-ietf-mipshop-80211fh-xx.txt for Informational
Apr 04  Submit draft-ietf-mipshop-80211fh-xx.txt to IESG for consideration of publication as Informational
  • - draft-ietf-mipshop-hmipv6-00.txt
  • - draft-ietf-mipshop-fast-mipv6-00.txt
  • - draft-ietf-mipshop-lmm-requirements-00.txt
  • No Request For Comments

    Current Meeting Report

    MIPSHOP (MIPv6 Signaling and Handoff Optimization)
    THURSDAY, November 13, 2003
    1530-1730 Afternoon Sessions II
    CHAIRS: Gabriel Montenegro <gab@sun.com>
    Minutes by:
    	Henrik Levkowetz <henrik@levkowetz.com>
    	Behcet Sarikaya <behcetsarikaya@yahoo.com>
    Some edits by the chair.
    ; MIPv6 Signaling and Handoff Optimization WG (mipshop)
    ; THURSDAY, November 13 at 1530-1730
    ; ==================================
    ; CHAIRS: Gabriel Montenegro <gab@sun.com>
    ; Agenda:
    ; 1. Preliminaries        10 Mins                 Chair
    ;    - Minutes
    ;    - Document status
    ;    - Agenda bashing
    3 workgroup drafts:
    	WG last call completed on the lmm requirements document Some comments came 
    in; new last call expected Nov. 26 through Dec 3, going to IESG (as 
    informational) on Dec 5.
    	HMIPv6 and FMIPv6 drafts currently in last call until Nov. 24.
    	Group is adopting Pete's 802.11 handover draft as per the charter. 
    Target: WG LC on feb and to IESG as informational on April 4.
    Next steps:
    	Dec 03 - LMM to IESG as informational
    	Jan 04 - FMIPv6 to IESG as experimental
    	Jan 04 - HMIPv6 to IESG as experimental
    	Feb 04 - 802.11 Fast Handoff WG LC
    	Apr 04 - 802.11 Fast Handoff to IESG as informational
    ; 2. Localized Mobility Management Requirements: 20 min
    ;    I-D: 
    ;    Presenter: Carl Williams
    ;    Slot to discuss comments received during WG last call.
    Carl talked about the LMM issues; 
    	1. Make the document less MIP-specific.
    	2. Clarify the intro with respect to the intent and background of the 
    	3. Title change; 'Localized Mobility Management Requirements' to 
    'Localized Mobility Management Goals'
    	4. FMIPv6 listed as reference but not cited; led to discussion of 
    including reference to the mobiliy terminology draft from Seamoby wg.
    	5. Add security consideration section
    	6. Minor editorial comments
    	A timeplan running up to submission to IESG on December 5th after a new wg 
    last call was shown.
    Gabriel:	Issue 3 - go with goals, issue 4 remove the reference
    James:	Agree, but we'll need a security considerations section
    Carl:		Yes, Pekka and I will work on this; and then submit etc. 
    according to the time plan.
    ; 3. Fast Handovers for Mobile IPv6 (FMIPv6): 30 min
    ;    I-D: 
    ;    Presenter: Rajeev Koodli
    ;    Slot to discuss comments received during WG last call.
    Rajeev		presented the wg last call comments on the FMIPv6 drafts.
    	A change log of revisions since IETF57 was shown. Last call comments were 
    shown, mostly relatively minor adjustments, see slides for details.
    	Input from mailing list (ML). codevalue=0 change should to MUST.
    	LinkLayer Address option. Change length to 8 octets to accommodate 
    EUI-64 addresses,
    	Lifetime of NCoA by NAR in NAACK? Same as lifetime for the prefix in RA.
    	Change destination address of FBack to source address of FBU. Maybe leave as 
    it is.
    	PAR should start buffering after processing FBU not after processing 
    	No need for PAR to buffer after processing FBU. It is not clear why we 
    need this change.
    Greg:		On the processing after FBU, the issue was rather one of the 
    semantics of the FBU.
    Rajeev:		...
    Greg:		Maybe the spec is not clear on when it is permissible to start 
    tunnelling. Need to be clarified
    Rajeev:	(About setting the U bit at different times)
    Greg:		So the confusion seems to be about the U bit. So possibly there is a 
    problem there.
    Rajeev:	The router is buffering a sliding window
    Greg:		Yes , then it might work
    Gab:		Maybe some clarification with respect to the U bit would be 
    James:	Who signals the buffer is the vital point Might make sense to put in 
    some words about how to implement the buffer. 
    Rajeev:	It now says the router must 'buffer and forward'
    James:	Ok, that may be sufficient.
    Rajeev:	(more issues)
    Alper		Are we going to recommend a working group item behind this last item 
    (where to specify link-layer triggers)?
    James		We have said that we will specify in other places the various 
    link-layer triggers.
    Alper		I just want to make sure that it is picked up somewhere...
    Rajeev:		(more issues)
    		- Using PrRtAdv both as a response to PrRtSol and as a handover 
    	      - either different code value
    		- or code=0 and a NcoA option
    James:	Prefer new code value.
    Greg:		Next - Identifier value in grat. PrRtAdv could create 
    re-transmission confusion. Propose having an increasing sequence number as 
    identifier, with a different code.
    Rajeev:	Ok
    Rajeev:	(more issues)
    		James/Rajeev interchange about how does PAR know FBU is sent from the new 
    link? No change from proposal on slide.
    Vijay:	Matching FNA with NAACK:
    		We don't need to match these up.
    Greg:		We're optimizing a corner case. If you just left this out, it would 
    probably be fine, because there's stuff in the pipe (Opti Dad) which will 
    fix it. Why have an NAACK at all? Why have this in the FMIP at all?
    Rajeev:	Fine with deprecating NAACK.
    (longer interchange Rajeev/Greg/James/Vijay about having this address 
    configuration as part of FMIP. Turns out Greg is basing his comments on an 
    earlier version of the draft. )
    James:	The draft should not in any way imply that there is any other way 
    than DHCP to do stateful address configuration
    (Gab/Greg/Rajeev continues FNA/FBU/NAACK discussion.)
    Gab:		I guess we can take this on to the list.
    ; 4. Hierarchical Mobile IPv6 mobility management (HMIPv6): 30 min
    ;    I-D: 
    ;    Presenter: Chair (slides by Hesham Soliman)
    ;    Slot to discuss comments received during WG last call.
    Gab presents Hesham's slides. Last call still on, please send slides. 
    Some technical comments, lots of nits.  
    	- Role of P, I and V flags not clear
    Greg:		In most cases you'd be reverse tunneling to the MAP, so maybe you 
    don't need the P and I flags
    James:	Relies on having to turn of ingress filtering. However re. FMIP, the 
    MAP is going to be in the same adm. domain; but it might not here, so 
    using these flags might open a security risk.
    Greg:		Essentially, there is text about holding on to MAPs as long as you 
    can, but if you use these flags you're going to loose your binding then. We 
    need to take this to the list.
    Gab:		I'd be in favour of deprecating these flags.
    James:	That would be my preference too.
    Gab:		Proposal to be confirmed by the list to remove these flags.
    Greg:		Going on to the R flag, this is historic. It was for extended mode 
    but now no extended mode. Will talk to Hesham about removing this.
    	- Remove section 9. Hesham has expressed he's ok with this.
    	- Add text to explain that a MAP further away from the MN may provide 
    better location privacy.
    That's about it, please send comments by next monday.
    ; 5. WG discussion:  30 min
    ;    I-D: none
    ;    Moderator: chair
    ;    Recent email exchanges have suggested for the working group
    ;    to produce a requirements (or "goals") document that, while
    ;    still limited to mobility at the IP level, would not be strictly
    ;    limited to MIP-based schemes (as the current LMM document is).
    ;    Another question is whether or not a thorough threats analysis
    ;    should be done by the working group, and if so, if this would
    ;    be captured in an existing document or in a new one.
    ;    This slot is aimed at discussing at least these questions, and
    ;    at finding WG direction in this respect.
    Gab: Current milestones go up to april, this should be a short-lived 
    working group, maybe end by July. Some people think that we should 
    recharter after that, but Vern Paxson is now about to start the 
    mobility research group (MOBOPTS), the charter is about done and the 
    mobility list will be created, so this is an alternative place to do 
    experimental work. Any comments from the floor?
    James:	Short working groups are GOOD. Gives sense of 
    accomplishment. It's fine to do the work shown on the slide in IRTF.
    Carl:		What about location privacy? This is something we might consider 
    doing here.
    James:	Advice against that - this is not an easy problem to solve. We've 
    done some work in NTTDoCoMo. Not sure it's even right for IRTF yet.
    Greg:		Not sure. There are some things that can be done.
    James:	Maybe a 1-page draft. But it would be a BCP, and maybe should be 
    done in the IRTF. It's a deployment issue, and until these things are 
    getting to be deployed, it's hard to get a grip on
    Greg:		Why tie it to HMIP? If your HA is close enough, it's nothing to do 
    with HMIP
    Eric Nejdjou:	Do we need to deny new workgroup items just to keep the 
    lifetime short?
    Gab:		If we want to keep to the milestones, I think the answer is yes.  We 
    can have the research group work for a while, and then maybe reopen 
    MIPSHOP to take on new stuff.
    Basavaraj:	Rechartering might be a worthwhile thing in a year or so. 
    Gab:		So new submissions would be individual submissions, and then when the 
    milestones are done, then we could reconsider the charter.
    Vijay:	Should complete current wg items and then come back to this issue in 
    the next IETF.
    James:	We can do as Basavaraj suggests, but I'll argue that we should shut 
    down at the next IETF too 
    Carl:		We're about to deploy MIPv6, till such a time Raj's comment about 
    reevaluating later is a good idea.
    Behcet:	DNA type of work falls into this wg, especially fast DAD. So I 
    would encourage extending this working group to include this, and work on 
    different link layers. Why generate a new group.
    Thomas:	We have homes for that work already, so do we need to	bring it over 
    here? The thing is, do we have real work that needs to be done? Then we 
    should do it. For instance location privacy, it would be nice to have it, 
    but it's pretty profound, and is it the most immediate problem? Better to 
    have some people work at it in the back room, and then when the work is 
    well baked, then form a working group to standardize it.
    Gab:		Ok, clear direction - till we finish the milestones, we won't 
    discuss other stuff, and after that we can get back to this question.
    ; Status of MIPSHOP WG I-Ds
    ; =========================
    ; 1. 
    ;    WG Last call
    ;         started:   oct 16
    ;         completed: oct 30
    ; 2. draft-ietf-mipshop-fast-mipv6-00.txt
    ;    WG Last call
    ;         started:         nov 3
    ;         to be completed: nov 24
    ; 3. draft-ietf-mipshop-hmipv6-00.txt
    ;    WG Last call
    ;         started:         nov 3
    ;         to be completed: nov 24


    MIPv6 Signaling and Handoff Optimization
    LMM Requirements LMM Requirements Document
    Fast Mobile IPv6 Handovers
    HMIPv6 - Last call comments