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

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 03 Oct 2008 11:10:45 -0700

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.

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.

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 03 Oct 2008 11:22:00 -0700

Hello Benjamin,

Along the way to resolving issue #10, I had some thoughts
about the points you raised.

If you go along with my suggestion that the home agent addresses
supplied in the Home Agent Address Discovery Reply message
do not have lifetimes associated with the addresses, then we can
make a reasonable suggestion about list maintenance and processing.

I would suggest that the home agent addresses obtained from the
Reply message should be stored and used as necessary.  When the
current home agent becomes inaccessible, the mobile node should
try to send an update to the next home agent on the list.  When one
of the home agents on the list seems unresponsive, it should be
deleted from the list of available home agents.  When the list is
depleted, the mobile node can re-attempt the discovery process.

But these are rare events.  Perhaps the mobile node would have to
try the discovery process on a timescale measured in months or
years, under most scenarios for administering the home network.

If you agree with this, then I guess there is again a need for some
clarifying text in section 11.4.1.  Contributions are always welcome.

The previous discussion points are documented at the following URL:
    http://trac.tools.ietf.org/wg/mext/trac/ticket/10

Regards,
Charlie P.

Benjamin Lim wrote:
>
> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not specifically
> mention what MN will do to the list of HA address received in DHAAD reply. I
> think the confusion comes in because the section state one possible way to
> do home registration is to perform a sequential trial of each home agent
> address in the list (e.g. test 1st HA address --> fail --> test 2nd HA
> address --> fail --> until end of list or succeed.) So this implies that MN
> should store the list of HA address in order to do the above action. Whether
> this list is store temporary (just to find HA) or permenantly (info for MN
> in case HA goes down) is not mention. Maybe we should add some clarifying
> text for this matter?
>
> Regards,
> Benjamin Lim
>

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 03 Oct 2008 15:35:17 -0500

Hi Charlie,

In the bootstrapping work that was done in the MIP6 WG, the MN is
dynamically assigned an HA. The scenario where an MN does HA discovery using
DHAAD was considered to be remote. But of course 3775 does specify HA
discovery and I am not arguing against that.
Maybe it is worthwhile revisiting the issue about DHAAD. Is dynamic HA
discovery still an important feature for MIP6? Or given that we now have
some bootstrapping solutions (integrated and split) can we rely on those for
HA discovery/assignment.

I do not believe that the idea of an MN maintaining a list of HAs received
in the Home Agent Address Discovery Reply message is very practical. If an
MN finds that the HA is unresponsive, I don't think it will try to verify
the next HA on the list. Most likely it will simply find another HA and
perform another registration. Agree that the previous HoA is no longer
valid. But I don't think that it would be disastrous to the MN.

So maybe we should reconsider the DHAAD feature in MIP6. It would be a way
of simplifying the protocol as well.

-Raj

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 03 Oct 2008 14:25:22 -0700

Hello  Basavaraj,

I am neutral on this.   Any new discussion should take into
account the voluminous discussion which has gone before,
summarized at the following URL:
    http://trac.tools.ietf.org/wg/mext/trac/ticket/2

I won't attempt to summarize the discussion here, but I'd like to
point out that the new revision of rfc3775bis incorporates text as
discussed at the Dublin IETF and on the mailing list, and intended
to close the issue.  On the other hand, I know that there are people
who would like to reopen the discussion.  Basically, I have
encouraged them to try convince the working group, and to
convince the chairs that rfc3775bis is the appropriate vehicle
for carrying out such a relatively large change to the protocol.

Regards,
Charlie P.

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 3 Oct 2008 14:30:31 -0700

Hi Raj and Charlie,

I agree with Raj on this issue. There are two main solution for dynamic HA discovery we have specified in the bootstrapping work and those are based on DNS and DHCP. These were also the solutions adopted by all other SDOs which adopted MIPv6.

Based on this I agree there is a value in simplifying MIPv6 removing the support for DHAAD.

Gerardo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Basavaraj Patil
> Sent: Friday, October 03, 2008 1:35 PM
> To: Charles Perkins; Benjamin Lim
> Cc: [email-masked]
> Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list
> processing
>
>
> Hi Charlie,
>

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 06 Oct 2008 11:57:42 -0500

Mext chairs (Marcelo/Julien),

Would you comment on the proposal to revisit thee DHAAD feature in MIP6
(RFC3775) and replace it with the solutions that were subsequently developed
as part of the bootstrapping work. This change would be done as part of the
effort to revise RFC3775.

-Raj

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Oct 2008 19:20:22 +0200

Hi Raj,

Basavaraj Patil escribió:
> as part of the bootstrapping work.

Our charter states:

Work items related to base specification maintenance include:

(B.1) Create and maintain issue lists that are generated on the basis
of implementation and interoperability experience. Address
specific issues with specific updates or revisions of the base
specification. One specific area of concern that should be
analyzed and addressed relates to multilink subnets.

This work item relates only to corrections and
clarifications. The working group shall not revisit design
decisions or change the protocol.

Changing DHAAD feature by other solution as you mention, seems to me 
more than a clarification or a correction, but a significant change in 
the spec. This would go beyond the scope of our current work.

If there were strong WG consensus behind the proposed change i.e. it is 
obvious that we need to make that change,  I would be tempted to go 
beyond a simple correction or clarification,  and we could discuss how 
make that change with our AD, but i don't think we are there yet.

