Subject: [mobile-ip] question usefulness of (L) bit in BU, remove this?

From: "Ed Remmell" <[email-masked]>
Date: Mon, 18 Nov 2002 18:37:28 -0700

Hello,

I'm in the process of implementing Mobile IPv6 draft 19 MN functionality,
and I've decided that the (L) bit in the BU is more trouble than it is
worth. Here are the supposed benefits (as I understand them) of the (L)
Link-Local Address Compatibility bit:

1) The HA continues to defend your link-local scope home address while you
are away from home. There is a DAD optimization which allows a node to only
perform DAD for the link-local scope address formed using the interface ID.
If you are a MN who auto-configures home addresses using the interface ID,
but you don't have the HA defend your link-local address while you are away
from home, potentially another node on your home network could successfully
perform DAD on and auto-configure your link-local address on your home
network, skip DAD (per the optimization) on other auto-configured addresses,
and end up successfully auto-configuring all of your home addresses. No good
could come of that.

2) The (L) bit can reduce the number of BUs that the MN needs to send to the
HA, for registration of multiple home addresses auto-configured using the
same interface ID.

#1 probably isn't that valid, since as a MN visiting a foreign network, you
will likely power off frequently (otherwise you will drain all of your
battery power), and in many cases this can cause the bindings you have
established with the HA to time out, and the HA to stop defending those home
addresses (including your link-local scope home address). For your typical
battery-powered host, this will likely be true at least 50% of the time
(i.e. will you leave your cell phone on at night just so it can keep you
registered with the HA to defend your home addresses?). So, the protection
that the (L) bit provides you seems to be partial at best. Of course, if the
HA allows you to create bindings with infinite or very long lifetimes... but
then if I was the HA, my local policy wouldn't allow such long lifetimes ;-)

#2 isn't a real issue. At most, I'm expecting 2 home addresses (a global
scope home address, and possibly a site-local scope home address) that the
MN needs to register bindings for, and in most cases this will be just the
global scope home address. So, you don't really save on the number of BUs
that the MN needs to send by using the (L) bit.

Notably, there isn't the benefit of having the HA tunnel you all of your
application-related link-local scope traffic while simultaneously acting as
a proxy for your ND traffic, because the HA does not tunnel any link-local
scope traffic to the MN. That would be a benefit that I could understand
(i.e. if I could maintain link-local scope sessions after moving to a
foreign link that the MN established while it was at home).

If that were all there was to it, I might still consider using the (L) bit,
but I really don't like the fact that when I return home (which may not be
immediately determined), I can't use my link-local scope address (which,
since my interface ID probably hasn't changed, will be the same on my home
network as well as on any foreign link I visit) because the home agent will
be defending it (until I figure out that I'm at home, and can deregister).
So, just for simplicities sake (i.e. to make initial handover processing
subsequent to a possible move as consistent as possible, between the "return
to home" and "visit foreign link" cases), I don't want to use the (L) bit.

See section 11.5.4. Returning Home:
"In addition, when returning home prior to the expiration of a current
binding for its home address, and configuring its home address on its
network interface on its home link, the mobile node MUST NOT perform
Duplicate Address Detection on its own home address, in order to avoid
confusion or conflict with its home agent's use of the same address."

How am I going to (easily) implement this requirement if I think I've moved,
but I don't know yet if I've moved to a foreign link or back to home, and
the HA is defending my link-local scope home address? I plan on doing
optimized DAD on the link-local address very soon after sending out a Router
Solicitation on the new link - there are a couple of reasons I can think of
why it would be useful to be able to start using my link-local scope home
address as soon as possible in the exact same manner after I think I've
moved, regardless of whether I'm returning to home or visiting a foreign
link (since it may take a little time for me to discover which is which),
for example:

1) quickly rejoin all multicast groups that I was previously a member of on
the new link (this includes multicast groups that the user application may
have joined). This requires that the source address of my MLD Report
messages be link-local scope. Note that DAD does not have to have completed
(i.e. optimized DAD) for me to be able to do this, since there is no real
harm with temporarily joining a multicast group on a link if it turns out
that you can't operate on that link because DAD fails (the MLD multicast
group join will time out later anyways, if there are no other members of
that multicast group on that link). You need to join the solicited-node
multicast group anyways to perform DAD (yes, I know there is a new draft
that suggests using the unspecified address as the MLD source address in
this case, but I like using the tentative link-local scope address as the
source address for MLD while performing DAD on that tentative address and it
meets the original RFC-2710 requirements of using a link-local scope source
address).

