Subject: [MOBILE-IP] New version of RFC2002bis

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 12 Jul 2000 09:22:28 -0700

Hello,

I have almost completed editing the new revision of RFC2002bis.

Here is the text of the appendix listing the changes:

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

   This section lists the changes between this version (...-02.txt) and
   the previous version of the document.

    -  Allowed registrations to be authenticated by use of a security
       association between the mobile node and a suitable authentication
       entity acceptable to the home agent.  Defined "Admissible
       Authentication extension" to be an authentication extension that
       makes a registration message acceptable to the recipient.
    -  Allowed registration replies to be processed by the mobile node,
       even in the absence of any Mobile-Home Authentication extension,
       when containing rejection code by the foreign agent.
    -  Specified that the mobile node SHOULD take the first care-of
       address in a list offered by a foreign agent, and MAY try
       each subsequent advertised address in turn if the attempted
       registrations are rejected by the foreign agent
    -  Eliminated Van-Jacobson Compression feature
    -  Updated assigned numbers lists
    -  Removed Open Issues
    -  Still more syntax corrections and editorial improvements

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

I have made the following resolutions for the Open Issues:

------------------------------------------------------------------------

J. Open Issues

    -  Whenever the foreign agent can change the Code in a Registration
       Reply from the home agent to indicate rejection, the mobile node
       can no longer check validity.

       This is also true if the foreign agent can change the granted
       lifetime in a Registration Reply.

       On the other hand, the mobile node could re-calculate with its
       record of what Lifetime it had requested, or assuming that the
       registration Code was a successful code.  Should the revised
       draft specify these behaviors?

Answer:

This is addressed by allowing rejection codes to be processed by
the mobile node.  If a foreign agent rejects registrations, and it
is bogus, then you don't want to use that foreign agent anyway.

If the foreign agent changes the lifetime, the authentication is
bad and the mobile node SHOULD NOT believe it.  The foreign agent
can send back a modified Registration Reply with a rejection Code
if it doesn't like the home agent's modified Lifetime.

This is already covered by the draft.

------------------------------------------------------------------------

    -  Should we just get rid of the possibility of considering the
       Router Addresses in Agent Advertisements?

Answer:

If anyone wants to suggest some further changes to the draft,
then the working group can discuss the changes.  Until then,
I don't see any substantial reason to make further changes.

------------------------------------------------------------------------

    -  From the mailing list:

          Q: new FA forwarding text; sometimes two MNs on the same
          FA sometimes get traffic forwarded directly rather than
          via HA. Also MNs can introduce denial of service if they
          make a mistake in their registration messages - sometimes
          re-registrations can be redirected at a MN!

       Is anything needed here?

Answer:

This is done better by using Binding Updates from the Route Optimization
draft.  Thus, it should not be considered an open issue for RFC 2002bis.

------------------------------------------------------------------------

    -  What does a home agent do with a reverse-tunneled broadcast
       packet?  Does it send the broadcast on the appropriate network
       interface?  Does it drop the packet?  Does the behavior depend
       on whether the mobile node set the 'B' bit in its Registration
       Request?

Answer:

These behaviors should be specified by the revised Reverse Tunneling draft.
I suggest moving the open issue to that draft.

------------------------------------------------------------------------

If the changes, and the resolutions to the open issues are acceptable,
I think the draft is ready for Last Call to Draft Standard.

Regards,
Charlie P.

PS. I will send the URL for the revised RFC2002bis soon.