Subject: RE: [mobile-ip] MIPv6 v20 BU infinite lifetime (0xffff) and persistent bindings

From: "Greg O'Shea" <[email-masked]>
Date: Mon, 10 Feb 2003 18:52:22 -0000

I saw no response to that query. Here are some more problems that are
unresolved with 0xffff lifetimes.

3) If MN becomes permenantly unavailable (e.g. broken, dropped
overboard, powered down and never powered up again) then HA will
continue to guard its HoA forever, and that's too long a time. 

4) While MN is offline the HA will continue to try and route packets for
MN towards its last known CoA. There is no reason (that I can see) to
suppose that this is reasonable behaviour for a HA. If the ICMP
unreachable don't get back to the HA then the care-of net becomes an
expensive /dev/null.

5) Draft 20 Section 9.3.4 says that a CN should delete a BCE for which
it gets persistent ICMP host unreachable messages. This will happen if
the MN is long-term disconnected or powered down. So how can a BCE be
deleted due to ICMP unreachable *and* permanent due to 0xffff ?

These are just examples of how 0xffff lifetime prevents the distributed
MIPv6 state from converging on something sensible. There may be more.
All of these things take care of themselves with finite lifetimes.

I start to think that the 0xffff device should be removed.

Greg
>-----Original Message-----
>From: Greg O'Shea [mailto:[email-masked]]
>Sent: 03 February 2003 18:00
>To: Mobile IPv6 mailling list
>Subject: [mobile-ip] MIPv6 v20 BU infinite lifetime (0xffff) 
>and persistent bindings 
>
>
>Two things:
>
>1) if the HA is not persisting infinite bindings, and it
>reboots, then how can the MN detect that its HA service has failed? 
>
>2) how can the MN detect whether or not HA is persisting bindings?
>
>What is the justification for the mandatory inifinite
>lifetime? Convergeance would seem to occur more reliably and 
>sooner with a shorter lifetime. (Shorter than infinity, anyway.)
>
>Greg
>>-----Original Message-----
>>From: Vijay Devarapalli [mailto:[email-masked]]
>>Sent: 31 January 2003 22:32
>>To: Ed Remmell
>>Cc: Greg O'Shea; Mobile IPv6 mailling list
>>Subject: Re: [mobile-ip] MIPv6 v20 question re L bit
>>
>>
>>Ed Remmell wrote:
>>> 
>>> Of course, there is the other alternative that Pascal Thubert 
>>> suggested, specifically doing DAD on the MN's home address
>>to resolve
>>> the link-layer address of the HA defending the home address. That 
>>> appears increasingly more attractive ;-)
>>> 
>>
>>I agree with the last part. this is what I has suggested
>>to a bunch of folks off the list.
>>
>>> 
>>> I had this long discussion with Nicolas Delest. I think we like 
>>> Pascal's suggestion of the MN doing DAD for its own address.
>>> 
>>> 1. MN realizes it is home (by receiving a router advert
>>>    with the home prefix)
>>> 2. it sends a DAD probe with source set to unspecified
>>>    address and the target set to HoA. Note: this is the
>>>    natural behaviour. whenever the MN receives a router 
>>>    advertisement advertising a new prefix, it configures 
>>>    an address and does DAD for that address.
>>> 3. the HA responds with a neighbor advertisement.
>>> 4. the MN gets hold of HA's MAC address
>>> 5. the MN sends a deregistration BU.
>>> 
>>> ofcourse there is one small hack in the above. the MN instead of
>>> considering the neighbor advertisement from the HA as a DAD 
>failure,
>>> it considers it a DAD success and proceeds to send a deregistration
>>> BU. but IMO, this is not a big deal. it is a DAD success 
>because, the
>>> HA was defending it so far and now the MN can take over. (Nicolas 
>>> convinced me on this).
>>
>>Note: steps 2, 3 and 4 are skipped if the router advertisement was 
>>sent by the HA which currently has binding cache entries for the MN.
>>
>>> 
>>> if the HA were not defending MN's home address (because
>>> the MN was shut off before coming home), then
>>> 
>>> 1. MN realizes it is home
>>> 2. MN looks at its binding update list and knows that
>>>    the binding at the HA has expired.
>>> 3. does DAD for the home address.
>>> 4. if DAD succeeds everything is fine. if it fails, 
>>>    then someone on the home link has configured its 
>>>    address.
>>> 
>>> we concluded that there is no need for BED (and therefore no need 
>>> for a new ICMP code).
>>> 
>>
>>I think the above is sufficient. This also solves the
>>issue raised by Greg in another email with subject
>>"MIPv6 v20 Question re returning home NA hack".
>>
>>Vijay
>>
>
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Feb 2003 10:58:20 +0200

Ok, I'm convinced. Anyone opposed to removing 0xffff?

Jari

---

From: Brian Haley <[email-masked]>
Date: Tue, 11 Feb 2003 13:26:02 -0500

> Ok, I'm convinced. Anyone opposed to removing 0xffff?

So you're making 0xffff just a regular lifetime (262140), right?
That's fine with me.

> continue to guard its HoA forever, and that's too long a time.

We just fixed this, but the other obvious workaround is to
adminstratively set the max lifetime on the HA to something less
than infinite.

> unreachable don't get back to the HA then the care-of net becomes an

This is not much worse than my machine today trying to reach
a system halfway around the world on some ISPs network that
doesn't propogate ICMP back.  The only difference I can see
is the periodic MPA that the HA might send.

> deleted due to ICMP unreachable *and* permanent due to 0xffff ?

The CN can delete a binding at anytime, regardless of the
lifetime, "permanent" certainly doesn't override ICMP unreachable,
or some local cache replacement policy (Section 9.1).

-Brian