2) after completing DAD on the link-local scope address, send a non-DAD
Neighbor Solicitation directly to the HA global scope address to see if I
have returned home. This is another way to detect whether or not I've
returned home, and it may complete faster than a RS/RA method (in any case,
it can't hurt to use both methods at the same time). If I determine that the
HA is directly reachable on the attached link, then I know that I've
returned home.

Plus, I need to auto-configure my link-local scope address as soon as
possible anyways, so that my user applications can resume using IPv6 on the
interface.

Recommended action? Well, I'm a big advocate for simplicity, especially in
the case of this specification which is already complex. So in this case,
since (to me, at least) there isn't any obvious advantage to having the (L)
bit in the BU, and since it does cause additional complexity (both for the
MN and for the HA), I'd recommend that it be removed.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Brian Haley <[email-masked]>
Date: Tue, 19 Nov 2002 10:57:48 -0500

Hi Ed,

> and end up successfully auto-configuring all of your home addresses. No good

I don't believe this is a problem specific to Mobile IPv6, it's
something you have to worry about when you start putting nodes on
your network that don't do DAD for all addresses, which IMHO is a
bad thing.

> HA, for registration of multiple home addresses auto-configured using the

I think you've mis-understood what the the L-bit signifies in the BU:

   Link-Local Address Compatibility (L)

     The Link-Local Address Compatibility (L) bit is set when the
     home address reported by the mobile node has the same interface
     identifier (IID) as the mobile node's link-local address.

It is not telling the HA to defend your link-local address,
that's what S=0 is for, it's set to allow the HA to derive all
your other addresses from your home address.

> that the MN needs to send by using the (L) bit.

We can't be so restrictive as to limit support for only 2 addresses,
others do have a need to support more than this, especially when
going through a site re-numbering.

> the HA is defending my link-local scope home address?

You'll know when you see an RA, right?  Maybe you're thinking about
using a link trigger (which has been discussed in other threads), but
that changing APs doesn't guarantee you're in another domain.

-Brian

---

From: Brian Haley <[email-masked]>
Date: Tue, 19 Nov 2002 14:11:24 -0500

> your other addresses from your home address.

Sorry, my mistake on this, S=1 L=1 will have the HA defend
your link-local.

But the major point is that without the L-bit, S=0 is not
implementable.

-Brian

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 19 Nov 2002 11:49:22 -0700

Brian -

> your network that don't do DAD for all addresses, which IMHO is a

What is interesting is there appears to be some discussion lately about
whether or not IPv6 DAD is even that useful. Anyways, that's not what I'm
questioning here.

> your other addresses from your home address.

No, I've not misunderstood, I really truly only have a problem with the (L)
bit ;-).

>From draft 19:
    -  L=1 and S=0:  Defend all non link-local unicast addresses
       possible on link and the derived link-local.

    -  L=1 and S=1:  Defend both the given non link-local unicast (home)
       address and the derived link-local.

My problem is having the HA defend the derived link-local scope IPv6
address, which occurs when the (L) bit is set irregardless of the setting of
the (S) bit. The main reason why I think this is a problem is it creates a
special case, specifically that of returning home without necessarily
knowing that you've returned home and then not being able to immediately use
your auto-configured link-local scope IPv6 address because you have to first
detect that you've returned home before you can deregister that address with
the HA to be able to use it. If there was a big advantage to adding this
extra complexity, then I could buy into that, however I don't see any real
advantage.

