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

From: "Venkata Jagana" <[email-masked]>
Date: Mon, 24 Sep 2001 23:29:15 -0700

Hello Charlie,

Thanks very much for your responses.

The modified text for items 1, 3 and 4 looks quite good to me.
Item 2 doesn't seem to cause any problem now (see my response below).
See my response below to item 5 with some reasoning why it is still
an issue.

>> 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 ..."
                        .........
>>    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.

>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.

   Looks good.

>> 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).

> 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.

   I agree that the issue here is not related to how MN acquires the CoA's
   in the foreign networks but how it makes use of its pool of CoA's in
   registering with the home agent.

   OK, this issue may not make sense anymore because of comment [1] above
   which dictates that MN should restart the BU process with the new home
   agent from its list if doesn't get an BA within MAX_BINDACK_TIMEOUT
   period.

>> 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.

> 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.

  Looks good.

>> 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.

> 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.

   The text looks quite OK to me.

>> 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.

> 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.

  Let us consider a scenario where MN moves from its home network 'A' to
  foreign network 'B' and then to foreign network 'C'.

  After moving from network 'A' to network 'B', MN should have registered
  (i.e. BU sent)its primary CoA picked up at 'B' with the home agent at
'A'.
  Now, the HA at 'A' has a binding cache entry marked home registration.

  Next, the MN moves from 'B' to 'C', then, MN would send BU to the HA
  at 'A' to request the change in cache entry with the new CoA just
obtained
  at 'C' and also to a home agent at 'B' to register its new CoA obtained
at
  'C' network. The registration with home agent at 'B' is required so that
  packets addressed to its old CoA at B will now be tunnelled to its new
  CoA at 'C'. Effectively, the MN now has one home agent at 'A', which I
  called 'Original Home - OH' (because that's where its home was) and
another
  home agent at 'B' which I called 'Foreign Home - FH' at 'B'.

  Let us say that, after sometime, the MN came back from 'C' to 'B'
  during its movement path and which means that MN can start reusing its
  old COA at but before start using it there, it needs to deregister its
CoA
  at B with HA at 'B'; then sending a BU to its OH at 'A' with this CoA
  at 'B'. Then, it will have to send a BU to HA at 'C' with the CoA at 'B'
  to start tunnelling packets destined fro MN. In this case, the 'FH' is
  effectively now moved 'B' to 'C'. In this case, it had to perform 3
steps:
  deregistration with 'B', registration with HA ('OH') at 'A' with CoA at
'B'
  and registration with  HA ('FH') at 'C' with COA at 'B'.

  Hope I made this clear without making it too complicated. So, my point
  is that the draft didn't consider a scenario like this and hence never
  talked about deregistration with home agent on the foreign networks the
  MN visited. The draft only discussed about the MN going back to its home,
  i,.e always 'A' in this case, and its deregistration procedures. In
reality,
  I am sure this scenario( and there are others) I described here is very
  well applicable and I strongly believe that this needs to be addressed,
  Am I missing something here? Hope not.

Thanks,
Venkat

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

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 25 Sep 2001 10:44:23 +0200

>   MN visited. 
	=> I beleive that this is due to th fact that neither the data structures
	(Binding cache or BUL) nor the BUs distinguish between a "foreign HA" or a 
	"real HA". So the section on deregistering when connecting to the 
	Home network still applies to your scenario. 

	Hesham

---

From: "Venkata Jagana" <[email-masked]>
Date: Wed, 26 Sep 2001 19:14:55 -0700

Hello Peter,

> It might be a good idea though to add a bit in the draft explaining this.

     I think so.

> However, I should like give another scenario almost similar to yours:
> The MN returns to network 'B' but gets another (second) CoA at 'B'. In
> this case, the "first CoA at 'B'" does not return home, and the
> deregistration at home agent at 'B' shouldn't be done.

     You may 'not' like to get another CoA if your MN already knew that
     it currently has a home registration with that 'B' network. And
     otherwise, the packets destined for old CoA at 'B' will be tunnelled
     to network 'C' and from there, again it will be tunnelled back
     to this new CoA at 'B' which I believe is messy. In fact, you can
     avoid this cris-cros situation by simple deregistering at 'B'
     and grab the old CoA at 'B'. I can imagine a scenario where a MN,
     at the boundaries moving too fast from one network to another even
     considering that fact that the lifetime of 'forwarding from previous
     CoA' is short, may experience this type of problem and this
     solution can simply avoid that problem.

> Extending this scenario seems messy, but one should remember, that most
> probably, the lifetime of "forwarding from a Previous Care-of Address"
> is short.

> Peter

Thanks,

Venkat
--
Venkata Jagana wrote:
>
> ...
>      Deregistering section, 9.4, applies to Home agent operation
>      and it describes about what HA should do when deregistration
>      (i.e. BU received) happens but what I am talking about is MN
>      operation, sec 10.20 (MN returning home) and not HA. This scenario
>      involves not just deregistration only but much more, sorry,
>      I haven't made that very clear in my last mail.
>
>      In a scenario, I have described here, MN should do the following
>      things at a minimum:
>           - deregister with home agent at 'B'
>           - Binding update to home agent at 'A' to refresh its
>             bcache entry with the CoA at 'B' now
>           - registration with foreign home agent at 'C' to start
>             tunnelling packets to CoA at 'B'
>
>      At any time, a MN may have a single original/real Home Agent
>      and single or multiple foreign Home Agents. At a given instance,
>      the number of foreign home agents a MN may have, will depend upon
>      how fast the MN is moving across the networks but it doesn't need to
>      keep track of all those foreign home agents except for the last one.
>      In a case where MN moves too quickly from one network to another,
>      then it would have established registrations with each of those
>      foreign home agents at the networks it visited earlier in order to
>      have the packets tunnelled to its current CoA from the previous
>      old CoA's.
>
>      Section 10.20 simply talks about MN returning home (its original
>      or real home) but it doesn't 'explicitly' talk about a MN moving
>      back to a old network it just visited earlier and what MN
>      should do (probably, I would consider this as a special case) and it
>      is not covered at all in this section unless it is interpreted that
>      it is left to the implementation, but I don't think that's a
>      good idea to leave it that way.

Thanks,
Venkat

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