Subject: [mobile-ip] Mipv6 issue #179: Prefix distribution and DHAAD problems

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Dec 2002 17:19:35 +0200

I'll deal with the different parts of this issue below:

1) The first problem is that when renumbering takes place
    and the lifetime of a specific prefix goes towards 0,
    this will create an undesireable shortening of
    binding lifetimes. Charlie suggested we ignore lifetimes
    less than two hours for this purpose. I don't know,
    I don't feel quite comfortable with the home agent
    exceeding the lifetimes of the prefixes. What else
    can we do?

    Perhaps a better approach is to suggest that the
    mobile node use S=1 when it knows that the lifetimes
    of some prefixes are quite short. Suggested text
    to Section 11.4.2: "It is RECOMMENDED that when
    the mobile node has multiple home prefixes and their
    valid lifetimes differ substantially, the mobile node
    should separate Binding Updates for each implied
    home address. Otherwise, a binding registered with
    Single Address Only (S) bit equal to zero may get
    a very short lifetime."

2) "Addresses not served by the home agent should not be
    autoconfigred". I agree that this text should be removed,
    the MN does not learn of other addresses.

3) Cross-checking information from different routers.
    I agree with Charlie here: we can't do much more
    unless IPv6 WG specifies how routers can ensure
    consistent information.

    I'm also hoping that SEND RD part will fix this
    issue later on. Router A will ensure that an RA
    it receives is valid and authorized by running SEND.

4) Overriding AdvPrefixList information by RAs from other
    routers. I agree, this should be fixed. Charlie's text
    "unless the update would override existing information
    from this home agent" is fine.

5) Same for overriding L bit information. Text: "unless
    the setting of the L bit was already configured in
    this home agent"

6) MAY vs. SHOULD for sending MPAs when new prefixes
    appear: I think we already have a scheme for not
    sending the information all in one go; so I believe
    a SHOULD is fine for initiating the transfer.
    Text change "MAY:" => "SHOULD:".

7) The micro-optimization (omitting the replying agent):
    As a part of dealing with other issues in DHAAD, the
    optimization has become imho too complex and I'm
    suggesting we get rid of it. See issue #160.

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 16 Dec 2002 12:00:32 -0700

Jari -

>     Single Address Only (S) bit equal to zero may get

There is the valid lifetime, and the preferred lifetime. In this case (i.e.
subnet renumbering), the MN is doing DHAAD, it will discover (at least) 2
home prefixes: a deprecated prefix, and a preferred prefix. Its source
address selection algorithm should have it picking the home address formed
from the preferred prefix over the deprecated prefix to use as a (home)
source address on a foreign link. So, I don't see how this is much different
from the case when the MN is operating at home, and the subnet renumbering
takes place (although there is the added complexity of the fact that when
the MN is away from home, the HA address it was using will likely change due
to the subnet renumbering).

In any case, let's not add additional and/or complex functionality to the MN
if we can help it, it isn't a powerful (Unix) server. On the other hand, the
HA is. I'd rather keep it simple and have the MN either always set (S)=1, or
conversely set (S)=0 and (L)=1 (two valid options, but IMHO only one method
is needed/used by a given MN, and it should be used consistently). What you
are suggesting is that the MN make the decision of whether to use (S)=1 or
(S)=0 based on some dynamic information (in this case, prefix lifetimes) -
which adds extra decision logic to the MN, something I want to avoid. Plus,
there is the potential for confusion if/when the prefix lifetimes change
dynamically causing the condition being evaluated on the MN to change from
false to true:

1) the MN registers first with (S)=0, because the prefix valid lifetimes do
not differ substantially.

2) later, the MN discovers that the prefix lifetimes have changed so that
now they differ substantially, and then per the recommendation above, the MN
should reregister the same home addresses but with (S)=1 this time - if the
(S)=0 bindings are already active in the HA, will the HA allow it to change
its registration to (S)=1 without first deregistering? IMHO the MN should
not have to deregister anything in this case, that is too complex. So,
better if the MN just leaves its (S)=0 registration alone.