I received some feedback (not posted to this list) that XX wireless may want
the (L) bit functionality, I guess the scenario is the following (I may have
misunderstood the specifics):

You have the network broadcast multiple global prefixes to a wireless
handset. The wireless handset has an (unique to the cellular network)
interface ID configured in it that it uses to statless auto-configure
multiple global home addresses. Each of these global home addresses can then
be assigned to a single device, which is either the wireless handset, or
else is a device attached to the wireless handset for which the wireless
handset is providing IPv6 Internet access. In this case, you can set L=1 and
S=0 in the BU to cause the MN to only have to send a single BU when
registering multiple global home addresses.

However, there are at least two alternatives to this scenario:

1) Change the specification to allow S=0 when L=0 to mean that you are
registering multiple addresses (not including the link-local scope address),
each auto-configured using the low-order 64 bits of the supplied home
address as the interface ID. Currently, the (S) bit is ignored in this case,
since when L=0, you can currently only register a single address. Even with
making this other change, I still think that the (L) bit should be removed.
Look at it this way: you (the MN) will probably reregister periodically with
the HA anyways, to keep your bindings current (see the Binding Refresh
Advice option). If some other node on your home network has grabbed one of
your global home addresses for its own use (i.e. because it optimizes DAD),
you will know soon enough when your reregistration attempt fails (assuming
that you have the HA perform DAD for you). Even better, when the HA detects
that another node on your home network is attempting to use your global home
address, it could send a Binding Refresh Request message to the MN to ask it
to reregister that home address, and then subsequently fail that
reregistration request - of course, that assume that the HA is permitted to
send the Binding Refresh Request, which isn't mentioned in the
specification.

2) Have the network broadcast a single unique 64-bit prefix to the wireless
handset, entirely for its own use. The handset can then assign as many
unique home addresses as it needs to, using this prefix. However, the
handset will still need to register each of these addresses individually
with the HA.

Interestingly enough, one possible solution that was suggested to me is that
you just never allow the MN to return home, i.e. it is always visiting a
foreign network. That solves my problem with the (L) bit, but unfortunately
it isn't a general solution for Mobile IPv6, it is specific to a particular
network implementation.

> going through a site re-numbering.

Good point.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Brian Haley <[email-masked]>
Date: Tue, 19 Nov 2002 15:22:13 -0500

> extra complexity, then I could buy into that, however I don't see any real

Shouldn't you wait until you know where you moved before starting
to configure/use addresses?  I believe the Mipv6 draft says that
a MN determines its current link by looking at RAs.

> send the Binding Refresh Request, which isn't mentioned in the

I will agree that there are a lot of potentially strange cases where
two MNs with the same IID can "fragment" the home-link address space.
I think having the L-bit will help alleviate this, but we're treading
close to a network administration problem, don't you think?  Operators
should not put two devices with the same IID on the same IPv6 link.

> handset will still need to register each of these addresses individually

There's always DHCPv6 :)

Are you here at the IETF?  Maybe anyone interested could have a short
discussion about this before/after the meeting tonight.

-Brian

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 19 Nov 2002 15:48:44 -0500

Ed

In the previous incarnations of this discussion it was stated
that the HA should always defend the link-local address
(time to dig through the archives :)

Since it is not a good idea of the HA to always assume a
64 bit IID, the 'L' bit was introduced assuring that it's
OK.

Before the 'L' was defined, this was all originally munged into
the 'S' bit definition and the 'S' bit behavior was weird.

This is just some history... see issues 23 and 39.

So, what you are asking for is to remove the restriction that
the HA must always defend the link-local address... or am I missing
you point?

-vlad

