Subject: [mobile-ip] Proposed resolution for issue #168

From: Charlie Perkins <[email-masked]>
Date: Mon, 02 Dec 2002 16:09:58 -0800

Hello folks,

After reading over this long issue several times, I think it is
reasonable to
resolve it by leaving things pretty much as they are.  The matter seems
to
depend on whether people believe multiple prefixes will be advertised on

a single link.  If not, then the 'L' bit philosophy does not buy much,
but
as pointed out then it's pretty simple to just not use it.  I didn't see
any
place where additional text was required.

I put just a few comments in the text of the issue, reproduced below.

Regards,
Charlie P.

=======================================================

Ed Remmell writes: 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.

======================== CEP comment ===================================

        This danger is unrelated to whether or not the 'L' bit is
        available.  A node could steal the addresses one way or
        the other.
=======================================================================

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.

===================== CEP comment
=========================================
        This is for one particular expectation.  As I understand it,
        the IPv6 specification was not written with the idea that all
        networks would conform to this expectation.  If that has
changed,
        then the savings would not typically be very impressive.
==========================================================================

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.

================= CEP comment
=============================================
        You are supposed to be able to use your link-local address
        for this.
==========================================================================

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.

================ CEP comment ==========================================
        These points are related to ways for minimizing reconnect
        time upon returning to the home network, and are not
        directly related to the 'L' bit.  This is true, because
        if another node is using the same link-local address, then
        the returning mobile is still equally hosed.
======================================================================

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.

------------------------------

Brian Haley responds to Ed Remmell: 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.

> 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.

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.

> #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.

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.

> 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?

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 Haley continues:

> 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.

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.

------------------------------

Ed Remmell responds to Brian Haley: No, I've not misunderstood, I
really truly only have a problem with the (L) bit ;-).

    -  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.

================ CEP comment ==========================================
        Problem: This is not good for DNS entries using the old IID
======================================================================

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.

> 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.

Good point.

------------------------------

> 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.

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.

> 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.

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.

> 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.

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.

------------------------------

Vladislav Yasevich writes: 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?

------------------------------

Ed Remmell responds to Brian Haley:

> 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.

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.

> 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.

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

------------------------------

Ed Remmell responds to Vladislav Yasevich: 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

------------------------------

Jari Arkko responds to Ed Remmell:

> 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

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?

------------------------------

Ed Remmell writes: 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. ;-)

------------------------------

------------------------------

------------------------------

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 2 Dec 2002 16:43:31 -0700

Charlie -

Short answer: yes, I agree, leave it as it is currently.

I've thought this over some since I originally posted it. It is true that MN
returning to home is a pain, and a few things which are normally
non-standard for IPv6 (i.e. temporarily disable DAD so you can successfully
auto-configure your link-local scope home address, send a DAD probe to
resolve the HA's MAC address rather than a regular NS, etc.) as well as some
other things which were unclear (i.e. make sure that the lifetime of the
MN's SAs with the HA is longer than the lifetimes of any bindings that the
MN has created in the HA) are done to make it work when the HA is defending
the set of addresses based on the MN's IID. I don't completely agree with
your statement that when you are using a globally unique IID, a node could
steal the addresses formed using that IID one way or the other, since the
IID is supposed to be globally unique after all - as I understand it, that
is the only type of IID that a MN is allowed to use with L=1 (the draft says
you must set L=0 if you are using a home address that was generated using a
random IID per RFC-3041).

Anyways, I wasn't able to weasel out of this extra complexity (I tried), so
I'm reconciled to implementing it per draft 19. On a somewhat unrelated
topic, I finally decided that using RFC-3041 to try other temporary random
IIDs if/when the MN fails to successfully auto-configure a link-local scope
address on a foreign network is a good idea, so I'm more in sync now with
the intent of the draft regarding stateless address auto-configuration on
home and foreign networks (including the return to home case).

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Charlie Perkins
> Sent: Monday, December 02, 2002 5:10 PM
> To: Mobile IP Working Group
> Subject: [mobile-ip] Proposed resolution for issue #168
>
>
> Hello folks,
>