Subject: [mobile-ip] Comments on Mobile IPv6 draft 14

From: "Venkata Jagana" <[email-masked]>
Date: Thu, 20 Sep 2001 18:49:22 -0700

Hello Charlie,

I have the following comments on MIP6 draft 14. Not really sure,
whether these similar issues have come up in earlier discussions or not
but I am unable to find any references in the archive. I am also
one of the contributors to MIP6 implementation in Linux
(i.e. MIPL/HUT project) and came across some of these issues during
an implementation. Thanks in advance for your responses and sorry for
the long mail.

1. There are conflicting descriptions about MN retransmitting BU's to HA
   in Sec 10.7 and Sec 10.8 if it doesn't receive matching BA's. Pasting
   the corresponding text here for quick reference.

   From Sec 10.7:
   " ...the mobile node SHOULD retransmit this Binding Update to its home
agent
   until it receives a matching Binding Acknowledgement.  Once reaching a
   retransmission timeout period of MAX_BINDACK_TIMEOUT, the mobile
   node SHOULD continue to periodically retransmit ..."

   It is quite possible that there may not be any matching BA from the HA
for
   the period of MAX_BINDACK_TIMEOUT (as noted in Sec 10.7) and in which
case
   rather than defaulting to periodic retransmissions, the MN could try the
   registration process of this binding with the remaining list of
   Home Agents for MN before switching to periodic retransmissions.

   In fact, sec 10.8, dynamic home agent address discovery (DHAAD), talks
about
   the exact similar thing of trying the home registration with the
remaining
   list of home agents.

   From Sec 10.8:
   " For example,if necessary, the mobile node MAY attempt its home
registration
   with each of these home agents,...... ...... In trying
   each of the returned home agent addresses, the mobile node SHOULD try
   each in the order listed in the Home Agent Addresses field in the
   received Home Agent Address Discovery Reply message."

   Even excluding the example piece in sec 10.8, I believe the MN should
   really try sending BU's with its remaining list of Home Agents (if any)
   after it initially failed with its first HA for a MAX_BINDACK_TIMEOUT
period.

   This needs to be clarified in the draft document.

2. This comment is also related to again Sec 10.7 "sending binding updates
   to the home agent":

   "...... the mobile node SHOULD continue to periodically retransmit
   the Binding Update at this rate until acknowledged (or until it begins
   attempting to register a different primary care-of address)."

   The above underlined statement is confusing to me because I can come up
   with two different interpretations of "different primary CoA is selected
   either from its pool of CoA's obtained in the same FN or when it has
   moved to a new FN." Of course, the first interpretation doesn't seem to
   make any sense but it quite possible to select different CoA as the
primary
   for some vague reason and use that in the BU.

   Please clarify if it really means that the selection of different
primary CoA
   is to be made after moving to a different FN or in the same FN. But, If
the
   selection of primary CoA is made within the same FN, then the spec
should
   clarify about the retransmission under Retransmission of binding update
(sec 10.11).

3. This comment is also related to again Sec 10.7 "sending binding updates
   to the home agent":

   "In the unlikely event that the mobile node's home address is
autoconfigured
    ......the home agent will reply to the mobile node's subsequent Binding
    Update with a Binding Acknowledgement showing Status 138, Duplicate
Address
    Detection failed".

   However, the draft doesn't clarify on what MN should do next in such a
scenario.
   I believe that, at least, even if this home address registration fails,
then MN
   can/should continue with additional registrations of its remaining home
addresses
   if there are any. Of course, these multiple registrations can however be
performed
   in parallel rather than doing them in sequence. In the case of a single
home address
   registration, if BA comes with status 138, then what else MN should do?
Is that the
   decision left to the implementation or would the draft clarify
something?

   Usually, I believe such a scenario wouldn't occur and I agree that it is
never
   guaranteed and hence MN possibly may pick up a different home address
and then
   continue rather than having to leave MN up in the air.