Ed Remmell wrote:
>>>2) The (L) bit can reduce the number of BUs that the MN needs
>>
>>to send to the
>>
>>>HA, for registration of multiple home addresses auto-configured
>>
>>using the
>>
>>>same interface ID.
>>
>>>scope home address, and possibly a site-local scope home
>>
>>address) that the
>>
>>>MN needs to register bindings for, and in most cases this will
>>
>>be just the
>>
>>>global scope home address. So, you don't really save on the
>>
>>number of BUs
>>

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 19 Nov 2002 13:05:32 -0700

Brian -

> a MN determines its current link by looking at RAs.

We do a form of optimistic DAD on the auto-configured link-local scope
address. The interface ID typically does not change. So, the same link-local
scope address is auto-configured regardless of whether we move to a foreign
network or back to the home network. At least that was the plan. The (L) bit
kind of introduces a kink in that plan.

We want to minimize handover latency, without resorting to trying to
implement some of the drafts for that purpose (since a lot of work is still
going on in that area, and we want to try to have a relatively stable
initial implementation of MIPv6 MN/CN functionality). So, doing as much in
parallel (after detecting the possible move) is preferable. Sometimes we may
be notified of a possible move via the equivalent of a L2 trigger.
Auto-configuring the link-local scope IPv6 address on the mobile interface
immediately after we've sent the initial RS (after detection or notification
of a possible move) enables us to do other things in parallel. We can
usually complete DAD, for example, on that link-local scope address, before
we start auto-configuring other addresses. Also, I'd like to as soon as
possible to rejoin all multicast groups that the MN had previously been
joined to on the foreign link (or is it the home network? we don't know
yet), that should be done in parallel if possible (RFC-2710 requires MLD
Report messages to be sent with a link-local scope source IPv6 address, we
would use the tentative link-local address for that purpose). If I have to
design my implementation to also detect the special case of moving back to
the home network and the HA defending my link-local scope address, it will
probably increase handover latency slightly (which I'd like to avoid) and
more importantly it makes my implementation more complex to handle this
special case. Reducing complexity is much appreciated, because our
implementation is specifically for embedded systems, and we need to reduce
the amount of code as much as possible.

> should not put two devices with the same IID on the same IPv6 link.

I completely agree (for the non-RFC3041 case).

> discussion about this before/after the meeting tonight.

Sorry, I'll have to pass, I'm chained to a desk currently. ;-)

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 19 Nov 2002 13:11:28 -0700

Vlad -

Exactly, I don't want the HA to defend my link-local scope address. That is
the special case that I'm trying to avoid in my MN move detection/move
handling code.