>     suggesting we get rid of it. See issue #160.

This would be nice. I assume that if you make this change on the HA side,
then the MN also doesn't need to implement the complex functionality to
check to see if the source address is in the HA list, and if not to give it
the highest preference. Please refer to (rejected) issue #165:
http://www.piuha.net./~jarkko/publications/mipv6/issues/issue165.txt

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Dec 2002 00:40:58 +0200

> better if the MN just leaves its (S)=0 registration alone.

I see your problem, but do you have a suggestion on what to do? As I
see it, we have the following options:

- Do nothing. There will about one additional BU per mobile node per
   expiring prefix so its not too much. The trouble is, from the HA's
   point of view they all arrive at the same time.

- If the prefix expiration is imminent, go to S=1 to avoid trouble
   for the more stable prefixes.

- Do not reduce binding lifetimes based on very short prefix lifetimes.

- Something else, what?

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 16 Dec 2002 16:00:25 -0700

Jari -

> see it, we have the following options:
<snip>
> - Something else, what?

I think there is a little misunderstanding about what is going on with (S)=0
(L)=1 BUs. IMHO, the (S)=0 (L)=1 BU is potentially ALWAYS valid, regardless
of any prefix lifetime. For example, the link-local scope home address of
the MN formed from the interface ID in such a BU never expires, it has an
infinite valid lifetime (or, at least a lifetime constrained solely by the
lifetime negotiated in the BU). So, the lifetime of such a registration
(which I understand as the MN registering a globally unique interface ID,
completely independent of the results of Home Prefix Discovery) should be
independent of any prefix lifetimes associated with the home link. At least
that's how I see it. Now, granted that if there are no prefixes advertised
to the MN, this type of registration is fairly useless, since link-local
scope traffic cannot be tunneled to the MN by the HA (so, the only purpose
of the HA defending the MN's link-local scope address is just to reserve it
for when there actually are prefixes available to auto-configure). But then
in the case of the subnet renumbering scenario, this shouldn't be the case -
there should be a new valid and preferred prefix advertised to the MN.

>     -  However, if the Single Address Only (S) bit field in the Binding
>        Update is zero, the lifetime for that Binding Cache entry MUST
>        NOT be greater than the minimum remaining valid lifetime for all
>        subnet prefixes on the mobile node's home link.  If the value of
>        the Lifetime field specified by the mobile node in its Binding
>        Update is greater than this prefix lifetime, the home agent MUST
>        decrease the binding lifetime to less than or equal to the prefix
>        valid lifetime.

This is wrong, I think. Per my comments above, I think the lifetime
negotiated by the MN and the HA for this type of (S)=0 (L)=1 registration
should be completely independent of the lifetime of prefixes used on the
home link. So, then the lifetime for this type of registration could be
infinite, even though there is a home prefix due to be invalidated. That
does not seem like a problem to me, since no specific address is being
registered in this case, the interface ID is being registered.

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

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 16 Dec 2002 16:57:19 -0700

> of any prefix lifetime.

I meant to say not that the BU message itself is ALWAYS valid, but that the
binding lifetime associated with such a BU in the home agent could be
infinite then the binding would be (in that case) always valid. This binding
lifetime should be independent of the lifetimes of prefixes advertised on
the home link in the case of (S)=0 (L)=1, that was my point. My example was
based on the fact that the link-local scope prefix has an infinite lifetime.
Since one of the home addresses associated with this binding is link-local
scope, then why shouldn't the binding also have a similar lifetime (or the
negotiated lifetime, whichever is less). IMHO, this type of binding is valid
as long as there is at least 1 MN home address associated with it - there
will always be the link-local scope home address associated with it for this
type of binding (the HA defends that address), so it can stay valid
indefinitely.

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

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 17 Dec 2002 10:35:17 -0500

