Subject: [Mip6] Default value for HA Lifetime, in HA RA

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Nov 2005 15:24:30 +0100

Hi,

I am not sure whether this has been discussed.

Is there a true "default" value for the HA Lifetime field of the HA
Information Option in RAs sent by HAs on the home link?  The HA RA is
used by HAs on the home link to maintain the HA list, which will
eventually be sent to MN in a DHAAD Reply.

The spec currently says this "default" value should equal the Router
Lifetime that HA (as a router) sends on a link, and that "0" MUST NOT be
used.  Or, most HAs on the home link will use "0" as Router Lifetime,
because few of them (if any at all) are supposed to be default routers.

Which leaves one guessing about what to put in the HA Lifetime field.
Should the HA just put a "default" value 0x1000?  Too long, too short?
Should it put the max value 0xffffffff?  The text does not have any
recommendation about that.

Also, will a HA link-multicast an RS to other HAs when this lifetime
expires?  Current text seems to be silent about it, it just says that
when lifetime expires the entry in HA list is deleted.

Thanks,

Alex

RFC 3775 has that:
>   Home Agent Lifetime
> 
>       16-bit unsigned integer.  The lifetime associated with the home
>       agent in units of seconds.  The default value is the same as the
>       Router Lifetime, as specified in the main body of the Router
>       Advertisement.  The maximum value corresponds to 18.2 hours.  A
>       value of 0 MUST NOT be used.  The Home Agent Lifetime applies only
>       to this router's usefulness as a home agent; it does not apply to
>       information contained in other message fields or options.

RFC 2461:
>       Router Lifetime
>                      16-bit unsigned integer.  The lifetime associated
>                      with the default router in units of seconds.  The
>                      maximum value corresponds to 18.2 hours.  A
>                      Lifetime of 0 indicates that the router is not a
>                      default router and SHOULD NOT appear on the default
>                      router list.  The Router Lifetime applies only to
>                      the router's usefulness as a default router; it
>                      does not apply to information contained in other
>                      message fields or options.  Options that need time
>                      limits for their information include their own
>                      lifetime fields.

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Brian Haley <[email-masked]>
Date: Wed, 16 Nov 2005 10:47:08 -0500

Hi Alex,

RFC 2461 defines the default Router Lifetime to be (3 * 
MaxRtrAdvInterval), or 1800 seconds, so if you have a zero Router 
Lifetime you should set the Home Agent Lifetime to this.

I would agree this might not be as clear as it could be in 3775, it 
really only says you should only include the HAI option if the lifetime 
is different from the Router Lifetime in the RA.  The receiving rules 
are at least clear.

Regarding multicasting an RS when the HA Lifetime goes to zero, I 
wouldn't think so, you just have to assume either the router is 
unreachable or it stopped offering HA services.  The router should have 
transmitted a final RA with the lifetimes set to zero if it went 
off-line gracefully of course (as 6.2.5 in 2461 says).  Plus, routers 
don't send solicitations, hosts do :)

-Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Nov 2005 17:12:39 +0100

> Lifetime you should set the Home Agent Lifetime to this.

Oh, so that was.

> really only says you should only include the HAI option if the 
> lifetime is different from the Router Lifetime in the RA.  The 
> receiving rules are at least clear.
> 
> unreachable or it stopped offering HA services.

Ok... I see.

I assumed wrongly that HA would decrement the Lifetimes in the HA list,
but it's not the case.  It's the MN who decrements that lifetime.  And
after it decrements it to 0 it should send DHAAD Request to its HAs, right?

> The router should have transmitted a final RA with the lifetimes set
>  to zero if it went off-line gracefully of course (as 6.2.5 in 2461 
> says).

Right...

> Plus, routers don't send solicitations, hosts do :)

Right, sorry for the mistake.  An MR would send RSs though.  Anyways...

Alex

---

From: Brian Haley <[email-masked]>
Date: Wed, 16 Nov 2005 14:51:57 -0500

> after it decrements it to 0 it should send DHAAD Request to its HAs, right?

No, maybe I confused you.  When I was talking about HA lifetime I was 
talking about the lifetime in the HA Info Option in the RA.  When this 
ticks-down to zero this HA would get removed from the list that could be 
returned with DHAAD.  The MN probably wouldn't process the HA Info part 
of the RA.

-Brian

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 17 Nov 2005 11:18:16 -0500

Brian

> returned with DHAAD.  The MN probably wouldn't process the HA Info part

Hmmm.. why not?

If this is processed by the mobile node, then the mobile node can keep
track of the HA preferences and liftimes.  It can also manage the DHAAD
list and not send DHAAD requests when that list is not empty.

Just a thought.

-vlad

---

From: Brian Haley <[email-masked]>
Date: Thu, 17 Nov 2005 14:00:19 -0500

> list and not send DHAAD requests when that list is not empty.

Yeah, when the MN is at home and can see these RAs, it could process 
them, but from an implementation standpoint it's easier to not write the 
code to do this in a MN since you might never be at "home" - this is 
what MIPL does.  Plus, DHAAD is evil according to some and should not be 
used...

-Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Nov 2005 19:44:09 +0100

Hi Brian,

Brian Haley wrote:
> lifetime is different from the Router Lifetime in the RA.

Would it be right to conclude that whenever the HA is not the DR
(Default Router) the HAI option must be present in RA sent by that HA?
If it's not then the HA1 Lifetime in HA list of the receiving HA2 is
going to be 0.

If the HAI option is not included then there's at least the following
drawback: the receiving HA will unnecessarily create an entry in the HA
list with the lifetime equal 0, which will immediately be deleted
afterwards by the process that decrements lifetimes and that removes
everything that has 0 lifetime:

>    o  Determine the lifetime for this home agent.  If the Router
>       Advertisement contains a Home Agent Information Option, then the
>       lifetime is taken from the Home Agent Lifetime field in the
>       option; otherwise, the lifetime specified by the Router Lifetime
>       field in the Router Advertisement SHOULD be used.
[...]
>    o  The remaining lifetime of this Home Agents List entry.  If a Home
>       Agent Information Option is present in a Router Advertisement
>       received from a home agent, the lifetime of the Home Agents List
>       entry representing that home agent is initialized from the Home
>       Agent Lifetime field in the option (if present); otherwise, the
>       lifetime is initialized from the Router Lifetime field in the
>       received Router Advertisement.  If Home Agents List entry lifetime
>       reaches zero, the entry MUST be deleted from the Home Agents List.

On another mail you wrote:
> The MN probably wouldn't process the HA Info part of the RA.

Ok, this was _a_ confusion on my side.  The MN doesn't receive the HA
Lifetime in the DHAAD Reply.  It's the HA that decrements that lifetime.

So would it be right to say that the HA List Conceptual Data Structure
is different on MN than on HA?  The HA List on HA takes decrementing
actions on some fields while the HA List on MN doesn't.  The spec
currently does not have MN to maintain a HA List, but I think it should.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Nov 2005 21:41:51 +0100

Brian Haley wrote:
> Vlad Yasevich wrote:
> 
>>> No, maybe I confused you.  When I was talking about HA lifetime I
>>>  was talking about the lifetime in the HA Info Option in the RA.
>>>  When this ticks-down to zero this HA would get removed from the
>>>  list that could be returned with DHAAD.  The MN probably
>>> wouldn't process the HA Info part of the RA.
>> 
>> 
>> 
>> Hmmm.. why not?
>> 
>> If this is processed by the mobile node, then the mobile node can 
>> keep track of the HA preferences and liftimes.  It can also manage
>>  the DHAAD list and not send DHAAD requests when that list is not 
>> empty.
>> 
>> Just a thought.
> 
> 
> them, but from an implementation standpoint it's easier to not write 
> the code to do this in a MN since you might never be at "home" - this
> is what MIPL does.

I think that MN shouldn't process the HAI options when seeing them at
home, but the HAI option could be delivered to MN in DHAAD Reply, and
thus when Lifetime becomes 0 MN would send DHAAD Request again (if it
doesn't have a HA available).

> Plus, DHAAD is evil according to some and should not be used...

Sorting this out is very urgent to me.

There is a draft-dhaad-harmful.

There are unclear aspects with anycast routing.

The DHAAD part in 3775 has other unclear things, like HAI optional
presence, HA List presence at MN and HA List missing HA interface ids.

However, rfc3963 has an error processing section whereby MR sends a new
BU to another HA on the home link (in case of error).  Currently, the
only implementable way for MR to know about alternate HAs on the home
link is with DHAAD.  I'm saying "implementable" because it's in a
Proposed Standard, as opposed to the draft status of the bootstrapping
drafts.

So I am interested to find out whether there's any interest in
improving the DHAAD spec and use it, or make a clear indication (I'm not
sure under what form) about never ever use DHAAD.

Alex

---

From: Brian Haley <[email-masked]>
Date: Thu, 17 Nov 2005 15:58:58 -0500

> (Default Router) the HAI option must be present in RA sent by that HA?

I would say Yes.

> everything that has 0 lifetime:

The HA should never create an entry since HA Lifetime=0 is not allowed. 
  Again, 3775 doesn't spell this out exactly, maybe someone is keeping 
track of the nits?  Our implementation treats this as an error and 
ignores it.

> Lifetime in the DHAAD Reply.  It's the HA that decrements that lifetime.

Right, the MN just gets an ordered list.

> currently does not have MN to maintain a HA List, but I think it should.

I've only implemented HA and CN code, but from what I remember the HA 
List is only on the HA, the MN has a Binding Update List.  Of course 
3775, Section 11.4.1 says:

    If the mobile node has a current registration with some home agent
    (the Lifetime for that registration has not yet expired), then the
    mobile node MUST attempt any new registration first with that home
    agent.  If that registration attempt fails (e.g., timed out or
    rejected), the mobile node SHOULD then reattempt this registration
    with another home agent.  If the mobile node knows of no other
    suitable home agent, then it MAY attempt the dynamic home agent
    address discovery mechanism described above.

So I guess keeping a list of HAs could be implementation-dependent.

-Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Nov 2005 22:09:37 +0100

Brian Haley wrote:
>> So would it be right to say that the HA List Conceptual Data
>> Structure is different on MN than on HA?  The HA List on HA takes
>> decrementing actions on some fields while the HA List on MN
>> doesn't.  The spec currently does not have MN to maintain a HA
>> List, but I think it should.
> 
>  List is only on the HA, the MN has a Binding Update List.

That's what I think too.

> Of course 3775, Section 11.4.1 says:
> 

YEs, the list of HAs at MN could be left out as "implementation
dependent".  The only risk with it is that whoever implements it at MN
is very likely to call it "HA list" (which HA list, HA's or MN's?)...

Alex

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Nov 2005 09:11:39 +0100

In your previous mail you wrote:

   
   
=> note the SHOULD here is against an attack: when the MN got several
DHAAD replies with a fake one in front, it should try all the HAs in
the replies before come back to DHAAD. The idea is to give a chance to
try a good HA...

Regards

[email-masked]

---

From: Brian Haley <[email-masked]>
Date: Fri, 18 Nov 2005 09:07:42 -0500

> the replies before come back to DHAAD. The idea is to give a chance to

I was thinking a MN might have a few statically configured HA addresses, 
and if BUs fail to all, then it does DHAAD.  But I've never implemented 
a MN :)

-Brian