Subject: [mobile-ip] new text for Mobile IPv6 movement detection

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 19:16:04 -0700

Jari -

Here's my new improved version of the MD text:

Definitions added to Section 3.2:

    L2 handover - process by which the mobile node changes from one
    link-layer connection to the Internet to another. For example, a
    change of wireless access point is a L2 handover.

    L3 handover - subsequent to an L2 handover, a mobile node detects
    a change in an on-link subnet prefix that would require a
    change in primary care-of address. For example, a change of access
    router subsequent to a change of wireless access point typically
    results in a L3 handover.

11.5.1 Movement Detection

    For some wireless technologies and deployment scenarios, a L2
    handover may not always require a L3 handover, for example, if both
    the old link and the new link share the same access router and thus
    the same on-link prefixes. The primary goal of movement detection is
    to detect L3 handovers.

    This section does not attempt to specify a generic movement
    detection algorithm which will function optimally for all types of
    applications, link-layers and deployment scenarios; instead, for
    informational purposes it describes one method which uses the
    facilities of IPv6 Neighbor Discovery, including Router Discovery
    and Neighbor Unreachability Detection. This method is generally
    considered to be too slow, and therefore the mobile node SHOULD
    supplement it with other information whenever it is available to the
    mobile node (e.g., from lower protocol layers).  The description
    here is based on the conceptual model of the organization and data
    structures defined by Neighbor Discovery [12].

    When the mobile node detects a L3 handover, it performs Duplicate
    Address Detection [13] on its link-local address, Router Discovery
    to select a new default router, Prefix Discovery with that router
    to form new care-of address(es) as described in Section 11.5.2,
    and then it registers its new primary care-of address with its
    home agent as described in Section 11.7.1, and also updates the
    associated mobility bindings in correspondent nodes that it is
    performing route optimization with as specified in Section 11.7.2.
    Because of the additional protocol signalling overhead involved in
    the mobile node updating the home agent and correspondent nodes with
    its new care-of address, as well as the temporary interruption of
    network connectivity caused by the L3 handover process and the
    potential for dropped packets, generally L3 handovers should be
    avoided. Specifically, if the mobile node detects that the old
    default router on the old link is still bi-directionally reachable,
    it should generally continue to use that router rather than switch
    away from it to use a new default router.

    Mobile nodes can use the information in received Router
    Advertisements to detect L3 handovers. In doing so the mobile node
    needs to consider the following issues:

    o  There might be multiple routers on the same link thus hearing a
       new router does not necessarily constitute a L3 handover.

    o  When there are multiple routers on the same link they might
       advertise different prefixes.  Thus even hearing a new router
       with a new prefix might not be a reliable indication of a L3
       handover.

    o  The link-local addresses of routers are not globally unique,
       hence after completing a L3 handover the mobile node might
       continue to receive Router Advertisements with the same
       link-local source address.  This might be common if routers use
       the same link-local address on multiple interfaces.  This issue
       can easily be avoided when routers use the Router Address (R)
       bit, since that provides a global address of the router.

    In addition, the mobile node should consider the following events
    as indications that a L3 handover may have occurred:

    o  With some types of networks, notification that a L2 handover has
       occurred might be obtained from lower layer protocols or device
       driver software within the mobile node.  However, not all L2
       handovers result in L3 handovers. For example, movement of a
       mobile node from one cell to another in many wireless LANs can
       be made transparent to the IP level through use of a link-layer
       "roaming" protocol, as long as the different wireless LAN cells
       all operate as part of the same IP link with the same subnet
       prefix.  Therefore, link-layer indications do not guarantee that
       a L3 handover has occurred.

    o  If Router Advertisements that the mobile node receives include
       an Advertisement Interval option, the mobile node may use its
       Advertisement Interval field as an indication of the frequency
       with which it should expect to continue to receive future
       Advertisements from that router.  This field specifies the
       minimum rate (the maximum amount of time between successive
       Advertisements) that the mobile node should expect.  If this
       amount of time elapses without the mobile node receiving any
       Advertisement from this router, the mobile node can be sure that
       at least one Advertisement sent by the router has been lost.
       It is thus possible for the mobile node to implement its own
       policy for determining the number of Advertisements from its
       current default router it is willing to tolerate losing before
       it considers it likely that a L3 handover has occurred.

    Upon receiving such indications, the mobile needs to send Router
    Solicitations to discover routers and prefixes on the new link.

    Note that while the mobile node is on a link, it use normal IPv6
    mechanisms such as Neighbor Unreachability Detection [ref] to track
    reachability of the default router. However, such tracking is
    performed only when the mobile node has packets to send, and in the
    absence of frequent Router Advertisements or indications from the
    link-layer, the mobile node might become unaware of a L3 handover
    that occurred.