Ed

> registered in this case, the interface ID is being registered.

I am not sure this is quite right.  A binding associates a primary HoA
with a primary CoA.  If the prefix for the registered primary HoA happend
to become deprecated, the MN should do something about this...  changing
the primary HoA sounds like the right thing.

Now, if the prefix for a non-primary HoA becomes depricated, there is really
no action to be taken if S=0 was used.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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, 17 Dec 2002 08:39:17 -0700

Vlad -

I see your point, I'll make sure I implement it this way in my MN design,
provided that something isn't changed (i.e. on the HA) to simplify MN
processing in this scenario. I wish there wasn't this extra
wrinkle/complexity - IMHO the HA shouldn't care about the specific primary
HoA chosen by the MN to do the (S)=0 (L)=1 registration... it really only
needs to know about the interface ID part of that address for this type of
registration.

Perhaps the way it is implemented in the HA, it makes sense to refer to it
as a primary HOA, specifically the home address that the MN specifies in the
BU when it registers with (S)=0 (L)=1. However, the way the MN sees it and
uses it, the actual home address that it specifies in the BU in this case
DOES NOT MATTER, only the low-order 64 bits (the interface ID) of that
address matter.

On the MN side, it is (or should be) very simple actually:

1) the MN discovers home prefixes using DHAAD, and forms home addresses from
these prefixes using a globally unique interface ID. This is one method of
configuring home addresses, and the (S)=0 (L)=1 type of BU supports it quite
well. Of course, part of discovering home prefixes is also discovering their
valid and preferred lifetimes, but that part is identical to normal IPv6
Prefix Discovery processing.

2) the MN discovers CoA prefixes from the current IPv6 default router on the
foreign link it is currently attached to, and uses those to auto-configure
CoAs.

3) the MN picks a primary CoA from the set of CoAs it discovered in step #2.

4) the MN registers its globally unique interface ID with the HA specifying
(S)=0 (L)=1, specifying any of the home addresses it formed from this
interface ID in step #1, and associating that interface ID with the primary
CoA selected in step #3.

In my current MN design, I'm giving the user application a callback when a
new home address is configured, and a different callback when a new CoA is
configured (which they can select to be a new primary CoA). Then, the user
application is responsible for creating the mobility bindings. The only
place where the preferred/deprecated status of a prefix comes into play is
source address selection. Of course, when the prefix is invalidated, all
home addresses sharing that prefix are unconfigured.

Regarding the extra wrinkle you mention about the primary HoA becoming
deprecated/invalidated, and the MN needing to create a new binding with
(S)=0 (L)=1 specifying a new primary HoA (formed from the same IID as the
invalidated one), I can make this work with my current design by being
smarter internally (i.e. below the level of the user APIs) to manage the
(S)=0 (L)=1 binding with the HA such that it is kept current, i.e. always
make sure that it is using a valid and preferred HoA if one is available
with the IID that the user application specified when it created the
mobility binding. That doesn't seem like too big a deal, if it simplifies HA
processing for the MN to continue paying attention to the specific HoA
registered (and not just the IID part) in this case I can live with that.

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