4. The above comment (3) brings up another interesting point related to
BU's sent to
   CNs.

   Consider the following scenario: If a MN sends BU to CN at any time ( as
defined in
   sec. 10.9 "A mobile node MAY send a Binding Update to any correspondent
node at
   any time to allow the correspondent node ...") after picking up new
CoA(s) but
   before the completion of Home Address registration of this same COA
(used in BU to CN),
   then won't this be a problem.

   Hence, a MN may not a send a BU to CN at any time but only after the
primary COA
   registration succeeds to make sure the home address is valid and
otherwise, this
   address will be a conflict with another node on its home network. Of
course, the procedure
   for not allowing this home address to be picked up by another network is
outside the
   scope of this document and I am sure this is a hole in the ND protocol
unless I am
   missing something here.

5. The draft doesn't talk about what would MN do if MN returns back to its
   previously visited network.

   Sec 10.20 discusses about MN returning home - I may be wrong but my
   understanding of this section is that MN is returning to its Original
   Home (OH) but not the previous FN it just visited earlier and returning
back
   to it like in example of MN moving from A -> B -> C -> B network and
   in which case, MN should deregister its earlier CoA with HA at B (FH -
Foreign Home,
   btw, pardon for my new terminology)as described in Sec 10.20 but in
addition,
   the draft should also clarify that MN should register this primary CoA
with its original HA.

   In overall, I believe the section 10.20 is fully applicable to the
scenario
   just I described but additional clarifications needed to be added.

I may be wrong in some of my interpretations but please let me know if
that's the case.

Thanks,
Venkat

----------------------------------------------------------------
Venkata R Jagana
IBM Linux Technology Centre, Beaverton
[email-masked]
Tel: (503) 578 3430 T/L 775-3430
----------------------------------------------------------------

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 24 Sep 2001 13:18:57 -0700

Hello Venkata,

Sorry for the delay in answering your questions.

Venkata Jagana wrote:

>    " ...the mobile node SHOULD retransmit this Binding Update to its
>    home agent until it receives a matching Binding Acknowledgement.
>    Once reaching a retransmission timeout period of MAX_BINDACK_TIMEOUT,
>    the mobile node SHOULD continue to periodically retransmit ..."
                        .........
>    This needs to be clarified in the draft document.

Agreed.  Here is my text which tries to capture your argument:

           .....                        Once reaching a retransmission
   timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart
   the process of delivering the Binding Update, but trying instead the
   next Home Agent from its Home Agent list (see section 10.8).  If 
   there is only one home agent in the Home Agent list, the mobile node
   instead SHOULD continue to periodically retransmit the Binding Update
   at this rate until acknowledged (or until it begins attempting to 
   register a different primary care-of address).  See section 10.11 for
   information about retransmitting Binding Updates.

>    primary for some vague reason and use that in the BU.
> 
>    primary CoA is to be made after moving to a different FN or in the
>    same FN. But, If the selection of primary CoA is made within the
>    same FN, then the spec should clarify about the retransmission under
>    Retransmission of binding update (sec 10.11).

I don't know whether it is wise to make this restriction.  I can
imagine arguments for both sides.  And anyway, the point should
be that the mobile node tries a new Home Agent, not a new care-of
address. (!)  The mechanisms by which a mobile node acquires a new
care-of address are more related to either layer-2 triggers, or
reception of new Advertisements.  Neither of those events is
crucially relevant to the issue here, it seems to me.

>     autoconfigured ......the home agent will reply to the mobile node's
>     subsequent Binding Update with a Binding Acknowledgement showing
>     Status 138, Duplicate Address Detection failed".
> 
>    scenario. I believe that, at least, even if this home address
>    registration fails, then MN can/should continue with additional
>    registrations of its remaining home addresses if there are any.
>    Of course, these multiple registrations can however be performed
>    home address registration, if BA comes with status 138, then what
>    else MN should do? Is that the decision left to the implementation
>    or would the draft clarify something?
> 
>    never guaranteed and hence MN possibly may pick up a different home
>    address and then continue rather than having to leave MN up in the air.

First, it's important to make sure the mobile node stops using the
same home address in this case.  But I think it's reasonable to
follow your suggestion here.  I've put in the following text:

      ....  In this case, the mobile node MUST NOT attempt to re-use
   the same home address.  It SHOULD continue to register care-of
   addresses for its other home addresses, if any.  The mobile node MAY
   also attempt to acquire a new home address to replace the one for
   which Status 138 was received, for instance by using the techniques
   described in appendix B.

>    BU's sent to CNs.
>    Consider the following scenario: If a MN sends BU to CN at any time (as
>    defined in sec. 10.9 "A mobile node MAY send a Binding Update to any
>    correspondent node at any time to allow the correspondent node ...")
>    after picking up new CoA(s) but before the completion of Home Address
>    registration of this same COA (used in BU to CN), then won't this
>    be a problem.
> 
>    primary COA registration succeeds to make sure the home address is
>    valid and otherwise, this address will be a conflict with another
>    node on its home network. Of course, the procedure for not allowing
>    this home address to be picked up by another network is outside the
>    unless I am missing something here.

If the mobile node is assured that its home address is valid, then
it should be allowed to send Binding Updates to correspondent nodes
at any time.  After the mobile node sets the 'D' bit in a home
registration, and the home agent accepts, the mobile node can have
this assurance.  I have put in some text to make this clear.
For instance, in the description of the `D' bit in section 9.1:

                         .......              When the home agent sends
       a successful Binding Acknowledgement to the mobile node, in 
       response to a Binding Update with the `D' bit set, the home agent
       assures to the mobile node that its home address will continue to
       be valid at least as long as the mobile node transmits Binding  
       Updates with new care-of addresses for that home address.    

And in section 10.9:

   When the mobile node is assured that its home address is valid,  
   it MAY send a Binding Update to any correspondent node at any
   time to allow the correspondent node to cache the mobile node's
   current care-of address (subject to the rate limiting defined in  
   Section 10.12).  See for example the home agent's use the 'D' bit  
   of Binding Updates (in section 9.1) for how the mobile node can be 
   assured that its home address is still valid.

>    back to it like in example of MN moving from A -> B -> C -> B network
>    and in which case, MN should deregister its earlier CoA with HA at B
>    (FH - Foreign Home, btw, pardon for my new terminology) as described
>    in Sec 10.20 but in addition, the draft should also clarify that MN
>    should register this primary CoA with its original HA.

I didn't understand the problem here.  What does "HA" mean in the last
sentence?  I don't think there is a problem, unless the mobile node
is changing its home agent or home address somehow.  Basically, the
home agent just has a single care-of address for the mobile node,
and the care-of address is supposed to correspond exactly to the
current FN.  There would not be a need for the mobile node to
deregister previous care-of addresses at its home agent.

> Venkat

Regards,
Charlie P.