I am doing a MN implementation, so I'd like this to behave consistently for
all HA implementations that my MN might interoperate with, i.e. the
specification should state that the HA never defends the MN's link-local
scope address even if the MN sends a BU with L=1.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: Vladislav Yasevich [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2002 1:49 PM
> To: Ed Remmell
> Cc: Brian Haley; Mobile IPv6 mailling list
> Subject: Re: [mobile-ip] question usefulness of (L) bit in BU, remove
> this?
>
>
> Ed
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Nov 2002 19:28:09 +0200

> probably increase handover latency slightly (which I'd like to avoid) and

If you are concerned about this, how about having your implementation set
S=1 in which case the HA will only defend your proper home address?

I assigned issue #168 for this.

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 21 Nov 2002 12:28:36 -0700

Jari -

But then I miss out on the benefits of being able to reduce the number of
BUs that I have to send, what I'd really like is either having the HA never
defend my link-local scope address generated from my IID or being able to do
the equivalent of S=0 L=0 (the IID in this case would be the low-order
64-bits of the home address I register in that BU - the specification
currently says that when L=0, the HA cannot determine the IID, but it could
determine it the same way as when L=1 just not defend the derived link-local
scope address in that case).

It is OK if the HA does DAD when I ask it to (although I've seen recently a
suggesting for removing the (D) bit, so I guess that will go away) on the
link-local scope address generated from the IID in this case, the problem I
have is with the HA defending my link-local scope address while my binding
is registered - when I return home, I would like to be able to immediately
stateless auto-configure my same link-local scope address (I'm assuming the
scenario where my IID never changes, so I use the same link-local scope
address on home and foreign links), and not have to worry about if I'm
returning home or instead moving to a different foreign link (or perhaps I'm
being confused about having moved, and in fact returning to the same link),
i.e. I do not want to have to treat the case of returning home with the HA
defending my link-local scope address as a special case.

I've said in previous emails why I'd like to auto-configure the same
link-local scope address each time after a move, and doing it in parallel
with the RS/RA process just allows me to minimize handover latency a little.
Probably the bigger benefit for me is I wouldn't have to add special code to
handle DAD failure on the auto-configured link-local address as being a
"soft failure" that indicates that possibly I've returned home and my HA is
defending that address and I just need to deregister my bindings with the HA
and try again, since I'm doing a generic embedded systems implementation and
every byte of code space (ROM usage) counts so minimizing special cases and
minimizing complexity is generally key. Normally, I treat DAD failure to
configure a link-local scope address on the interface as a hard failure, and
then disable the interface for use with IPv6 in that case.

Anyways, I've kind of given up on arguing about this issue, and I'm just
going to assume no changes in the spec and that I'll have to work around it
(I'm not planning on adding extra code to handle this special case, I'm
either leaving it up to the user to handle by either never registering with
S=0 L=1, else they never returning home, else they disable the use of DAD on
the MN, else ???). I've provided all of the information in previous emails.
As I said in a previous email, if the link-local scope application traffic
from the home network was being forwarded to the MN by the HA via a tunnel
(which doesn't happen), then it would make sense for a binding for the MN's
link-local scope address to exist in the HA and for the HA to defend it, but
since this does not happen, the only reason to have this extra functionality
is for compatibility with that stateless address auto-configuration
requirement which says that nodes can optimize DAD by only performing DAD on
the link-local address auto-configured using the IID, and really I'm not
convinced that that "benefit" compensates for the extra hassle that MNs need
to deal with when they return home and the HA is defending their link-local
scope address and they may not know yet that they've returned home and may
want to use that address (or worse, they may assume that DAD failed for
their link-local scope address and go disable the entire IPv6 interface).
Here's a scenario you'all might understand better:

1) MN is operating on foreign link. MN auto-configures the link-local scope
address based on the IID, registers bindings, etc.

2) MN is powered off while its bindings are still active. Assume its
bindings have an "infinite" or relatively long lifetime in the HA. Because
of the current intent of L=1 S=0 to have the HA defend your complete set of
home addresses (including the link-local scope address) auto-configured
using the IID, so that other nodes can't accidently use them, I think it is
fairly reasonable to assume "infinite" or relatively long lifetimes for
these bindings in the HA.

3) MN returns home and is powered up on the home network. MN does not know
that the HA is still maintaining active bindings for its home addresses,
i.e. MN does not maintain this state in NVRAM (I suspect that many embedded
systems MN implementations will function this way).

4) MN attempts to stateless auto-configure its same link-local scope address
based on the IID that it always uses. DAD fails because the HA is still
defending that address. MN disables the entire IPv6 interface and refuses to
operate ;-). Hopefully, the user application on the MN is smart enough to
detect this fact and manually configure a different IID and try again (if
the stack APIs support that), but if that happens, now the home addresses
have changed with that different IID, which is not a good thing either
(Mobile IPv6 is supposed to let you keep your same home addresses). It is
possible that MN functionality is "switchable", and that in this case when
the MN powers up on the home network it is no longer functioning as a MN,
but instead just as a regular IPv6 host node, so it wouldn't be smart enough
to deregister its bindings with the HA in that case. Tough luck, I guess -
don't ask for infinite lifetimes on your bindings next time. This particular
scenario will cause problems with other home addresses, if the MN doesn't
know to deregister them. At least, if I could auto-configure my link-local
scope in this case, I'd be able to enable the interface to use with IPv6,
and then manually configure other addresses (or perhaps auto-configure a
site-local scope address that I hadn't registered as a home address before).
But, yeah generally this is a bummer.

Of course, one easy solution is to never allow the MN to return home. ;-)

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 10:28 AM
> To: Ed Remmell

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 25 Nov 2002 08:58:14 -0700

