Re: [MEXT] Issue #10: The usage of "HA lifetime" (RFC3775-update)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEXT] Issue #10: The usage of "HA lifetime" (RFC3775-update)



Hi Charlie,

Thanks for clarification.
I am sorry for my long delay.

At Fri, 03 Oct 2008 11:10:45 -0700,
Charles E. Perkins wrote:
>
>
> Hello Ryuji,
>
> I'd like to suggest a resolution to this issue.
>
> First, it's interesting to note that not all IPv6 addresses come
> equipped with lifetimes.  For instance, DNS server addresses
> are supplied by DHCP without any associated address lifetime.
>
> I think it is O.K. to have the home agent address lifetime.
> treated similarly.  If the mobile node is preconfigured with
> a home agent address, that information should not be timed
> out by way of any default lifetime.
>
> Similarly, the home agent addresses supplied in the
> "Home Agent Address Discovery Reply" message are
> not equipped with lifetimes.  So, I think that any home
> agent that was discovered in this way should be used
> in the same way as a preconfigured home agent address,
> and not timed out.

If RFC3775 clearly mention this,  I am OK with it.

> On the other hand, home agent addresses discovered
> by way of local Router Advertisement messages (containing
> the Prefix Information option) do have address lifetimes.
> However, in this case the presumption is that the the
> Advertisement messages are beaconed periodically, and
> that each periodic advertisement updates the time-out
> schedule at each receiver on the subnet.  Thus, effectively,
> the typical scenario is that the home agent address seldom
> times out at any device receiving the Advertisement
> messages.  Of course, if the home agent dies and no
> longer sends advertisements, the home agent address
> information has to be expunged.  But this does not happen
> very often, and should not be the model for operation
> when the Advertisements are no longer available due to
> node movement.
> Thus, in all cases, it seems to me that allowing the Home
> Agent address information to expire is counter to the
> operational intention as indicated in RFC 3775.
>
> Conceptually, this depends on the mobile node being
> able to distinguish between loss of connectivity to the
> home network due to mobility, versus loss of neighbor
> connectivity to the home agent on the home network.
> We can presume that an operational IPv6 network
> has Internet connectivity and thus a local router.  Then,
> this can be done if the mobile node keeps track of
> advertisements on its home subnet, for which it does
> have a record of the subnet prefix.  When there are no
> advertisements from the home network, the mobile
> node can take action as if it had moved away -- and
> keep the home agent address without applying any
> timeout.  When there are advertisements from the
> home network, but no more advertisements from the
> mobile node's home agent, it should act as if the home
> agent was no longer accessible, and apply the address
> lifetime to the home agent's IPv6 address.

I support this.

> If this is agreeable, I will craft some clarifying text
> for rfc3775bis.  Or, even better, I would happily accept
> text from others containing an acceptable resolution to
> this issue.

thanks!
ryuji


> Comments?
>
> Regards,
> Charlie P.
>
>
>
>
>
> Ryuji Wakikawa wrote:
> > Hi George
> >
> > In my previous email, I tried to figure out why DHAAD does not provide
> > HA lifetime.
> > My guess was that the HA lifetime is originally proposed for HA who manages
> > other HAs at the home link by original authors.
> > I think my guess was wrong...
> >
> > Anyway, if MN manages the HA lifetime if the lifetime is available, we
> > need some
> > operational description when the lifetime is not available.
> > RFC3775 clearly said that the HA entry MUST be deleted when its lifetime
> > is expired.
> > BUT the lifetime is not always available...
> >
> > So far, we have two options for this.
> >
> > 1. George
> > No cache. MN does not record the HA information in its home agent list.
> > 2. Vijay
> > Local configuration matter. No modification is required to RFC3775.
> >
> > I personally agree with Vijay, but I think we need some clarification
> > for this in the bis.
> > We might need to define the default value for the locally configured HA
> > lifetime..
> >
> > regards,
> > ryuji
> >
> >
>
>

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.