Subject: [mobile-ip] Issue #95 and some proposals for resolution

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Oct 2002 14:46:52 -0700

Hello folks,

Issue #95 raises questions related to the following topics:

== Terminology clarification for routing header type
== Handling of routing header for Binding Acknowledgement
== Site-local addressability
== Use of Home Address Option in Binding Updates

Here are some proposed resolutions (enumerated) for Issue #95, the
text of which is too long to be included in this message.  Please consult
   http://www.piuha.net/~jarkko/publications/mipv6/issues/issue95.txt
for the complete text.

1. Observe, within the Terminology section, that instances of
   "Routing Header" within the specification are to be interpreted
   as "Routing Header Type 2" unless otherwise indicated.

2. Change relevant instances of "Routing Header" within the text to
   specify "Routing Header Type 2" whenever understandability and
   readability will be enhanced.

3. The following text is to be deleted from section 6.1.8:

   The Binding Acknowledgement is sent to the source address of the
   Binding Update message, regardless of whether the Binding Update
   succeeded or failed.  No Routing Headers are added to the message.

4. Changes for 9.4.4:

   The following text is to be deleted:

                                              Furthermore, if the packet
    is to be sent to the mobile node at any address other than the mobile
    node's home address, it MUST be sent using a Routing header (even if
    the binding was rejected).  The intermediate IP address, to which
    the packet will be delivered immediately before the home address, is
    determined as follows:
 
     -  Whenever the Binding Update is accepted with a nonzero lifetime,
        the routing header will be constructed using the care-of address
        as described in Section 9.6.
 
     -  Otherwise, if the Source IP Address of the packet containing
        the Binding Update, is legal for inclusion in a Routing Header,
        the routing header will be constructed using that IP address.
        Note that multicast addresses, link-local addresses, loopback
        addresses, IPv4 mapped addresses, and the unspecified address,
        MUST NOT be used within a Routing Header for the Binding
        Acknowledgement.

   The following text is to be added, and (as requested elsewhere)
   enables deregistrations from the home network to use a link-local address:
 
    If the Source Address field does not contain a unicast address,
    the Binding Acknowledgement MUST NOT be sent, and the Binding
    Update packet MUST be silently discarded.  Otherwise, the
    acknowledgement MUST be sent to the Source Address of the
    IPv6 header that carried the Binding Update.  Unlike 
    the treatment of regular packets, this addressing procedure
    does not use information from the Binding Cache.  If the 
    Source Address is not an address of the mobile node on its
    home network, then the Binding Acknowledgement MUST be sent
    using a Type 2 Routing Header which contains the mobile
    node's home address.  Otherwise, the routing header MUST
    NOT be used.

5. Since 10.2 references 9.4.4, there needs to be less text in 10.2,
   but the following is added preceding the cross-reference:
 
     If the Source Address field in the IPv6 header of the Binding Update is
     equal to the home address of mobile node, then it indicates that the
     mobile node is back at home. In this case, Binding Acknowledgement MUST
     NOT include a Type 2 Routing Header.  For all other unicast routable
     care-of addresses, the Binding Acknowledgement MUST include a Type 2
     Routing Header.

  Samita asks:

  > BTW, why do we need to include RH Type 2 in BA when src-addr != home-addr,
  > is this because of authentication verification at the MN end ?  May be
  > we should clarify that in the draft.

  My understanding is that mobiility messaging is processed as if it were
  happening end-to-end between nodes at their home addresses.  So, for
  instance, any security associations would be indexed by home addresses.
  I'm not quite sure what needs to be clarified.  Or maybe I missed the
  point of the question.

  Since this is a deregistration, and given the way the 'S' bit works,
  I think it's unwise to accept deregistrations from a link-local
  address, so the 9.4.4 text still does work.

6. Proposal: Since 10.2 cross-references 9.4.4, maybe it's better anyway
   to pull the text out of 9.4.4 into a "better" place.  The question is,
   what place is better.  One possibility: the bottom of 6.1.8, which
   previously contained erroneous text.

7. The suggestion was made to cause all Binding Updates to contain
   a Home Address option, even for deregistrations on the home network
   where it is not necessary.  I don't think this really buys any
   decrease in processing complexity.  It is logically separate from
   the other details in this multifaceted thread.  So, I'm reluctant
   to make this change without a clear mandate, and from the standpoint
   of efficiency it's a loss.

8. Create a new subsection of Section 4, which discusses issues
   about addressability of mobile nodes and home agents:

   (from Jari Arkko):
   - Require that home agents and mobile nodes that use site-local
              addresses always stay completely within that site.
   - Pick a global care-of address if available.
   (from Hesham Soliman):
   - Home Agents should never be multi-sited.
   (from Jari Arkko):
   - Mobile Node network interfaces should never be multi-sited.

    James Kempf writes:

    > I'd like to see these critera reflect the possibility of
    > using a site local for a LCoA with an LMM agent.

   I agree with the intention, but the possibility does remain with
   the above restrictions, and handling of local care-of addresses
   by LMMs has to be specified completely outside the base specfication,
   and it seems to me that no problems result from the above.

Comments are welcome.  It's a very complicated set of issues,
and has taken some time to get right, if indeed the above does
lead towards an acceptable set of resolutions.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 23 Oct 2002 11:43:35 -0700

Hello folks,

I have updated the specification according to the
suggestions in the proposal.

There are two details left that may require discussion.
One has to do with whether the mobile node is allowed
to use its link-local address for deregistrations on the
home network.  The current wording below allows this.
The other has to do with formulating some text to be
added to 6.1.8.  This has not yet been done.  See comments
inline for details.

Regards,
Charlie P.

"Charles E. Perkins" wrote:
>     node's home address.

This wording was chosen to allow the mobile node to use its
link-local address when deregistering on the home network.
If such use is to be prohibited, then a simpler formulation
could be used which requires the mobile node to use its
(unicast routable) home address instead.

>                             Otherwise, the routing header MUST
>     NOT be used.
> 
> 

This part of the proposal is not yet implemented, but I'll try
to do it before tomorrow.