Thanks.
- Ed Remmell
Elmic Systems USA, Inc.

Best of Show Winner, ESC 2003
Click on the link and take a look!
http://cmp.iconvention.com/escshowdaily/v33/index.cvn?ID=10183

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 09 May 2003 15:52:13 +0200

>     change of wireless access point is a L2 handover.

For some reason I have a knee-jerk reaction against "Internet" in the
above. Perhaps it's that while defining an L2 event it seems unnecessary
to mention this non-link-layer construct called the Internet. Perhaps
it's that, heck, in spite of all the link-local rot,
maybe some folks will use this without necessarily being on the
internet (ok, I'll go wash my mouth with soap). Anyway,
it's not mentioned below for "L3 handover" so might as well
leave it out for L2 as well.

At any rate, would the above be much worse if we simply did?:
s/to the Internet to another/to another/

Also:

s/a L2/an L2/

>     results in a L3 handover.

Will we always effect a change at L2 immediately prior to an L3 change?
One could imagine with multiple L2 connections deciding for whatever
reason to suddenly switch it's L3 from one to another. Perhaps not
common, but this makes me think that we could soften the above a bit
by changing:

	subsequent to an L2 handover, a mobile node detects

to

	a mobile node detects

and this:
	subsequent to a change of wireless access point

to:

	(perhaps subsequent to a change of wireless access point)

Also:

s/a L3/an L3/

This applies to the text below as well.

>     and then it registers its new primary care-of address with it

How about splitting this sentence here, just to relax it a bit:

s/11.7.1, and also updates/11.7.1. Subsequently, it may update/

>     performing route optimization with as specified in Section 11.7.2.

"...correspondent nodes with which it is performing route optimization
(as specified in Section 11.7.2)."

>     away from it to use a new default router.

I think I saw some text from Greg on the mailing list which improved
upon the above.

>        at least one Advertisement sent by the router has been lost.

Ok.

>        it considers it likely that a L3 handover has occurred.

Presumably, the L3 handover is not detected, the L3 switch is.
MIPv6 specifies how the effect the L3 handover.

I'd reword this:

         Accordingly, the mobile node can dynamically set its own policy to
	determine how many
   	lost Advertisements from its
         current default router constitute an L3 handover.

>     link-layer, the mobile node might become unaware of a L3 handover

ok

-gabriel

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 08:33:22 -0700

Gabriel -

Thanks, I'll update the text accordingly and send it to the list.

- Ed

-----Original Message-----
From: gabriel montenegro [mailto:[email-masked]]
Sent: Friday, May 09, 2003 6:52 AM
To: Ed Remmell
Cc: Mobile-Ip; Jari Arkko
Subject: Re: [mobile-ip] new text for Mobile IPv6 movement detection

Also:

s/a L2/an L2/

to

	a mobile node detects

and this:

to:

Also:

s/a L3/an L3/

Ok.

I'd reword this:

ok

-gabriel

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 09:18:33 -0700

Gabriel -

>          current default router constitute an L3 handover.

This was actually the original wording, w/out my making any changes. How
about changing it to:

"The mobile node can then implement its own policy to determine how many
lost Advertisements from its current default router constitute a L3 handover
indication."

Thanks.
- Ed

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 09 May 2003 20:22:10 +0200

> lost Advertisements from its current default router constitute a L3 handover

Ooops, yes, I thought I had written down 'L3 handover switch' but the
above is better.

-gabriel

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 May 2003 22:49:22 +0300

Ed,

Thanks for the text! Some details below (but they may have been
taken care of already by others -- I'm responding mails in the
order I receive them...)

>     results in a L3 handover.

Somehow link-layer handover would sound better, the rest of the draft
talks about link-layer. Not sure about proper replacement of L3 handover,
however. "IP layer handover"?

>     considered to be too slow, and therefore the mobile node SHOULD

... considered to be relatively slow, and ...

Hmm... the truth appears to be more like that its quite reasonable when AI is small,
but a catastrophy if AI is large and there's no L2 assist?

>     Address Detection [13] on its link-local address, Router Discovery

This is an issue I had before, and couldn't quite figure out to
best explain it: first you get a hint, then you detect a L3 handover
(say, the reception of a previously unheard RA). At that point
there's no need to do RD, right? So I'm not sure we are always
doing RD after detecting a L3 handover.

>     network connectivity caused by the L3 handover process and the

Break this sentence in parts.

>     avoided. Specifically, if the mobile node detects that the old

Maybe "Thus, L3 handovers should be avoided unless they are
necessary."

>        can easily be avoided when routers use the Router Address (R)

s/easily//

>     link-layer, the mobile node might become unaware of a L3 handover

--Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 14:28:10 -0700

Jari -

> but a catastrophy if AI is large and there's no L2 assist?

Agreed. The NUD mechanism is too slow.

> doing RD after detecting a L3 handover.

There are other things that cause you to detect a L3 handover besides
receiving a new RA from a router you haven't heard of yet. In fact, the
method of "eager cell switching" that has been discussed recently (and that
apparently took control of the MD part of the spec recently ;-) is kind of
advanced, and even when it is well understood and specified likely won't be
implemented by all MNs. For example, using the RA AI to detect when you are
no longer reachable from your current default router - the MN can use that
to detect a L3 handover. In this case, it does need to send a RA to solicit
for new routers. So, I think the current text is fine.

> >        can easily be avoided when routers use the Router Address (R)

OK.

15 minutes or so, I should have a new version to post to the list. Provided
I don't get any new feedback in the meantime...

Thanks.
- Ed

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 May 2003 23:08:36 +0200

"When IKE version 1 is used with preshared secret authentication
   between the mobile node and the home agent, aggressive mode MUST be
   used. Similarly, the ID_IPV6_ADDR Identity Payload MUST NOT be used in
   IKEv1 phase 1. "
   
   I couldn't understand the second sentence.

=> the identity is used to look up the right preshared secret, IKE runs
over the care-of address and an address identity is supposed to match
the peer address hence:
 - main mode can't be used because it gives no choice for the key of
   preshared secret look up (it must be the address).
 - address IDs can't be used.

   IMO, it is very natural for
   MN to use its H@ as the ID payload in IKEv1 phase 1.

=> it is natural but IKE runs over the care-of address, not the home address.
Note that a proposed but not available solution is to add a new "home address"
identity type (and subject alternative name type in PKIX).

   It uses CO@ to negotiate with its Home Agent, it also uses its H@
   as the ID so that the HA can get the preshared key.

=> many implementations check the peer address (the address IKE runs over)
and the address ID (and an address subject alternate name with
signature based authentication) matches. This is the defense against
some attacks because IKE doesn't protect the peer addresses at all
(a known security flaw which should be fixed in IKEv2). Of course
it doesn't work with NAT traversal (which can be considered intrinsicly
insecure) or with an initiator using a dynamic address (a road warrior)
but fortunately other ID types can (should in these cases) be used.

   If ID_IPV6_ADDR ID MUST NOT be used, then the HA must think of a name
   (like in FQDN format) for each of its mobile nodes.

