Subject: [MEXT] New Text for home link detection in RFC3775bis

From: Suresh Krishnan <[email-masked]>
Date: Wed, 02 Jul 2008 10:21:17 -0400

The WG had consensus to fold in text from draft-krishnan-mext-hld into 
RFC3775bis. Here is the proposed text for doing so. Feel free to edit.

This change is made in Section 11.5.4

OLD TEXT
========
    A mobile node detects that it has returned to its home link through
    the movement detection algorithm in use (Section 11.5.1), when the
    mobile node detects that its home subnet prefix is again on-link.

NEW TEXT
========
    When an MN detects that it has arrived on a new link using the
    movement detection algorithm in use (Section 11.5.1) it performs the
    following steps to determine if it is on the home link.

    o  The MN performs the procedure described in Section 11.5.2 and
       configures an address referred to as the Current MN Address (CMA).
       It also stores all the on-link prefix(es) received in the RA along
       with their prefix lengths in a conceptual list called the Current
       Link Prefix List (CLPL).

    o  If the home prefix has been statically pre-configured on the MN
       it checks if the home prefix matches one of the prefixes in the
       CLPL. If it does, the MN concludes that it has returned home.

    o  If the home prefix has not been statically configured the MN uses
       some form of bootstrapping procedure (e.g. RFC5026) to determine
       the home prefix. It then checks if the home prefix matches one of
       the prefixes in the CLPL. If it does, the MN concludes that it has
       returned home.

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "fan zhao" <[email-masked]>
Date: Wed, 2 Jul 2008 11:01:49 -0700

Hi Suresh,

I have a quick comment:
the Home Link Detection is not only performed during handover,
but also during initial attach. The new text is proposed into section
11.5.4.  "Returning Home", which seems to me that the new text
only applies to the handover case.

Therefore, my oponion is to have a new (sub)section called "Home Link
Detection" somewhere, and refer to this new section in section 11.5.4.
What do you think?

Sincerely,
fan

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 02 Jul 2008 14:15:32 -0400

Hi Fan,
   Sounds like a good idea.

Cheers
Suresh

---

From: <[email-masked]>
Date: Thu, 3 Jul 2008 11:07:02 +0200

Hi all,

I hope that the following can hepl:

 If the MN has no configuration then A otherwise B.

A: Bootstrap
o The MN has neither IP address, nor the HA IP address, nor home IP prefix,
o The MN connects to a network, obtains a link IP prefix and acquires or forms an IP address (MN@)
o The MN discovers the HA IP address and its home IP prefixes
o The MN compares the prefix of its IP address (MN@) with the home IP prefixes
		- If those prefixes match then the MN is in its home network, HoA=MN@, and the HA is the HA for this HoA. The MN initiates IP sessions with classical routing.
		- If not then the MN is in a foreign network, CoA=MN@, the HA is a HA for the MN. The MN will form a HoA from home prefixes or will request a HoA from the HA and will exchange a BU/BA with the HA. The MN initiates IP sessions using MIP.

B. Handover
o The MN has a HoA, the HA IP address and its home IP prefixes
o The MN connects to the network and obtains a link IP prefix
o The MN compares the link IP prefix with the HoA IP prefix
		- If those prefixes match then the MN is in its home network
					+ If the MN has no CoA: It means that the MN is always on its home network. It has made no IP handover therefore it does not need to send a BU. The MN continues its IP sessions with classical routing.
					+ If the MN already has a CoA: It means that the MN returns at its home network then it has to sends a BU to deregister. The MN continues its IP sessions with classical routing.
		- If the prefixes do not match then the MN is in a foreign network
					+ if the MN has no CoA: It means that the MN comes from its home network then it forms (or acquires) a CoA with the link prefix on which it has just connected and sends a BU to its HA. The MN continues its IP sessions using MIP.
					+ If the MN already has a CoA:
					* If the link prefixes and the CoA prefix match: It means that the MN is always on the same foreign network. It has made no IP handover therefore it does not need to send a BU. The MN continues its IP sessions using MIP.
					* If the link prefixes and the CoA prefix do not match: it means that the MN has made IP handover towards another foreign network therefore it has to form (or acquire) a CoA with the link prefix on which it has just connected and to send a BU to its HA to update its registration. The MN continues its IP sessions using MIP.

o Note that when the mobile node connects on a new visited network it may need to discover the HA of this network if available. The mobile node may have to use this HA for next IP sessions.

Sincerly,

Kassi

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Suresh Krishnan
Envoyé : mercredi 2 juillet 2008 20:16
À : fan zhao
Cc : [email-masked]
Objet : Re: [MEXT] New Text for home link detection in RFC3775bis

Hi Fan,
   Sounds like a good idea.

Cheers
Suresh

fan zhao wrote:
> Hi Suresh,
> 
> I have a quick comment:
> the Home Link Detection is not only performed during handover, but 
> also during initial attach. The new text is proposed into section 
> 11.5.4.  "Returning Home", which seems to me that the new text only 
> applies to the handover case.
> 
>> The WG had consensus to fold in text from draft-krishnan-mext-hld 
>> into RFC3775bis. Here is the proposed text for doing so. Feel free to edit.
>>
>>
>>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 09 Jul 2008 16:02:27 -0700

Hello Kassi,

I have gone through your proposal.  It seems to be a valid
summary of many actions taken by the mobile node when
encountering a new link.

However, I think it amounts to an abbreviation of material
that is found elsewhere within RFC3775 (e.g., section 4.1)
and RFC 5026.  As such, I do not think it is focussed on the
specific issues that have been raised with home link detection,
but instead is much more generalized and thus harder for me
to pinpoint the need.