So, my take on this is that so far, the issue does not seem to fall into 
the scope of our work in rfc3775 and there doesn't seem to be strong 
consensus in doing it neither, so i think the solution proposed by 
charlie at this point is the reasonable way to go. (I am merely 
expressing my view on the wg status and the charter on this issue, so if 
the wg feels differently, this could be changed)

Regards, marcelo

>  This change would be done as part of the

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 06 Oct 2008 12:33:45 -0500

Hi Marcelo,

I agree that the WG charter w.r.t MIP6 (RFC3775) is limited to only doing
maintenance work ("Corrections and clarifications "). However I think it
would be worthwhile to potentially consider simplifying the protocol as
well. 
One of the things that the previous MIP6 WG intended to do was to decouple
some of the more larger features in the protocol (such as route
optimization, movement detection, home agent discovery) in separate specs.
However we never did get to that point. Maybe it is something that MEXT WG
ought to take up. Anyway, I will propose this simplification of MIP6 for
discussion at the upcoming IETF73 meeting and we can get a sense of the WG.

-Raj

On 10/6/08 12:20 PM, "Marcelo Bagnulo" <[email-masked]> wrote:

>>>>>> mention what MN will do to the list of HA address received in DHAAD
>>>>>> reply.
>>>>>> I

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Oct 2008 21:14:09 +0200

> discussion at the upcoming IETF73 meeting and we can get a sense of the WG.
that seems a good plan to me

let us know how much time do you think i will be needed for this and 
following disucssion

regards, marcelo

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 20 Oct 2008 18:38:27 +0900

Hi Charlie,

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

At Fri, 03 Oct 2008 11:10:45 -0700,
 > in the same way as a preconfigured home agent address,

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

 > lifetime to the home agent's IPv6 address.

I support this.

 > text from others containing an acceptable resolution to

thanks!
ryuji

---

From: Benjamin Lim <[email-masked]>
Date: Tue, 21 Oct 2008 14:17:39 +0800

Hi Charlie,

I agree with your points.  Below is the propose text to Section 11.4.1
capturing the discussed points (hopefully).  Pls feel free to provide
comments for better wording.

Old Text (Section 11.4.1)
========
...

In this case, the mobile node MAY attempt to discover the address of
a suitable home agent on its home link.  To do so, the mobile node
sends an ICMP Home Agent Address Discovery Request message to the
Mobile IPv6 Home-Agents anycast address [16] for its home subnet
prefix.  As described in Section 10.5, the home agent on its home
link that receives this Request message will return an ICMP Home
Agent Address Discovery Reply message.  This message gives the
addresses for the home agents operating on the home link.

The mobile node, upon receiving this Home Agent Address Discovery
Reply message, MAY then send its home registration Binding Update to
any of the unicast IP addresses listed in the Home Agent Addresses
field in the Reply.  For example, the mobile node MAY attempt its
home registration to each of these addresses, in turn, until its
registration is accepted.  The mobile node sends a Binding Update to
an address and waits for the matching Binding Acknowledgement, moving
on to the next address if there is no response.  The mobile node
MUST, however, wait at least InitialBindackTimeoutFirstReg seconds
(see Section 13) before sending a Binding Update to the next home
agent.  In trying each of the returned home agent addresses, the
mobile node SHOULD try each of them in the order they appear in the
Home Agent Addresses field in the received Home Agent Address
Discovery Reply message.

New Text
========
..

In this case, the mobile node MAY attempt to discover the address of a
suitable home agent on its home link.  To do so, the mobile node sends
an ICMP Home Agent Address Discovery Request message to the Mobile IPv6
Home-Agents anycast address [16] for its home subnet prefix.  As
described in Section 10.5, the home agent on its home link that receives
this Request message will return an ICMP Home Agent Address Discovery
Reply message.  This message gives the addresses for the home agents
operating on the home link without having any lifetimes associated with
the addresses.  The mobile node MAY store these home agent addresses in
an internal list to perform its home registration procedures (e.g.
sending of Binding Update).

The mobile node, upon receiving this Home Agent Address Discovery Reply
message, MAY then send its home registration Binding Update to any of
the unicast IP addresses listed in the Home Agent Addresses field in the
Reply.  For example, the mobile node MAY attempt its home registration
to each of these addresses, in turn, until its registration is accepted.
 The mobile node sends a Binding Update to an address and waits for the
matching Binding Acknowledgement.   If the mobile node does not receive
a matching Binding Acknowledgement, the mobile node SHOULD remove that
Home Agent Address from its internal list before moving on to the next
address in its list.  The mobile node MUST, however, wait at least
InitialBindackTimeoutFirstReg seconds  (see Section 13) before sending a
Binding Update to the next home agent.  In trying each of the returned
home agent addresses, the mobile node SHOULD try each of them in the
order they appear in the Home Agent Addresses field in the received Home
Agent Address Discovery Reply message.  When the internal list is
depleted, the mobile node can re-attempt the discovery process by
sending an ICMP Home Agent Address Discovery Request message to the
Mobile IPv6 Home-Agents anycast address for its home subnet prefix.

Regards,
Benjamin Lim

Charles E. Perkins wrote:
>> reply. I