Subject: [mobile-ip] Re: problem when MN communicates with MN

From: Jari Arkko <[email-masked]>
Date: Sun, 19 Jan 2003 14:56:01 +0200

Ryuji Wakikawa wrote:

> If MN1 communicates with MN2, I guess that the section 11.7.2 of the
> mip6 draft is not well applied to decide the RR timing.
> 
> Section 11.7.2 said 
> "The destination address to which the procedure should be initiated to
>  in response to receiving a packet meeting all of the above tests is
>  the Source Address in the original (inner) IPv6 header of the packet."
> 
> but it should be clarified more like
> "If an home address option is present in the packet (inner IPv6
> header), the source address MUST be the home address in the home
> address option."

I agree. Your text is good, though we need to worry about one
additional thing. The Care of Test Init message can be destined
to the mobile node's home address, and its source is also a care-of
address -- and this time there is no HAO. So, my suggestion for
the text in 11.7.2 is as follows:

    ... that meets all of the following tests:

    o  The packet was tunneled using IPv6 encapsulation.

    o  ...

    o  The packet is not a Care-of Test Init message.

    The destination address to which the procedure should be initiated to
    in response to receiving a packet meeting all of the above tests is
    the Source Address in the original (inner) IPv6 header of the packet.
    If a Home Address destination option is present in the packet (inner IPv6
    header), the source address MUST be the home address in the home
    address option.
    ...

Draft updated on the web.

Jari

> Then the below problem can be avoided.
> 
> Situation:
> I might not be able to tell the situation correctly.
> If you can not understand my writing, I will clarify more.
> 
> Imagine when MN1 sends packets containing Home Address Option via HA
> (re-directional tunneling) to MN2. This is easily happen, because it
> is impossible to create BC at both of MNs (MN1 and MN2) at the same
> time.  There is some period that MN1 only acquires the binding cache
> entry for MN2.
> 
> Here is an example of the problem.
> ex. MN1 has the BC for MN2, but MN2 does not have a BC for MN1.
> When MN2 sends packets to MN1 at this point, the packet will be 
> 
> # CoA1 means MN1's CoA, and CoA2 means MN2's CoA.
> 
> The packet sent from MN2 will be like
> 	IP (src CoA2 dst MN1-HoA) + Home address option(MN2-HoA)
> 
> The packet received at MN1 will become like
> 	IP(src MN1-HA, dst CoA1) + IP (src CoA2 dst MN1-HoA) + Home address option(MN2-HoA)
> 
> In this case, the MN1 might insert a binding update list for CoA2.  If
> MN1 has already had a binding update list entry for MN2-HoA (ex.
> receiving MN2's tunneled packet), this situation becomes a loop
> problem. Insertion of MN's CoA and HoA into the binding update list is
> really BAD.
> 
> Problem:
> If MN1 sends BU for each of BUL entries, the receiver (MN2) will return
> SEQ_OUT error to MN for the BU of either BUL entries.
> 
> ie. The binding update list on MN1 is like 
> entry-1. dst = MN2-HoA seq = 1
> entry-2. dst = MN2-CoA seq = 2
> 
> After receiving BU for the entry-2, MN2 receives BU for the entry-1.
> Then MN2 sends SEQ_OUT, because the sequence number of the entry-1 is
> smaller than the number in the binding cache.  If MN1 increase the
> sequence number when it receives SEQ_OUT ACK, the entry-2 becomes
> smaller value. It becomes the loop problem.