Perhaps you could consider whether the text proposed by
Suresh is sufficient for the particular issue under discussion.
If not, and you can suggest some revised wording, that would
be appreciated.

Regards,
Charlie P.

[email-masked] wrote:
>             - If those prefixes match then the MN is in its home
>             network, HoA=MN@, and the HA is the HA for this HoA. The
>             MN initiates IP sessions with classical routing.
>
>             - If not then the MN is in a foreign network, CoA=MN@, the
>             HA is a HA for the MN. The MN will form a HoA from home
>             prefixes or will request a HoA from the HA and will
>             exchange a BU/BA with the HA. The MN initiates IP sessions
>             using MIP.
>
> B. Handover
>
>                                     + If the MN has no CoA: It means
>                                     that the MN is always on its home
>                                     network. It has made no IP
>                                     handover therefore it does not
>                                     need to send a BU. The MN
>                                     continues its IP sessions with
>                                     classical routing.
>
>                                     + If the MN already has a CoA: It
>                                     means that the MN returns at its
>                                     home network then it has to sends
>                                     a BU to deregister. The MN
>                                     continues its IP sessions with
>                                     classical routing.
>
>                                     + if the MN has no CoA: It means
>                                     that the MN comes from its home
>                                     network then it forms (or
>                                     acquires) a CoA with the link
>                                     prefix on which it has just
>                                     connected and sends a BU to its
>                                     HA. The MN continues its IP
>                                     sessions using MIP.
>
>                                                 * If the link prefixes
>                                                 and the CoA prefix
>                                                 match: It means that
>                                                 the MN is always on
>                                                 the same foreign
>                                                 network. It has made
>                                                 no IP handover
>                                                 therefore it does not
>                                                 need to send a BU. The
>                                                 MN continues its IP
>                                                 sessions using MIP.
>                                                 * If the link prefixes
>                                                 and the CoA prefix do
>                                                 not match: it means
>                                                 that the MN has made
>                                                 IP handover towards
>                                                 another foreign
>                                                 network therefore it
>                                                 has to form (or
>                                                 acquire) a CoA with
>                                                 the link prefix on
>                                                 which it has just
>                                                 connected and to send
>                                                 a BU to its HA to
>                                                 update its
>                                                 registration. The MN
>                                                 continues its IP
>                                                 sessions using MIP.
> o Note that when the mobile node connects on a new visited network it 
> may need to discover the HA of this network if available. The mobile 
> node may have to use this HA for next IP sessions.
>
> Sincerly,
>
> Kassi
>
>
> De : [email-masked] [_mailto:[email-masked]] De la part 
> de Suresh Krishnan
> >> _https://www.ietf.org/mailman/listinfo/mext_
> >>
>
> _https://www.ietf.org/mailman/listinfo/mext_
>
> ------------------------------------------------------------------------
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Jul 2008 11:08:30 -0700

Hello Suresh,

I'm creating a new issue for "home link detection" to
go into the issue tracker.  Your suggested text seems
to have found consensus for resolving the issue, as
long as it is located in a new section (as suggested in
later messages).  However, I would like to suggest a
textual revision and simplification.  Most of the revision
relies on pointing out that one has to get a home network
prefix before using it to compare against the list of
prefixes received in the RA.  The other revision, which
I hope is O.K., is to dispense with creating the new
acronyms CMA and CLPL.  I am biased against having
acronyms that are not used elsewhere in the document.

Here is my result:

NEW TEXT
========

Section 11.5.X   Home Link Detection

   When an MN detects that it has arrived on a new link using the
   movement detection algorithm in use (Section 11.5.1x) it performs the
   following steps to determine if it is on the home link.

   o  The MN performs the procedure described in Section 11.5.2x and
      configures an address.    It also keeps track of all the on-link 
prefix(es)
      received in the RA along with their prefix lengths.

      the home prefix.

   o  Given the availability of the home prefix, the MN checks whether or
       not the home prefix matches one of the prefixes received in the RA.
       If it does, the MN concludes that it has returned home.

================================================

It is also a bit tricky to determine where to locate this new section.
The current organization of section 11.5 is as follows:

     11.5. Movement  . . . . . . . . . . . . . . . . . . . . . . . . 123
       11.5.1. Movement Detection  . . . . . . . . . . . . . . . . . 123
       11.5.2. Forming New Care-of Addresses . . . . . . . . . . . . 125
       11.5.3. Using Multiple Care-of Addresses  . . . . . . . . . . 126
       11.5.4. Returning Home  . . . . . . . . . . . . . . . . . . . 127

After reading through the text, I think the new subsection would
fit best after the current 11.5.1, making it a new subsection 11.5.2.

================================================

By the way, given the new subsection, the first sentence of the
_current_ subsection 11.5.2 (to become subsection 11.5.3) needs
to be changed:

OLD:
   After detecting that it has moved a mobile node SHOULD generate a new
   primary care-of address using normal IPv6 mechanisms.

NEW:
   After detecting that it has moved to a link away from home, a mobile node
   SHOULD generate a new primary care-of address using normal IPv6
   mechanisms.

=================================================

Strictly speaking, the names of section 11.5{,.1} are probably wrong.
Perhaps they should be something more like "New Link{s, Detection}".
This is because a node can require establishment of a new link
without any movement.  For instance, as we all know, sometimes
wireless access points become unreachable even if we are standing
still, and then we have to search for another access point in range.

I haven't decided yet whether to actually go ahead and rename the
sections.  Comments are welcome!

Regards,
Charlie P.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 11 Jul 2008 14:20:35 -0400

Hi Charlie,
   Your suggested text sounds good. If you are looking for a new name 
for these sections may I suggest "Attachment to a new link" :-)

Cheers
Suresh