> -----Original Message-----
> From: Vladislav Yasevich [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2002 8:35 AM
> To: Ed Remmell
> Cc: Jari Arkko; Mobile IPv6 mailling list; Thomas Narten; Charles E.
> Perkins
> Subject: Re: [mobile-ip] Mipv6 issue #179: Prefix distribution and DHAAD
> problems
>
>
> Ed
>
> Ed Remmell wrote:
> >

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Dec 2002 13:43:48 +0200

I do agree about the 'theoretical' infinite
lifetime for the link local address.

However, we do not currently have the concept of
a primary home address. The purpose of the S=0
registration is to register multiple home addresses
similarly, and imho these addresses are equal, even
if just one of them appears in the packet.

Also, I still feel strongly that bindings must not
exceed the lifetime of the related prefixes. Mobile
nodes must know about the prefix lifetimes (unless
simply configured with a static home address) and
act accordingly.

One of the problems with S=0 is that the BA will only
return information regarding the whole set of addresses.
This information includes the lifetime, and there are no
mechanisms currently to convey different lifetimes to the
mobile node when S=0 is used.

Let me argue why we must have the returned lifetime be the
minimum of the lifetimes of registered in S=0. If we assume
we return a max or the "primary" home address' hoa1 lifetime
then it becomes possible that the mn and the ha do not
agree about the lifetime for some non-primary home address hoa2.
For instance, the prefix lifetime has recently changed and
the mn in question hasn't yet got the information since other
mns are being informed first. Then it can happen that the hoa2
is used by the mn even beyond the lifetime of the prefix. This
is not desireable.

What can we do then? The initial problem that caused this
discussion was that when the lifetime of an expiring prefix
approaches zero, all S=0 mobile node's bindings will expire
at the same time. This cause the HA to get a lot of BUs at
the same time.

The first proposal I had (use S=1) solves this problem as
the independent bindings for other addresses do not have to
be reissued at the time one binding expires. However, I
also see that this causes a lot of implementation hassle
for the MNs, particularly if they have to switch back and
forth.

What else can we do? Can we randomize lifetimes when they
are sent to MNs? I don't know. Perhaps we could randomize
the valid lifetime within the range of preferred lifetime ...
original valid lifetime. The effect of this would be that
BUs don't arrive at the same time.

Any other ideas?

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 18 Dec 2002 09:22:28 -0700

Jari -

First, I think I now understand what part you feel is difficult about this -
specifically, how the (S)=0 registration is actually implemented in the HA
as the equivalent of separate (S)=1 bindings, one for each home address
formed from the associated interface ID. Then, each of those bindings has an
associated lifetime, which is associated with the prefix of the home address
stored in the binding.

This is an implementation detail. The MIPv6 specification should be an
abstract protocol specification not tied to any specific HA or MN
implementation (in a perfect world that would be true...). What I'm
proposing is that the HA store separately the (S)=0 binding with the
lifetime negotiated with the MN in the BU/BA exchange, and that this
lifetime be completely independent of the lifetime associated with any
on-link home address prefixes advertised to the MN. I can think of the
following way to implement this on the HA:

1) Create a new (S)=0 binding which stores the home address that the MN
registered in the (S)=0 BU (which Vlad referred to as the "primary HoA"),
and also stores the lifetime negotiated with the MN in the BU/BA exchange.
This binding lifetime could be infinite (if the MN negotiates infinite), and
as I'm proposing is completely independent of any lifetime associated with
on-link home address prefixes. This binding is the one used when exchanging
BU/BA/BRR/etc. with the MN.

2) Then, for each of the home addresses formed from the MN's registered
interface ID combined with the on-link home address prefixes advertised to
the MN by the HA, have the HA create a separate (S)=1 binding with the
shorter of the lifetime of the parent (S)=0 binding and the valid lifetime
of the associated prefix (implementation detail - actually, you could just
have prefix invalidation go through the binding cache and clean up entries
where the home address of the binding matches the invalidated prefix). This
(S)=1 binding points to the (S)=0 binding, and has a state bit set which
indicates that it doesn't hold the correct lifetime ("correct" from the
standpoint of what is negotiated with the MN in the BU/BA exchange), i.e.
that there is an associated parent (S)=0 binding (which it points to) that
has the correct binding lifetime. Or, just the fact that the
parentBindingPtr in the (S)=1 binding is non-NULL would serve to indicate
this.

Of course, if this is just too complex to implement, then you could always
just entirely remove the (S)=0 registration from the specification, and only
allow registration with (S)=1. That's OK by me. Personally, I have no
problem implementing it this way in the Elmic highly-optimized for embedded
systems MIPv6 MN/CN implementation, so I'd expect that HAs can handle this
extra complexity also.