=> yes, each MN should use a name (FQDN or user_FQDN aka NAI) or
a keyID. What is the issue?
   
   Similarly, in draft mipv6haipsec pre 5, section 4.4
   
       " Note also that care needs to be taken with phase 1 identity
   selection. Where the ID_IPV6_ADDR Identity Payloads is used, unambiguous
   mapping of identities to keys is not possible. (The next version of IKE
   may not have these limitations.)"
   
   I couldn't see why it is not possible for unambiguous maping of
   identities to keys, given the ID payload is the HO@.
   
=> the problem is your assumption (the home address can be used in
the ID) is false...

Regards

[email-masked]

PS: note that in IKEv2 the ID should be a simple policy pointer and
the peer address should be protected, so the issue is very different...
And of course IKEv2 will support "legacy authentication" and should be
very close to current real world IKE deployment in mobile VPNs, IMHO
enough to be a dangerous competitor to mobile IPv6 without routing
optimization.

---

From: "Jimmy Zhang" <[email-masked]>
Date: Mon, 19 May 2003 10:34:58 -0700

Hi,

I have a question regarding IKE part. 

In Draft 21, section 5.1:

I couldn't understand the second sentence. IMO, it is very natural for
MN to use its H@ as the ID payload in IKEv1 phase 1. It uses CO@ to
negotiate with its Home Agent, it also uses its H@ as the ID so that the
HA can get the preshared key. If ID_IPV6_ADDR ID MUST NOT be used, then
the HA must think of a name (like in FQDN format) for each of its mobile
nodes, is that what we are going to do? I guess I miss something here.

Thanks,

Jimmy