Jari -

Please consider the following scenario, which involves interaction with
IPsec:
1) MN registers its set of home addresses (based on IID) when on a foreign
network by sending a BU with L=1 S=0. MN specifies an infinite binding
lifetime in the BU. HA allows that infinite lifetime.

2) MN returns home. MN must deregister with the HA, but first MN must
establish IPsec SAs with the HA, since the BU must be authenticated by the
HA. How is this possible, if MN cannot use any of its home addresses?

If MN could use its link-local scope home address (based on IID) to perform
the IKE exchange with the HA when on its home network, then (I expect that)
MN could establish the IPsec SAs needed to deregister its home addresses
with the HA. But, MN cannot use that link-local address in the case, because
the HA is busy defending it.

What should the MN do in this case? Should the MN use RFC-3041 to
auto-configure a temporary link-local scope address based on a different
IID, for the purpose of performing IKE? The HA won't recognize the source
address as identifying the MN in this case, so the MN must include the
ISAKMP Signature or Certificate payload in the IKE exchange so that the HA
can authenticate the MN. Will this work? It is very complex.

I still think it is simpler if you never permit the HA to defend the MN's
link-local scope home address (based on IID). What you could also do is have
the HA, when it detects that another node on the home network is using the
MN's link-local scope home address, automatically deregister the MN's
bindings. The other node on the home network is probably the MN returning to
home, in this case, so you are making it easier for the MN to return to home
(since its bindings will be auto-deregistered once the HA detects that the
MN is operating on its home network once again). You could argue that this
opens up the potential for other types of DoS attacks, but I'm not sure that
is a real issue, since the communication is done on the home link
(link-local traffic cannot go through a router), so the DoS attack would
only be possible if the node initiating the attack is attached to the home
link. I really like this solution, if you agree let me know and I'll work on
some specific text changes.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Thursday, November 21, 2002 12:29 PM
> To: Jari Arkko
> Subject: RE: [mobile-ip] question usefulness of (L) bit in BU, remove
> this?
>
>
> Jari -
>

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 25 Nov 2002 17:31:19 -0700

Jari -

Proposed new text to fix this issue (this could be added to section 10.3.1):
"The HA MUST NOT defend the link-local scope address formed from a globally
unique interface ID (i.e. based on a globally unique IEEE EUI-64) that a MN
registers with the Link-Local Address Compatibility (L) bit set.
Consequently, the HA MUST NOT optimize (and thereby skip) Duplication
Address Detection for the other MN home addresses formed from this interface
ID."

I found a couple of places in the specification which need to be changed to
indicate that the link-local address formed from the IID MUST be tested
using Duplicate Address Detection upon registration when the (L) bit is set,
but MUST NOT be defended:

section 10.3.1. Primary Care-of Address Registration:

old text:
"    -  L=1 and S=0:  Defend all non link-local unicast addresses
       possible on link and the derived link-local.

    -  L=1 and S=1:  Defend both the given non link-local unicast (home)
       address and the derived link-local."

change to:
"    -  L=1 and S=0:  Defend all non link-local unicast addresses
       possible on link and test (i.e. perform Duplicate Address Detection)
       but do not defend the derived link-local.

    -  L=1 and S=1:  Defend the given non link-local unicast (home) address
       and test but do not defend the derived link-local."

section 10.4.1. Intercepting Packets for a Mobile Node:
old text:
"Specifically, the home agent performs the following steps:

    1. The home agent examines the value of the Single Address Only (S)
       bit in the received Binding Update. ...
       For this purpose, the set of on-link prefixes includes
       both the link-local and site-local prefix."