> if just one of them appears in the packet.

I agree with this. For (S)=0 registration, the primary HoA is an
implementation detail on the HA, I think. Sure, the MN picks a home address
formed from the globally unique interface ID to put into the BU, and I guess
you could call that the primary HoA but I was hoping that in my MN
implementation I didn't need to treat it any differently from the other home
addresses formed from that same interface ID. At Vlad's suggestion, however,
I should treat it differently, specifically:

1) when the primary HoA assocated with the (S)=0 registration becomes
deprecated, the MN must choose a new primary HoA for the binding formed from
the same interface ID which is not deprecated

2) The MN must then reregister (S)=0 the binding with the HA using the new
(non-deprecated) primary HoA

I'd like to avoid having to do this - it seems to me that the (S)=0 (L)=1
registration is special and should not be tied to any specific home address,
it is registering the MN's globally unique interface ID.

> simply configured with a static home address) and

I agree with this. But, then above you said "we do not currently have the
concept of a primary home address. The purpose of the S=0 registration is to
register multiple home addresses similarly...". So, you agree that (S)=0
registration is not for any specific home address. In this case, it also
isn't for any specific home address prefix. It is a single (S)=0 binding
associated with multiple prefixes, and actually what is registered here is
the globally unique interface ID of the MN used to form home addresses from
these multiple prefixes. I disagree with you that the (S)=0 registration
always has to base its lifetime on the shortest lifetime of any on-link
prefix being advertised to the MN, I think this is a mistake. That is what
is causing your difficulty here. The MN will manage the lifetimes of
prefixes it discovers independently of the lifetime of the (S)=0 binding.
When a prefix becomes invalidated (per the valid lifetime), the MN will
correctly stop using the associated home address. This should not affect the
state of the (S)=0 binding, i.e. if there are other home addresses formed
from the same globally unique interface ID the MN can still use them as long
as the prefixes used to form them are still valid.

> mobile node when S=0 is used.

Prefix discovery is the mechanism used to convey the prefix lifetimes. The
binding lifetime in the (S)=1 case is associated with the prefix lifetime,
but only indirectly. I propose that the binding lifetime for the (S)=0
registration is completely independent of any prefix lifetime. If you can
take that step, then that simplifies this entire discussion/design and
removes most of your problems (and adds a new problem: that of
implementation). Then it becomes of question of how do you implement this on
the HA. I've described one way at the top of this email.

> is used by the mn even beyond the lifetime of the prefix. This

Again, the lifetime of HoA2 is independent of the lifetime of the (S)=0
binding on the MN - when the address prefix that HoA2 was formed from is
invalidated, the MN will unconfigure that address, and will stop using it
for any future communications. This is the Prefix Discovery mechanism, which
is completely independent of the BU/BA mechanism. As described above, prefix
lifetimes are only indirectly associated with the binding lifetime in the
(S)=1 case, and I'm arguing that they should not be associated at all with
the (S)=0 binding lifetime in the (S)=0 (L)=1 case.

> at the same time. This cause the HA to get a lot of BUs at

This should be a single (S)=0 BU to reregister the entire set of home
addresses formed from the interface ID associated with the binding. I'm not
sure why you think there will be multiple BUs in this case. If you don't
base the lifetime of the (S)=0 binding on the lifetime of any home address
prefix, then that will alleviate this situation.

> for the MNs, particularly if they have to switch back and

Actually, if you make this change, I'll just prohibit my MN implementation
from ever using (S)=0. ;-) Well, probably that's what I'll do.

> BUs don't arrive at the same time.

What you can do is disconnect the association between binding lifetime and
prefix lifetime only for the (S)=0 binding case.

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Dec 2002 14:25:59 +0200

> prefix lifetime only for the (S)=0 binding case.

Ok, I'm convinced. Anyone have a problem with this?

Jari