change to:
"Specifically, the home agent performs the following steps:

    1. The home agent examines the value of the Single Address Only (S)
       bit in the received Binding Update. ...
       For this purpose, the set of on-link prefixes includes
       the site-local prefix but not the link-local prefix."

section 10.3.1. Primary Care-of Address Registration:
There is a reference here to "the link-local address associated with the
home address in this binding", but this appears to be fixed by the changes
for issue #159.

--------------
Justification:

There are two reasons why this change is necessary, assuming that when the
MN returns home the HA may be maintaining a S=0 L=1 binding for its
interface ID with an infinite (or even a very long - i.e. 2 to 3 days)
lifetime:

1) there is currently too much latency associated with the MN returning
home. If the MN could immediately auto-configure the same link-local scope
address that it normally uses at home (based on its globally unique IID),
then that would alleviate this somewhat.

2) if the MN cannot obtain a home address because the HA is defending all of
its home addresses, this makes it very difficult   for the MN to use IKE to
establish the needed SAs with the HA to be able to deregister its bindings
with the HA.

Also, there is no real benefit associated with having the HA maintain a
binding for the MNs link-local scope home address, since the HA never
tunnels any link-local scope traffic to the MN when the MN is visiting a
foreign link.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Nov 2002 18:55:28 -0800

> establish the needed SAs with the HA to be able to deregister its bindings

(2) may not be valid. IMO, the lifetime for the binding cache entry
shouldnt be more than the lifetime of the security association with
which the binding cache entry was created. ofcourse this is not
explicitly said anywhere in the MIPv6 spec. maybe we should.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 26 Nov 2002 08:07:38 -0700

Vijay -

So, you are suggesting that the MN does not need to use IKE when it returns
home with active bindings, since it still has an active security association
with the same HA that it originally registered with in that case. I like
this idea. I agree that it should be documented in section 11.5.4. Returning
Home. This mandates the need for the MN to maintain this kind of state
information in NVRAM; in general, you shouldn't be assuming that the MN
maintains any state information in NVRAM, but in the case of MN returning
home when it has active bindings it seems unavoidable.

I feel pretty strongly about this issue overall, as a MN implementor. The
only benefit (that I can see) to L=1 current behavior of including the MN's
link-local scope address in the set of MN home addresses that the HA
maintains bindings for is that it allows the HA to optimize DAD; i.e. the HA
could then only do DAD for the MN's link-local address formed from the
interface ID (as I understand it), skipping DAD on other MN home addresses
formed using the same interface ID. The HA doesn't really function as a
proxy for that home address, in this case, since it never forwards any
link-local traffic to the MN when the MN is on a foreign network. So, really
this just benefits the HA, and the benefit isn't that significant.

IMHO L=1 creates a major headache for the MN when it returns home, because
then the MN doesn't have a single home address based on its interface ID
that it can use on its home network (at least not without first going
through the complex contortions required to deregister), if it still has an
active registration that it created with L=1. As a MN implementor, I want to
be able to always stateless auto-configure the same link-local address based
on my globally unique interface ID, regardless of what link I'm operating on
(i.e. foreign and home links should all work equally well). L=1 adds a
special case that isn't necessary.

We need to be making things easier for the MN. As it is, MN return to home
functionality is very complex. Please let's sacrifice the potential for
optimizing DAD on the HA (which really isn't a big deal) in the case of L=1
to instead allow the MN to successfully auto-configure its link-local
address based on the interface ID regardless of what network it is operating
on and regardless of its current registration status.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Vijay Devarapalli
> Sent: Monday, November 25, 2002 7:55 PM
> To: Ed Remmell
> Cc: Jari Arkko; Brian Haley; Mobile IPv6 mailling list
> Subject: Re: text for: [mobile-ip] question usefulness of (L) bit in BU,
> remove this?
>
>
> Ed Remmell wrote:
> >